Security Policy · Prometheus

Prometheus ist eine Open-Data-Plattform mit harten Anonymitäts-Garantien. Sicherheitslücken können in zwei Kategorien fallen:

Standard-Vulnerabilities (RCE, Injection, XSS, Auth-Bypass, SSRF, Deserialisierungs-Bugs) in src/mirror/, src/scraper/, src/sdk-* oder infra/.
Anonymitäts-Verstöße (Re-Identifikations-Methoden, PII-Leaks im Submission-Schema oder Aggregate-Store, k-Anon-Brüche, Cross-Snapshot-Mosaik-Angriffe).

Beide Kategorien folgen demselben Disclosure-Pfad — siehe unten.

Disclosure-Pfad#

Nicht öffentlich melden (kein Issue, kein PR-Body, kein öffentlicher Forum-Post), solange ein Fix nicht koordiniert ist.

Stattdessen per signierter, verschlüsselter Nachricht an:

E-Mail: security@<TODO-foundation-domain> (Foundation-Domain folgt mit Foundation-Anbindung; bis dahin: MAINTAINERS.md-Liste direkt kontaktieren)
PGP-Public-Key: https://<TODO-domain>/.well-known/pgp-prometheus.asc (Fingerprint folgt mit Generierung)
Signal/Matrix: auf Anfrage über den E-Mail-Kanal

Was in den Report gehört#

Konkrete Beschreibung der Schwachstelle / des Re-Id-Vektors
Reproduktions-Schritte (bitte minimal und deterministisch)
Betroffener Code-Pfad oder Datenscope
Mögliche Mitigations-Vorschläge (optional)
Gewünschte Disclosure-Zeitlinie (Default 90 Tage)

Zeitlinien#

Schritt	Zielzeit
Eingangsbestätigung	innerhalb von 48 Stunden
Erste Bewertung (Severity + Fix-Plan)	innerhalb von 7 Tagen
Patch verfügbar	30–90 Tage (je nach Komplexität, mit Reporter abgestimmt)
Public Advisory	nach Patch + Rollout, üblicherweise nach 90 Tagen

Wenn die Lücke aktiv ausgenutzt wird, verkürzen wir auf so wenige Tage wie möglich. Wenn der Reporter eine spezifische Veröffentlichungs-Frist will, respektieren wir das.

Was als Anonymitäts-Verstoß zählt#

Aus concept/03-risikoprofil.md (D-Familie) plus Folge-Cases:

Eine Submission, die ein verbotenes Feld (siehe concept/data-flow.md §3) enthält und vom Mirror akzeptiert wurde.
Ein Aggregate-Store-Eintrag mit k_effective < k_min, ohne dass das Feld cohort_id auf __small_cohorts umgeschrieben wurde (concept/07-prototyp-requirements.md §6.6).
Eine Methode, die aus einem Open-Data-Snapshot Einzelpersonen, Maintainer oder Endnutzer-Hosts reproduzierbar zurückführen kann (Mosaic-Re-Identifikation, D-2-1).
Ein Bug im SDK, durch den PII (z. B. Env-Var-Inhalte, Hostnames, Klartext-Repo-Pfade) vor Stufen 5/6 in den Egress-Buffer kommen (D-2-2).
Bypass der Submission-Validierung am Mirror durch geschickte JSON-Schema-Variationen.

Was NICHT als Sicherheitslücke zählt#

DoS gegen die öffentlichen Read-APIs durch Last (das ist Mirror-Operations-Sache, gehört in Rate-Limits, nicht in eine Schwachstellen-Disclosure).
Eingeschränkte Performance des Snapshot-Workers.
Stilistische / Coding-Standards-Verstöße.

Warrant Canary (Vorbereitet)#

Sobald die Federation einen produktiven Mirror betreibt, wird unter /v1/status ein Warrant Canary-Block erscheinen mit:

Datum + signiertem Statement, dass bisher keine Anordnung eingegangen ist, die Open-Data-Garantie zu unterlaufen.
Signatur durch die Mirror-DID + Co-Signatur mind. eines Federation-Maintainers.

Das Verschwinden des Canaries ist als Signal zu lesen.

Bug-Bounty#

Aktuell keine monetäre Bounty. Anerkennung erfolgt durch:

Eintrag im SECURITY-HALL-OF-FAME.md (folgt) mit Reporter-Handle und ADR-Verweis auf die Lücke (sofern Reporter zustimmt).
Co-Authored-By-Eintrag im Patch-Commit.

Sobald ein Foundation-Sponsor (concept/06-offene-punkte.md P1-6) den Bounty-Topf bereitstellt, wird dieser Abschnitt aktualisiert.