Threat model — Prometheus v2

Translation. The German version of this document is canonical (CLAUDE.md, § Sprache & Tonalität). Where the two differ, the German text decides. Read the German original →

A STRIDE-based threat analysis of the four capture modes and the federated mirror architecture. For each component, threats are identified, mitigations named, and their effect on residual risk (see 03-risikoprofil.md) linked.

1. Trust boundaries#

Three trust boundaries — T1 (end user ↔ internet) · T2 (submitter ↔ mirror) · T3 (mirror ↔ mirror)

T1 — the trust boundary between the end-user process (OSS lib with SDK, end-user agent, hybrid aggregator) and the outside world.
T2 — the trust boundary between the submitter (local aggregator) and the mirror operator. This is where the signed aggregates cross HTTPS / mTLS.
T3 — the trust boundary between independent mirror operators (gossip / pull federation). Relevant from phase 2 onwards.

2. STRIDE per component#

2.1 OSS lib with self-instrumentation (mode A)#

Threat	Example	Mitigation
S Spoofing	A malicious library version embeds the SDK and fakes reach for `pkg:npm/example-lib`	DID binding to the maintainer key; the mirror verifies the signature. Risk: `I-2-1` (library spoofing).
T Tampering	An end user manipulates SDK state and produces fake runtime	The k-anon guard only takes effect from `k_min`; Sybil with a single host is useless. Risk: `M-2-1`.
R Repudiation	A submitter claims never to have submitted	Signature + immutable audit log.
I Information disclosure	The SDK leaks PII from third-party processes (a bug)	Schema-reject-PII (stage 6) + mirror-side validation (stage 9). Risk: `D-2-2`.
D Denial of service	The SDK floods the aggregator with events	Local backpressure + rate limit; under overload a drop sample (not the submission loop).
E Elevation of privilege	The SDK escalates host process privileges	The SDK runs in the library context, without special rights; OS sandboxing (e.g. seccomp) is recommended for sensitive hosts.

2.2 End-user agent (mode B)#

Threat	Example	Mitigation
I Information disclosure	The agent inadvertently reads `~/.git/`, local paths, repository names in the clear	Stage 2 (sanitize) + schema-reject-PII. Risk: `D-2-3`.
T Tampering	Malicious code swaps out the agent binary	OS package signing, reproducible builds; distribution through established package managers.
D DoS	The agent consumes CPU/RAM in the host system	Footprint budget K7 + hard limits.
E EoP	The agent runs as root for the dep-tree scan	Recommendation: user mode + a read-only mount; root only for system-wide discovery.

2.3 Local aggregator (mode C)#

Threat	Example	Mitigation
I Disclosure	A RAM dump contains raw events	Raw events only in RAM/tmpfs; disk stores exclusively anonymised aggregates (stage 8).
T Tampering	Manipulating the aggregator lowers `k_effective`	Phase 1: the mirror checks `k_effective >= k_min` declaratively. Phase 2: ZK-SNARK attestation (see `05-zero-knowledge-vorschlag.md`, building block B).
D DoS	Submission queue overflow	Egress buffer with a 30-minute loss threshold (K5), exponential backoff.

2.4 Registry scraper (mode D)#

Threat	Example	Mitigation
S Spoofing	A manipulated registry response	A hash of the manifest source file in the provenance stamp; cross-registry plausibility (npm download stats vs. GitHub stars).
T Tampering	The mirror operator manipulates the manifests read in	Open-source scraper code; every mirror can run its own scraper and cross-check aggregates (gossip).
I Disclosure	The scraper reads private GitHub repositories	Whitelist-only on public endpoints + token scoping.
D DoS	Registry API rate limits	Backoff + cached manifests; risk: `S-2-3`.

2.5 Mirror#

Threat	Example	Mitigation
S Spoofing	An attacker registers a "pseudo mirror" with forged aggregates	A federation registry with signature confirmation; on suspicion of an eclipse, disclosure in the mirror's own status endpoint. Risk: `M-2-2`.
T Tampering	An insider changes aggregates retroactively	Append-only log (Sigstore Rekor); manipulation would break the hash chain and is visible across mirrors.
R Repudiation	A mirror claims not to have received a submission	The submitter keeps the `submission_hash` locally; a gossip diff reveals the eclipse.
I Disclosure	Research attack: mosaic re-identification from aggregates	k-anon thresholds (`k=5`, `k=25`), DP noise in phase 2 (see the ZK building block), minimum cohort size. Risk: `D-2-1`.
D DoS	Sybil submissions flood the mirror	Rate limit per DID at the ingress (`ADR-v2-0007`: ≤ 24 submissions/DID/24 h for modes A/B/C); exceeding it → `429` before acceptance, no audit log entry, and the aggregate stays in the submitter's egress buffer to be sent again. Plus cross-mode plausibility (track A vs. D) and burn-in for new DIDs. Proof of work is rejected with reasons in `ADR-v2-0007`. Risk: `M-2-1`.
E EoP	Malicious code in the mirror stack obtains write access to the aggregate store	Container isolation, signed releases, regular audits (Apache-2.0 open-source stack).

2.6 Cross-mirror federation (T3)#

Threat	Example	Mitigation
Eclipse attack	An attacker separates mirror A from mirror B by BGP hijack or similar	A gossip diff shows diverging `audit_log.head`; phase 3 threshold consensus (≥ 2 of 3 mirrors must confirm an aggregate).
Sybil federation	An attacker operates several "independent" mirrors	Geographic / organisational diversity in federation registry audits; recorded in `06-offene-punkte.md` as a P1 blocker.
Consensus drift	Mirrors have differing views of `submission_hash`	Phase 2: bidirectional gossip + diff resolution; phase 3: threshold consensus decides canonically.

3. Re-identification risk (cross-cutting)#

Even without PII fields, aggregates can identify people — mosaic inference is the primary attack vector:

Niche project + small cohort: pkg:npm/very-specific-tool has only 3 maintainers; even k=5 runtime sessions plausibly point at one person.
Correlation attack: a vendor with its own CRM data can cross-reference a reach snapshot with its customer metrics in order to de-anonymise individual end users.

Mitigations:

k_min = 5 as the lower bound, k_min = 25 for modes B/C because of the end-user depth.
A ban on combined cohort_id multi-axes that would effectively yield k=1 (e.g. region × OS × runtime-band).
DP noise (Laplace mechanism, ε ≤ 0.5) for particularly sensitive metrics in phase 2.
A research disclosure policy: every Open Data publication carries a statement on re-identification risk.

4. What Prometheus does not protect against#

Deliberately out of scope:

End-device compromise: if the host is already infected with malware, modes A/B are not trustworthy anyway. Protecting the device is a matter for the OS and AV.
Maintainer identity theft: whoever holds the maintainer key can sign. Key rotation and a hardware key (YubiKey or similar) are the maintainer's duty.
Upstream supply-chain attack: if npm install already ships a manipulated binary, that is an SBOM / supply-chain problem, not in Prometheus scope.

5. Cross-references#

03-risikoprofil.md — quantified risks in the D/I/M/S families
05-zero-knowledge-vorschlag.md — ZK hardening (SNARK, Public Audit Log, mix-net, threshold consensus)
data-flow.md — the stage view of anonymisation
ADR-v2-0001 — submission protocol
06-offene-punkte.md — anti-Sybil strategy, eclipse disclosure format