Topic starter
24/10/2026 8:54 pm
TL;DR: Per-CVE reachability can separate imported dependencies from actually called vulnerable functions, according to Nullify. Vulnerability triage can then use auditable evidence and confidence thresholds instead of package-level max-severity rollups.
Editorial analysis by NHI Mgmt Group, based on content published by Nullify: “Per-CVE Reachability: Doing the Triage Without the Headcount”.
Key questions
Q: Why do package-level vulnerability scores often overstate real risk?
A: Because a package can contain many vulnerable symbols, and most applications use only a subset of them.
Q: What are the signs that alert automation is failing?
A: Common signs include endless repeat investigations, high analyst turnover, brittle playbooks that break when conditions change, and large numbers of alerts still reaching human review after automation is in place.
Q: How should security teams prioritise CVEs inside bundled dependency findings?
A: Treat the bundle as a queueing mechanism, not a remediation decision.
Practitioner guidance
- Instrument reachability before severity downgrades Require package import checks and symbol-level call analysis before any CVE can move below its scanner-assigned severity.
- Separate confidence thresholds from suppression rules Allow only high-confidence symbol evidence to justify large downgrades, and keep uncertain negatives from hiding reachable issues.
- Persist evidence with every triage decision Store the call sites, confidence level, and method for each CVE so reviewers can audit why a finding was reprioritised.
Bottom line: Dependency counts alone do not tell you which vulnerabilities matter, because bundled findings can include CVEs the application never reaches.
Glossary terms: Per-CVE Reachability, Symbol-Level Analysis, Severity Rollup, Confidence threshold
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:12 am
Per-CVE reachability is a governance problem before it is a tooling problem. The central failure mode is assuming package presence equals exploitable exposure. That assumption breaks down in modern dependency graphs where one package can contain many symbols, only a subset of which are callable from the application. The practical implication is that teams must govern triage outcomes on code-path evidence, not on bundle-level fear.
A question worth separating out:
Q: How do organisations keep AI triage from hiding real vulnerabilities?
A: By making AI a bounded decision layer rather than a suppression engine. Keep unknowns visible, require confidence thresholds for downgrades, and preserve the full evidence chain for audit. AI should reduce repetitive analysis, not override the scanner when the model cannot prove absence with high confidence.
👉 Read our full editorial: Per-CVE reachability is turning vulnerability triage into control logic
This post was modified 6 days ago by NHI Mgmt Group