TL;DR: Executive vulnerability reporting breaks down when asset data is unreliable, scanner precision is poor, and provenance is unknown, because a board-friendly metric is only as sound as the findings underneath it, according to Kusari. The practical shift is away from counting vulnerabilities toward measuring precision and recurrence, which exposes wasted remediation capacity and recurring exposure classes.
NHIMG editorial — based on content published by Kusari: Precision and provenance are the metrics that make vulnerability data usable
Questions worth separating out
Q: What breaks when vulnerability findings are treated as board-grade risk without precision testing?
A: The metric collapses into filtered noise, because false positives and misplaced findings consume remediation capacity without reducing actual exposure.
Q: Why does provenance matter more than total vulnerability counts in supply chain security?
A: Because counts do not tell you whether the vulnerable component should have been there, how it entered the build, or whether anything in production can reach it.
Q: How do you know if vulnerability remediation is actually working?
A: Look for reduced mean time to remediate, fewer reopened findings, and verified closure rather than ticket closure alone.
Practitioner guidance
- Measure scanner precision on a single team queue Track every finding the team acted on during one sprint, then verify whether each one mapped to a real deployed exposure.
- Prove artifact provenance before counting exposure Select a sample of findings and trace each one back to the exact dependency, transitive parent, and deployed artifact.
- Replace ticket volume with recurrence tracking Choose one vulnerability class and chart its incidence over the last two to six months rather than counting closed tickets.
What's in the full article
Kusari's full analysis covers the operational detail this post intentionally leaves for the source:
- How the precision metric was calculated across real codebases and deployed artifacts
- The false-positive comparison methodology behind the scanner evaluation
- The dependency provenance questions teams should ask at build and release time
- Why recurrence tracking is more useful than raw vulnerability counts for executive reporting
👉 Read Kusari's analysis of vulnerability precision and provenance metrics →
Vulnerability precision and provenance: what boards are really missing?
Explore further
Precision is now a governance control, not just a tooling quality issue. When vulnerability data is half noise, executive reporting becomes a capacity sink rather than a risk signal. That means precision belongs in the same governance conversation as asset inventory and ownership, because the metric drives where scarce engineering time is spent. Practitioners should treat precision as a measurable control objective, not a vendor claim.
A question worth separating out:
Q: What is the difference between precision and recurrence in vulnerability reporting?
A: Precision measures how many acted-on findings were actually real, while recurrence measures whether the same class of exposure is still appearing over time. Precision tells you whether the instrument is trustworthy, and recurrence tells you whether the system is improving. Both are needed for executive reporting.
👉 Read our full editorial: Precision and provenance are the metrics that make vulnerability data usable