Security

Responsible disclosure

If you find a security issue — credential leak, API auth bypass, signature-forgery vector, injection vulnerability, denial-of- service path, or anything else that could compromise the integrity of claim envelopes or user accounts — please report it privately:

• Email: [email protected] — preferred for first contact.
• PGP: on request via the email above. We'll publish a key fingerprint here once the rotation cadence is stable (Day 30).
• GitLab issue (public): only for issues without an exploit primitive (e.g., dependency-CVE notices). acevault-lab/sourcescore-api/-/issues.

We aim to acknowledge within 24 hours and patch high-severity issues within 7 days. Coordinated disclosure preferred; we will credit reporters publicly on this page (opt-in).

Signing & verification

Every claim envelope is signed with HMAC-SHA256 over a canonical JSON serialization (sorted keys, ASCII-safe, no whitespace) of: claim fields + signedAt +signedBy. Re-compute locally to verify integrity — see the signature-verification example in the integration guide.

Signer identity: did:web:sourcescore.org. This identifier is preserved across all key rotations; the underlying key material changes, the public identity does not.

Migration path: v0 uses HMAC-SHA256 (shared secret) for the catalog distribution layer. Y2 migrates to W3C Verifiable Credentials with Ed25519 public-key signing. Existing envelope shape is forward-compatible — same fields, additional proof block. Old HMAC envelopes remain verifiable for ≥24 months post-migration.

Key rotation

The catalog signing secret rotates quarterly on a published schedule. Old envelopes remain valid forever (signatures are checked against the key in effect at their signedAt timestamp). New envelopes after the rotation date are signed with the new key.

• Quarter 1: signing key #1 active
• Quarter 2: signing key #2 active; key #1 used for legacy verification only
• … etc. Rotation events are logged to this page + /changelog/.

API-key hygiene

Paid-tier API keys are hashed (SHA-256) at rest; we never store plaintext. The key prefix (first 8 chars) is kept for ops identification but cannot reconstruct the full key. If you believe a key is compromised:

1. Revoke it immediately in your dashboard.
2. Generate a replacement.
3. Email [email protected] with the prefix so we can fingerprint the abuse pattern fleet-wide.

Scope of guarantees

• HTTPS everywhere. All endpoints (/api/v1/*, dashboard, docs) serve over TLS 1.2+. Cloudflare edge handles termination; HSTS preload pending Day 30.
• No PII in logs. We log request paths, status codes, and IP-hashes (not raw IPs) at the edge. We do not log request bodies, response bodies, or API-key plaintext.
• No user-data sales. Cloud provider terms (CF, Stripe, Resend) apply; we do not have an additional data-share relationship.
• Static signing surface. The catalog JSON twin served from the edge is content-addressable by claim id + timestamp. Mutation requires re-signing — there is no path for in-place edits.

What we don't (yet) guarantee

Honest scope, per methodology:

• Catalog claim correctness. Every claim has ≥2 primary sources hand-verified at publish time. Sources can go stale; we mark claims with lastVerified dates and re-verify on a documented cadence, but we do not guarantee that every claim is true at every future moment.
• SOC 2 / ISO 27001. Not yet certified. On roadmap for Y2 once we cross 100 paying customers (per the self-serve growth thesis).
• Bug bounty program. Not yet running formally; disclosures are credited publicly + we'll send a thank-you payment for high-severity reports at our discretion until a formal program launches.
• Public-key signing (Ed25519). v0 is shared- secret HMAC. Y2 migration is on the roadmap; until then, envelope integrity verification requires either trusting the catalog JSON twin OR holding the shared secret (Enterprise tier).

Incident response

Active incidents are surfaced on this page + at /changelog/ (severity: breaking) within 4 hours of detection. Post-mortems for incidents impacting paying customers are published within 14 days. Subscribe to /feed.xml for incident notifications.