Security · responsible disclosure

Found a vulnerability? Email us first. We will respond within 3 business days.

You report. We acknowledge in 3 business days, assess in 10. We coordinate a fix on a 90-day default disclosure window. You get credit in the changelog unless you prefer not to.

bug_report Report a vulnerability schedule Response SLA my_location Scope verified Supply chain key Cryptography policy Threat model
1 · How you report

One email. No public issue.

Write to security@kyeprotocol.com with a clear reproduction. Do not open a public GitHub issue for a suspected security problem.

  • Include: affected component, version or commit SHA, reproduction steps, observed impact, your preferred credit name (or "anonymous").
  • Encrypt sensitive details: the PGP key fingerprint is published at /.well-known/security.txt.
  • We coordinate. Public disclosure happens on a mutually-agreed date. The default window is 90 days from the day you reported.
  • No bug bounty yet. Credit in the changelog is the recognition we offer today. A paid program is on the roadmap.
2 · What you get back

Three commitments. Plain English.

We tell you we received the report. We tell you what we found. We tell you when to publish.

  • Acknowledgement ≤ 3 business days. Receipt confirmed by a human, not a ticket bot.
  • Initial assessment ≤ 10 business days. You get a severity rating, a triage owner, and an expected fix window.
  • Coordinated disclosure on day 90, by default. Earlier if a fix ships sooner. Later only by mutual written agreement.
3 · What is in scope

Public surface. Reference runtime. Official SDKs.

If you find a bug in our published code or running surface, we want to hear about it.

  • In scope: everything under public/ in the GitHub mirror; the reference Gateway and PDP under internal; the TypeScript, Python, and Go SDKs; the marketing site at kyeprotocol.com; the sandbox at /sandbox/.
  • Out of scope: our internal tooling, third-party services we do not operate, social-engineering attempts against staff, denial-of-service or rate-limit probing against the live perimeter.
  • Proprietary mechanism content under internal is intentionally not published. Speculative attacks against undisclosed mechanisms cannot be assessed and will be closed without action.
4 · Supply chain

Seven controls. Run on every commit.

You can verify each control by reading the workflow files in the public GitHub mirror.

  • Dependabot. Weekly PRs for npm, pip, and github-actions. The github-actions ecosystem is SHA-pinned.
  • Dependency review. Runs on every pull request to main. Fails on any high-severity advisory.
  • Secret scan (gitleaks). Runs on every push and PR, plus a weekly scheduled scan.
  • Signed-commit check. Every commit between PR base and head must carry a valid signature. Unsigned commits block the merge.
  • SBOM (CycloneDX JSON). Generated on every push to main. SHA-256 hashed and retained for 90 days.
  • IP-safety scan. Blocks mechanism keywords from leaking into public/.
  • Webhook signing test vectors. Verify the public, vendor-documented primitives (HMAC, JWS (JSON Web Signature), COSE) round-trip on every PR. The KYE™ mechanism construction is proprietary and is not disclosed in this repository.
5 · Cryptography

What we sign with. And how often we rotate.

You verify every webhook with the standard, vendor-documented HMAC recipe. Every signed envelope verifies with Ed25519 over the canonical bytes. KYE™-specific signing constructions are proprietary and are not disclosed in this repository.

  • Webhook signing. Standard HMAC-SHA-256 (RFC 2104), 256-bit shared secret per publisher — the KYE™ mechanism construction is proprietary and is not disclosed in this repository. Use a constant-time comparison; the official SDKs ship a verifyWebhookSignature(...) helper that does so.
  • Envelope signing. Ed25519 (Edwards-curve Digital Signature Algorithm) over JCS (JSON Canonicalization Scheme, RFC 8785) canonical bytes.
  • Key rotation. Annual to monthly depending on key class. Compromise-driven rotations follow the post-compromise variant in the internal key-rotation runbook.
  • Public registry. Per-tenant signing public keys are published at the publisher's /.well-known/jwks.json. Any third party can verify any envelope without contacting us.
6 · Threat model

STRIDE matrix. Six named threats. Six mitigations.

The protocol surface threat model is maintained internally and reviewed each release. Six named threats — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — each map to a named mitigation in the runtime.

  • Spoofing → per-tenant Ed25519 signing keys; canonical bytes; offline verification from public registry.
  • Tampering → append-only D1 with WORM (Write-Once-Read-Many) triggers; object-store immutability in compliance mode for every audit chain.
  • Repudiation → signed Evidence Pack™ per privileged action; replayable from public keys alone.
  • Information disclosure → tenant-scoped row keys; mTLS / OAuth2 client-credentials on every privileged surface; IP-safety scan against public mirror.
  • Denial of service → edge-native rate limiting on every public endpoint; kill-switches per surface.
  • Elevation of privilege → Purpose Permission™ gate in front of every irreversible operation; two-person rule for the highest-impact actions.

Want the procurement-grade summary?

The Trust Center lists every claim with a reproducible verification command.

verified_user Open the Trust Center → forum security@kyeprotocol.com