Theory 24/Software Security /Risk theory/3 min
Severity Is Not Reachability
A critical bug in code you never call is not critical for you.
The practical risk of a vulnerability is bounded by whether the vulnerable code is reachable in a given deployment rather than by its severity score, so severity-ranked patch lists misallocate effort and reachability analysis should precede scoring.
01The evidence
- Empirical work on web application security shows that vulnerability prevalence and exploitability depend on how components are used in a particular application, not only on the properties of the component in isolation.ESEM, 2009
- The measurement problem is structural: severity scores are assigned to components, while risk accrues to deployments, and the two are related by configuration rather than by scoring.ACM record
02The tension
Patch management is driven by severity. Teams triage by CVSS and prioritise the highest scores, which is rational given the information available. But most critical-scored vulnerabilities are in unused paths, and the ones that matter are often medium-scored and reachable.
03The theory
A vulnerability can only be exploited if an attacker can reach the vulnerable code through the application's actual interfaces. Reachability is a property of the deployment, and it is binary or near-binary: either the path exists or it does not.
That makes risk a product of severity and reachability, and because reachability is often zero, the product is often zero. Ranking by severity alone therefore over-weights unreachable criticals and under-weights reachable moderates.
The prediction is that realised exploits should correlate with reachability better than with severity, and that a patch list ordered by severity-reachability product should outperform one ordered by severity on time-to-fix for exploited vulnerabilities.
The practical consequence is that reachability analysis, which is increasingly automatable, should precede scoring in the triage pipeline, and that severity scores should be reported as conditional on reachability.
04What this is not
Severity ranks by potential impact in the abstract. This ranks by impact given reachability, which predicts that most urgent patches are not the highest-scored ones.
05Predictions
- P1Realised exploits should correlate with reachability better than with severity.
- P2A reachability-weighted list should improve time-to-fix for exploited vulnerabilities.
- P3Most critical-severity vulnerabilities should be unreachable in typical deployments.
06What would refute it
Exploit occurrence tracking severity regardless of reachability would restore the scoring approach.
07What it would change
It would restructure patch triage and make reachability a first-class security metric.
08Evidence base
- Security of open source web applications — ESEMhttps://www.computer.org/csdl/proceedings-article/esem/2009/05314215/12OmNyGtjmg
- Security of open source web applications — ACMhttps://dlnext.acm.org/doi/10.1109/ESEM.2009.5314215