Prometheus is an Open Data platform with hard anonymity guarantees. Security vulnerabilities can fall into two categories:
- Standard vulnerabilities (RCE, injection, XSS, auth bypass, SSRF, deserialisation bugs) in
src/mirror/,src/scraper/,src/sdk-*orinfra/. - Anonymity breaches (re-identification methods, PII leaks in the submission schema or the aggregate store, k-anon violations, cross-snapshot mosaic attacks).
Both categories follow the same disclosure path — see below.
Disclosure path#
Do not report publicly (no issue, no PR body, no public forum post) for as long as a fix has not been coordinated.
Instead, send a signed, encrypted message to:
- E-mail:
security@<TODO-foundation-domain>(the foundation domain follows once the foundation is attached; until then: contact theMAINTAINERS.mdlist directly) - PGP public key:
https://<TODO-domain>/.well-known/pgp-prometheus.asc(fingerprint follows once generated) - Signal/Matrix: on request via the e-mail channel
What belongs in the report#
- A concrete description of the weakness / the re-identification vector
- Reproduction steps (please keep them minimal and deterministic)
- The code path or data scope affected
- Possible mitigation proposals (optional)
- Your preferred disclosure timeline (default 90 days)
Timelines#
| Step | Target time |
|---|---|
| Acknowledgement of receipt | within 48 hours |
| First assessment (severity + fix plan) | within 7 days |
| Patch available | 30–90 days (depending on complexity, agreed with the reporter) |
| Public advisory | after patch and rollout, usually after 90 days |
If the vulnerability is being actively exploited, we shorten this to as few days as possible. If the reporter wants a specific publication deadline, we respect it.
What counts as an anonymity breach#
From concept/03-risikoprofil.md (the D family) plus follow-on cases:
- A submission that contains a forbidden field (see
concept/data-flow.md§3) and was accepted by the mirror. - An aggregate store entry with
k_effective < k_minwhere thecohort_idfield was not rewritten to__small_cohorts(concept/07-prototyp-requirements.md§6.6). - A method that can reproducibly trace individuals, maintainers or end-user hosts back from an Open Data snapshot (mosaic re-identification, D-2-1).
- A bug in the SDK through which PII (e.g. env var contents, hostnames, repository paths in the clear) reaches the egress buffer before stages 5/6 (D-2-2).
- A bypass of submission validation at the mirror through clever JSON schema variations.
What does NOT count as a security vulnerability#
- DoS against the public read APIs through load (that is a mirror operations matter and belongs in rate limits, not in a vulnerability disclosure).
- Limited performance of the snapshot worker.
- Stylistic or coding standards violations.
Warrant canary (prepared)#
As soon as the federation operates a production mirror, a warrant canary block will appear under /v1/status containing:
- A date plus a signed statement that no order has so far been received that would undermine the Open Data guarantee.
- A signature by the mirror DID plus a co-signature from at least one federation maintainer.
The disappearance of the canary is to be read as a signal.
Bug bounty#
Currently there is no monetary bounty. Recognition takes the form of:
- An entry in
SECURITY-HALL-OF-FAME.md(to follow) with the reporter's handle and an ADR reference to the vulnerability (if the reporter agrees). - A Co-Authored-By entry in the patch commit.
As soon as a foundation sponsor (concept/06-offene-punkte.md P1-6) provides a bounty pot, this section will be updated.