Datenfluss — Prometheus v2

Vom Rohereignis im Endnutzerprozess (oder im Registry-Crawl) bis zum Open-Data-Snapshot. Jede Stufe markiert, ob PII theoretisch durchlaufen könnte und welche Defense-in-Depth-Schicht dort greift.

1. Stufen-Übersicht#

Stufen im Endnutzer-Prozess (1–8):

1. RAW Event (RAM, nie auf Disk) — install · session-start · runtime-tick · feature-flag · dep-load.
2. Sanitize — Hosts, Pfade, Env-Vars droppen oder hashen.
3. Cohort-Map — Identifier auf (project_id, version_id, cohort_id) mappen per lokaler Konfiguration.
4. Aggregate-Window — Tumbling 1h-Window (lokal auch 1min für Debugging).
5. k-Anon-Guard — wenn k_effective < k_min, dann in cohort_id="__small_cohorts" umschreiben.
6. Schema-Reject-PII — JSON-Schema-Validierung; verbotene Felder lehnen ab.
7. Sign + Attestation — ed25519-Signatur; deklarative Claims (Phase 1) / SNARK (Phase 2).
8. Egress-Buffer — lokale Disk, nur signierte Aggregate; Retry mit exponential backoff; max 30 min vor Verlust-Risiko.

Übergang über HTTPS POST /v1/submit (mTLS optional).

Stufen am Mirror (9–14):

9. Submission-Validierung — Signatur, Schema, k_effective ≥ k_min, Window-Plausibilität.
10. Append-Only-Log — Sigstore-Rekor-Hash-Chain, public verifiable.
11. Aggregate-Store — ClickHouse, Partition toYYYYMM(window_start).
12. Gossip / Pull-Federation — Mirror-zu-Mirror Konsistenz-Replikation.
13. Open Data Snapshot — täglich 00:00 UTC, Parquet + CSV.gz, CC-BY-4.0.
14. Open Data API — Read-only, keine Auth.

Parallel — Modus D (Registry-Scraping) läuft Mirror-intern und beginnt bei Stufe 3 (Cohort-Map auf bekannte PURLs); die Stufen 1, 2 entfallen, weil keine privaten Endnutzer-Events gelesen werden.

2. Was wo passiert — Verantwortlichkeiten#

3. Was niemals den Endnutzer-Prozess verlässt#

Folgende Begriffe sind in keiner Stufe ≥ 7 erlaubt — Schema-Reject-PII würde sie zurückweisen, und das ist Defense-in-Depth, nicht der primäre Filter:

• IP-Adresse, MAC-Adresse, Hostname, FQDN
• Username, E-Mail, OS-User, Process-PID
• Datei-Pfade aus dem Host-Filesystem
• Klartext-Git-Repo-Pfade oder Branch-Namen
• Maintainer-Klartextnamen oder Maintainer-E-Mails
• Inhalt von Environment-Variablen
• Zeitstempel feiner als die Window-Granularität (typ. 1 h)

Was darf drin sein:

• project_id (PURL — öffentliche Paket-Kennung)
• version_id (semver / ähnliche — öffentlich)
• cohort_id (vordefinierte Kategorie wie rt-runtime-mins, install-count)
• Banded numeric values (30-60, 100-1000)
• k_effective, k_min (Audit-Felder)
• Provenienz: submitter_did, Signatur, Mirror-Routing

4. Aggregat-Beispiele#

Modus A (Self-Instrumentation in OSS-Lib pkg:npm/example-lib):

{
  "project_id": "pkg:npm/example-lib",
  "version_id": "1.4.2",
  "cohort_id":  "rt-runtime-mins",
  "metric":     "runtime_minutes_band",
  "value":      "30-60",
  "k_effective": 23,
  "k_min":       5,
  "window_start": "2026-05-26T12:00:00Z",
  "window_end":   "2026-05-26T13:00:00Z",
  "source_mode": "A"
}

Modus D (Registry-Scraping über pkg:pypi/example-lib):

{
  "project_id": "pkg:pypi/example-lib",
  "version_id": "2.0.0",
  "cohort_id":  "dep-edges-from-public-manifests",
  "metric":     "observed_dependency_count",
  "value":      "1247",
  "k_effective": null,                     // Track A liest nur öffentliche Manifeste, k-Anon trivial
  "k_min":       null,
  "window_start": "2026-05-26T00:00:00Z",
  "window_end":   "2026-05-27T00:00:00Z",
  "source_mode": "D"
}

5. Outage- und Replay-Verhalten#

6. Querverweise#

• system-overview.md — Komponentensicht
• threat-model.md — STRIDE über diesen Fluss
• 03-risikoprofil.md — Risiken D-2-1 … S-2-3
• 05-zero-knowledge-vorschlag.md — ZK-Bausteine zur Härtung
• 02-poc-spezifikation.md — Phase-1-MVP-Tracks A + B