docs: drop circular severity-driver & unfounded silent-reservoir claims

Two corrections requested by review:
1. "Reachability drives severity" is circular — reachability is part of the
   bounty severity *definition* (single packet/tx), and severity_estimated is
   itself derived from root_cause/attack_path, so any root-cause->severity "lift"
   is doubly circular. Removed fig7 (lift + reservoir panels) and all lift
   numbers; §7 now states plainly that reachability is definitional, not a
   finding, and that we draw no root-cause->severity conclusions from estimated
   tiers.
2. The "silent reservoir" (N silently-patched fixes would rate High) is
   unfounded: we cannot tell whether those fixes were never reported or were
   reported via the bounty and then quietly patched. Removed entirely.

Replaced the priority map's estimated-severity axis with an honest one: fixes
per subsystem (observed volume) coloured by impact class from the bounty
*definition* (consensus/value = critical-if-exploitable; availability = DoS).
security_report §2/§4 reworked around observed volume + definitional impact
mapping; softened "silently" to "no CVE/advisory" throughout.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: grandchildrice

docs/analysis.md

@@ -6,16 +6,16 @@ security fixes across the eleven production Ethereum clients.*
 
 > **Key takeaways.** For anyone auditing Ethereum clients (or other blockchain /
 > consensus systems), the data says: (1) the **historical fix record — not the
-> CVE list — is the real map**, since ~94% of fixes ship silently; (2) the threat
-> profile is **availability- and consensus-centric** (untrusted network input
-> crashing or diverging a node), not the memory-corruption profile of generic
-> C/C++ datasets; (3) severe bugs concentrate in a few regions — **crypto, the
-> EVM, and the consensus state-transition** for chain-split/value bugs, **p2p /
-> sync / RPC** for DoS — and severity tracks **reachability × blast radius** (led
-> by integer-overflow, consensus-divergence, resource-exhaustion); (4) fixes are
-> **localized** (43% single-file); and (5) because **one spec is implemented
-> eleven ways in six languages**, a fix in one client is a variant lead for the
-> other ten. The actionable version is the audit field guide
+> CVE list — is the more complete map**, since ~94% of fixes carry no CVE or
+> advisory; (2) the threat profile is **availability- and consensus-centric**
+> (untrusted network input crashing or diverging a node), not the memory-
+> corruption profile of generic C/C++ datasets; (3) by the bounty's impact
+> definition, **consensus, EVM and crypto code is where an exploitable bug is
+> *critical*** (chain split / invalid value) while **p2p / sync / RPC is where
+> *DoS* lives**, so scope an audit accordingly; (4) fixes are **localized** (43%
+> single-file); and (5) because **one spec is implemented eleven ways in six
+> languages**, a fix in one client is a variant lead for the other ten. The
+> actionable version is the audit field guide
 > ([`security_report.md`](./security_report.md)); below, each finding is
 > cross-checked against the vulnerability-dataset literature (CVEfixes, BigVul,
 > Devign, CrossVul, DiverseVul, PrimeVul, Croft et al.).
@@ -119,51 +119,28 @@ across implementations. It is the diversity dimension DiverseVul and CrossVul
 argue reduces overfitting, obtained here **within a single well-specified
 domain**.
 
-## 7. What raises severity
-
-Severity here is the **Ethereum Foundation bug-bounty** grade (network-scale
-impact × single-packet/tx reachability), not CVSS. Only **6.4%** of rows were
-graded by the bounty, so we estimate the rest with an LLM decomposition
-(`impact_type` / `reachability` / `blast_radius`) calibrated against the graded
-rows (~60% exact / ~80% within ±1 tier on real severe bugs; method:
-[`severity_labeling.md`](./severity_labeling.md)). Combining graded + estimated
-tiers, **675 rows (30%) now carry a bounty tier** (176 High/Critical), enough for
-a robust reading.
-
-![Figure 7](figures/fig7_severity_drivers.png)
-
-**(a) Reachability × blast-radius is the severity driver** (Fig, left; n=176).
-Three root causes are *over-represented* in High/Critical: **integer_overflow
-(lift ×1.71)**, **consensus_divergence (×1.60)**, and **resource_exhaustion / DoS
-(×1.26)** — precisely the classes that map to the bounty's impact categories
-(invalid-ETH / chain split / network takedown). Conversely **`race_condition` has
-lift ≈ 0.29** and `unhandled_error/nil` ≈ 0.67: common bugs, but locally-triggered
-and low-blast-radius, so out of the "single-packet/tx, network-scale" severity
-model by definition. Severity tracks *what the bounty pays for*, not code-bug
-class alone.
-
-**(b) The silent reservoir — most severe fixes were never graded** (Fig, right).
-Of the **1,552 silently-patched client fixes, ~34% (532) carry a bounty-relevant
-tier when assessed** — **110 High, 242 Medium, 180 Low** — and the estimated-High
-ones are dominated by `liveness_dos` (89) and `chain_split` (21). Only 60 fixes
-in the whole corpus were actually bounty-graded, so the public severity record
-**understates the severe population by roughly an order of magnitude**; the
-`severity_estimated` / `severity_source` columns expose the would-be-rated slice
-explicitly (never overwriting the 60 ground-truth grades).
-
-**Reporting bias, not a severity map.** Among the *graded* rows, Geth dominates —
-not because Geth is buggier, but because it publishes GitHub Security Advisories
-while most clients patch silently. The graded slice measures **disclosure policy,
-not security posture**. And fix size does **not** separate severity (median ~51
-LOC high vs 45 overall) — you cannot spot a critical bug by diff size.
-
-*Takeaways for a researcher.* (i) Prioritize by **attacker-reachability ×
-subsystem** (p2p, rpc, crypto, consensus state-transition) rather than by whether
-a CVE exists. (ii) The **unrated `consensus_divergence` / `resource_exhaustion`
-rows are a hunting ground** for under-triaged severe bugs — the corpus surfaces
-exactly the silent, high-impact fixes that CVE-anchored datasets miss. (iii)
-Because one spec is implemented eleven ways, a severe fix in one client is a lead
-to look for its **silent analogue in the others** (§6).
+## 7. Severity — what the bounty counts, and what we can honestly say
+
+Severity here is the **Ethereum Foundation bug-bounty** grade: an impact reachable
+by a single packet / on-chain tx that splits the chain, takes the network down,
+corrupts value, or slashes validators (not CVSS). Two honest caveats bound what
+this dataset supports:
+
+- **Remote reachability is part of the *definition*, not a finding.** Because a
+  bug is only graded when it is remotely triggerable, "reachable bugs are the
+  severe ones" is true *by construction* — not an empirical result. What the data
+  adds is *where the impactful code is*: consensus / EVM / crypto for
+  chain-split/value bugs, p2p / sync / RPC for DoS (the audit priority map,
+  [`security_report.md`](./security_report.md) §2).
+- **Only 6.4% of rows were bounty-graded.** The rest are LLM-*estimated*
+  ([`severity_labeling.md`](./severity_labeling.md)), and that estimate is derived
+  partly from `root_cause` / `attack_path` — so we deliberately draw **no**
+  "root-cause X raises severity" conclusion from it, which would be circular.
+  Treat `severity_estimated` as a triage prior and filter to
+  `severity_source == bounty-graded` for ground truth. Note also that a graded row
+  reflects **disclosure policy** (which clients publish advisories), not relative
+  security posture, and fix size does **not** separate severity (median ~51 LOC
+  high vs 45 overall) — you cannot spot a critical bug by diff size.
 
 ## 8. Data quality and coverage
 

docs/figures/fig7_severity_drivers.png

@@ -14,82 +14,85 @@ languages, both layers). Numbers and examples are drawn from
 
 ## 1. What matters — the impact model that sets priorities
 
-Prioritize by **blast radius × remote reachability**, per the
+Rank findings by the **impact they could realize**, per the
 [Ethereum Foundation bug bounty](https://ethereum.org/en/bug-bounty/): a finding
-is severe if a **single network packet or on-chain transaction** can **split the
-chain**, **take the network down**, **create/steal ETH**, or **slash validators**.
-Everything below is ranked against that model — not CVSS, and not code-bug class
-in isolation. (Note: clients patch ~94% of issues *silently*, so **the historical
-fix record — not the CVE list — is the real map**; this guide is that map.)
-
-## 2. Where to look — the audit priority map
-
-![Figure 1 — audit priority map](figures/fig9_priority_map.png)
-
-Plotting every subsystem by **audit volume** (how many bugs it has produced) and
-**severity density** (share rated High/Critical) yields three actionable groups:
-
-**① Deep-audit first — low volume, high severity density.** Few fixes, but a bug
-here is disproportionately *critical* because it sits on consensus-critical or
-cryptographic paths:
-
-| Subsystem | fixes | %High/Crit | why it's severe |
-|---|---:|---:|---|
-| `crypto` | 40 | **15%** | signature/curve/hash errors → forgery, DoS, or divergence |
-| `evm` / `opcodes` / `precompiles` | ~80 | **12%** | any semantic disagreement = **chain split** |
-
-**② Highest priority — high volume *and* high severity.** The consensus and
-network core; audit breadth *and* depth here:
-
-| Subsystem | fixes | %High/Crit | dominant cause → entry |
-|---|---:|---:|---|
-| `p2p` | 82 | **17%** | resource_exhaustion ← malicious p2p message |
-| `fork-choice` | 93 | **13%** | missing validation ← crafted state |
-| `sync` | 140 | **11%** | resource_exhaustion ← malformed input |
-| `beacon-chain:block-processing` | 84 | **10%** | **consensus_divergence** ← malformed input |
-| `beacon-chain:attestation` | 106 | **9%** | missing validation ← malicious attestation |
-
-**③ Highest volume, mostly availability.** Most churn and most bugs, but they
-skew toward liveness/DoS rather than consensus — audit for resource limits and
-input validation:
-
-| Subsystem | fixes | %High/Crit | dominant cause |
-|---|---:|---:|---|
-| `state-trie` | 210 | 7% | improper_state_update |
-| `p2p-interface` | 181 | 7% | missing_input_validation |
-| `rpc` | 147 | 5% | resource_exhaustion |
-
-**One-line takeaway:** *audit `crypto`, the `EVM`, and the consensus state-
-transition for **critical** (chain-split/value) bugs; audit `p2p`, `sync`, and
-`RPC` for **availability** (DoS) bugs.*
+is Critical/High if a **single network packet or on-chain transaction** can
+**split the chain**, **take the network down**, **create/steal ETH**, or **slash
+validators**. This is the lens for everything below — not CVSS, and not code-bug
+class in isolation. (Most fixes carry **no CVE or public advisory**, so the
+historical **fix record — not the CVE list — is the more complete map** of where
+clients break; this guide is that map.)
+
+## 2. Where to look — by volume and impact class
+
+![Figure 1 — where fixes concentrate, by impact class](figures/fig9_priority_map.png)
+
+Two *observed* facts scope an audit: **where fixes concentrate** (volume — where
+bugs historically occur) and **which impact class each subsystem maps to** by the
+bounty definition (a consensus- or value-affecting bug is Critical/High *if
+exploitable*; an availability bug is a DoS).
+
+**Highest volume — most bugs land here.** `state-trie` (210), `p2p-interface`
+(181), `rpc` (147), `sync` (140), `beacon-chain:attestation` (106), `transactions`
+(99), `fork-choice` (93). Audit breadth first where the churn is.
+
+**Consensus- and value-critical — where an exploitable bug is *critical* by
+definition** (semantic disagreement → chain split; bad arithmetic → invalid
+value): the **EVM / opcodes / precompiles**, **gas & balance arithmetic**
+(`transactions`), **fork-choice**, the **beacon-chain state-transition**
+(`block-processing`, `attestation`), **state-trie**, and **crypto / KZG**. Note
+`crypto` and `evm` are **low-volume but consensus-critical** — few historical
+fixes, but a bug there is critical by definition, so deep-audit them.
+
+**Availability — audit for DoS:** `p2p`, `p2p-interface`, `sync`, `rpc`, `txpool`,
+`database` — dominated by resource-exhaustion and missing input validation; audit
+for resource bounds on peer-controlled work.
+
+Per-subsystem **dominant cause → entry point** (observed labels):
+
+| Subsystem | fixes | dominant cause → entry |
+|---|---:|---|
+| `state-trie` | 210 | improper_state_update ← malformed input |
+| `p2p-interface` | 181 | missing_input_validation ← malformed input |
+| `rpc` | 147 | resource_exhaustion ← malformed input |
+| `sync` | 140 | resource_exhaustion ← malformed input |
+| `beacon-chain:attestation` | 106 | missing_input_validation ← malicious attestation |
+| `fork-choice` | 93 | missing_input_validation ← crafted state |
+| `beacon-chain:block-processing` | 84 | consensus_divergence ← malformed input |
+| `p2p` | 82 | resource_exhaustion ← malicious p2p message |
+| `evm` | 40 | integer_overflow_underflow ← crafted state |
+| `crypto` | 40 | missing_input_validation ← malformed input |
 
 ## 3. The attack surface — where untrusted input enters
 
 ![Figure 2 — attack surface](figures/fig8_attack_surface.png)
 
-Severity requires a remotely-reachable trigger, so your taint sources are the
-places a node ingests adversary-controlled data. In order of exposure: **p2p /
-gossip** (messages, attestations, blocks, peers), the **untrusted-parsing** layer
-(RLP / SSZ / JSON decoders that run *before* validation), **on-chain transactions
-/ the EVM**, and **crafted chain state** (snap-sync, historical data). Start taint
-analysis here; the `internal_only` slice is not bounty-reachable.
+A remotely-triggerable bug originates where a node ingests adversary-controlled
+data — your taint sources. In order of exposure: **p2p / gossip** (messages,
+attestations, blocks, peers), the **untrusted-parsing** layer (RLP / SSZ / JSON
+decoders that run *before* validation), **on-chain transactions / the EVM**, and
+**crafted chain state** (snap-sync, historical data). Start taint analysis here.
+
+## 4. Rank a finding by the impact it could realize
 
-## 4. What raises severity — rank findings by class
+The bounty's impact categories map to concrete bug classes and code regions — use
+this to weight a finding by *what it could actually cause*, not by whether it
+carries a CVE:
 
-![Figure 3 — what raises severity](figures/fig7_severity_drivers.png)
+| Impact (bounty) | Realized by | Where it lives |
+|---|---|---|
+| **Chain split** | consensus_divergence | EVM opcodes/precompiles, gas accounting, fork-choice, beacon-chain state-transition |
+| **Invalid value / ETH** | integer_overflow, improper_state_update | gas & balance arithmetic, precompiles, state-trie |
+| **Network takedown (DoS)** | resource_exhaustion | p2p, rpc, sync, crypto |
+| **Validator slashing** | attestation / slashing validation | beacon-chain state-transition |
 
-Three root causes are over-represented among High/Critical fixes and should raise
-your priority on a finding: **integer overflow/underflow (×1.71)** — gas/balance/
-slot arithmetic that can mint invalid value or diverge; **consensus divergence
-(×1.60)** — the chain-split class; and **resource exhaustion / DoS (×1.26)**.
-Conversely, `race_condition` (×0.29) and `unhandled_error/nil` (×0.67) are common
-but usually *locally* triggered and low-blast-radius — real bugs, lower priority
-under this model. (Fig 3b: most such severe bugs were **never publicly graded** —
-another reason to trust the fix record over the CVE list.)
+*(Remote reachability is part of the severity **definition**, not a separate
+finding — a bug is only in scope if a single packet/tx can trigger it, which is
+exactly why §3's entry points matter.)*
 
 ## 5. The recurring vulnerability patterns — what to look for
 
-![Figure 4 — root cause & trigger](figures/fig2_rootcause_attack.png)
+![Figure 3 — root cause & trigger](figures/fig2_rootcause_attack.png)
 
 Six archetypes cover most of the corpus. Each is a hunting hypothesis: a
 mechanism, a trigger, and a **code smell** to grep for.
@@ -125,9 +128,9 @@ key. Subsystems fixed in *many* clients are the best variant-hunting grounds:
 
 **The method (N-day / variant analysis):** take a fix in client *A*, find the
 analogous code in *B…K* by `label`, and check whether the same guard exists.
-Because fixes are usually silent, a fix that landed in one client is frequently
-**not yet** mirrored in the others — a repeatable path to fresh findings unique to
-a multi-implementation ecosystem. Its sharpest form is **spec-divergence testing**
+Because fixes usually ship without an advisory, a fix that landed in one client is
+frequently **not yet** mirrored in the others — a repeatable path to fresh findings
+unique to a multi-implementation ecosystem. Its sharpest form is **spec-divergence testing**
 (P5): where clients implement the same pyspec/EELS function (EVM opcodes,
 precompiles, SSZ, epoch processing), fuzz edge cases for behavioural disagreement
 — the direct route to chain-split severity.
@@ -165,8 +168,9 @@ precompiles, SSZ, epoch processing), fuzz edge cases for behavioural disagreemen
    bug shared by clients with >33% combined share is a network-level event; a bug
    in one client is a lead to check the others. Diversity both mitigates and
    *reveals* bugs (variant hunting).
-5. **Prioritize by reachability × blast radius, not by CVE existence.** The
-   highest-impact bugs here were patched silently; a CVE-only view misses them.
+5. **Prioritize by the impact a bug could realize** (chain split / DoS / value /
+   slashing), not by whether it carries a CVE. Most fixes here have no CVE, so a
+   CVE-only view misses them.
 
 ## 9. Audit playbook (checklist)