Security

Reporting a vulnerability

• Email: security@purposesource.org. Encrypting is welcome; a key fingerprint will be published here with the first key ceremony record.
• Machine-readable: /.well-known/security.txt (RFC 9116) points here and at that address.
• Do not use the public contact form for a vulnerability; the form is fine for everything else.

Response targets (targets, not a service-level commitment — the team is small): acknowledgement within 3 business days; triage and an initial severity assessment within 10 business days; a fix or a published advisory on a timeline agreed with you, by severity. If we go silent, escalate to legal@purposesource.org.

Coordinated disclosure. We ask for 90 days from acknowledgement before public disclosure, or earlier by agreement once a fix is deployed. We publish a post-mortem for any issue that affected published artifacts, the signing keys, or the transparency log, and we credit reporters who want credit. There is no bug bounty.

Scope

In scope: this website; the edge API at api.purposesource.org and the apex machine endpoints (/jwks.json, /stats.json, /ct/*); the published artifacts (registry, ledger, certificate records, entitlement records, key set, transparency log) and any way to make them assert something false; the certificate issuance and verification chain; the form intake routes; the public repositories under github.com/purposesource.

Out of scope: the subprocessors’ own infrastructure (report to them directly); denial-of-service and volumetric findings; social engineering of the team; findings that need physical access; automated-scanner output without a demonstrated impact; the content of third-party repositories that merely adopt the licence.

Safe harbour

Research conducted in good faith under this policy — staying within scope, avoiding privacy violations and service degradation, not exfiltrating data beyond what is needed to demonstrate the issue, and giving us the disclosure window above — is authorised. The Association will not pursue legal action against you for it, and will state that your research was authorised if a third party raises the question. This does not authorise action against any third party, including the subprocessors, and it cannot bind them.

How this is built

• A static site. Every page is server-rendered HTML; the two scripts on the site (the counters refresh and the verification island) only ever refresh what the HTML already says. No cookies, no analytics, no consent banner — aggregate traffic comes from server-side edge metrics that never touch a visitor’s browser.
• One third-party script, the bot-protection widget on the contact forms, loaded only there. The Content-Security-Policy in the response headers names it as the sole external script source; no analytics host is permitted, and the build fails if one is added.
• No database on any anonymous path. The edge API serves published artifacts from an object store and a key-value cache; there is no relational store behind any public route, so there is nothing to inject into and nothing to exfiltrate from.
• Forms store nothing. A submission is verified server-side against the challenge service, forwarded as one email, and discarded. A missing or unverifiable challenge is a refusal — the form fails closed, never open.
• Key custody. Signing keys are born non-exportable in an HSM-backed vault in Switzerland; no human holds standing sign permission; every certificate is logged in the append-only transparency log before delivery. Details on keys.
• Supply chain. Dependencies are pinned by lockfile and installed with npm ci; the build runs nine gates that fail on a banned phrase, an unlabelled figure, a licence-text hash mismatch, a dead link, a structured-data claim we do not make, or a mutated log entry.
• Subprocessors and residency are listed on the Trust Center overview.

Incident history

None. When there is one, it is listed here with its post-mortem, and the status page linked from the footer carries the live timeline.