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

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.

Canonical KYE™ surfaces referenced on this page: Evidence Pack™ · KYE Protocol™ · Purpose Permission.