DRS is security infrastructure. Please report vulnerabilities privately so they can be fixed before public disclosure.

Only the latest minor version line receives security fixes. DRS is at 0.x while the verification protocol stabilises; any new finding may be patched in a new 0.x.y release rather than backported.

Do not file a public GitHub issue for security-relevant findings.

Two acceptable channels:

1. GitHub private security advisory (preferred): https://github.com/OkeyAmy/DRS/security/advisories/new
2. Email: amaobiokeoma@gmail.com with subject prefix [DRS security].

Please include:

• affected layer (drs-core, drs-verify, drs-sdk)
• affected version (commit hash if running from source, tag if from a published artifact)
• a reproduction (minimal bundle, payload, or test case) if available
• your assessment of severity and attack scenario

These are best-effort targets. If a finding is actively exploited we will shorten them. If a finding requires upstream coordination (e.g., ed25519-dalek, serde-json-canonicalizer) we will say so and work to the upstream timeline.

In scope:

• cryptographic verification correctness (Ed25519, SHA-256 chain, JCS canonicalisation)
• DID resolution correctness and SSRF controls
• replay protection (nonce store)
• revocation semantics (local admin + remote status list)
• RFC 3161 timestamp binding
• HTTP surface of drs-verify (rate limiting, admin token, headers)
• SDK signing path correctness
• supply-chain risks in the published artifacts (crates.io, npm, ghcr.io)

Out of scope:

• denial of service that requires already-exhausted rate limits or unbounded resource allocation already documented as a pilot-only limitation (see docs/production-readiness-checklist.md)
• social engineering of maintainers
• vulnerabilities in third-party dependencies already tracked by upstream CVE databases unless they affect DRS in a way that is not obvious from the dep's advisory text

Good-faith security research is welcome. You will not be pursued for legal action as long as you:

• do not access data that is not yours
• do not disrupt production systems operated by third parties
• give us a reasonable window to fix before public disclosure
• do not demand payment in exchange for silence

Treat these as confirmed gaps, not findings:

• Process-local nonce store: drs-verify keeps replay state in memory. A restart loses it, and multiple replicas do not share it. Single- instance deployments only until #40 in the tracker lands.
• Local emergency revocation durability depends on configuration: POST /admin/revoke is process-local by default. Set REVOCATION_STORE_PATH for restart durability, and use the remote W3C Bitstring Status List for cross-replica propagation.
• Invocation freshness policy is design-gated: verifier code checks receipt temporal validity and nonce replay, but maximum invocation age and clock-skew policy are still being specified. Do not claim stale-invocation rejection beyond nonce TTL/replay behavior until that policy lands.

These are called out here so embedders can size their threat model accurately while the fixes are in flight.

Releases are tagged by the maintainer. The publish workflow signs the verifier image with keyless cosign; downstream users should verify the image signature and match release artifacts to the GitHub tag.