CISOs should measure open source risk by evidence and speed, not by raw finding counts. Five measures carry most of the signal: inventory coverage, known exploited exposure, reachable flaws past deadline, time to fix, and the share of unknowns. All five can be computed from data most teams already have.
Why are raw counts a poor measure?
A count of open vulnerabilities rises with the number of dependencies and the number of scanners, and falls when a scanner stops working. It tells you about the tool, not the risk. Two teams with 500 findings may be in very different positions if one has none exploited and the other has three.
NIST SP 800-161 Rev. 1 frames the underlying concern: reduced visibility into how technology is developed, integrated and deployed. Metrics should show how much visibility you have and what you do with it.
What are the five measures?
1. Inventory coverage. What share of applications and builds produce a current SBOM? The 2026 minimum elements expect an SBOM for each version and coverage of all components including transitive dependencies. Below 100 percent coverage, every other number has a blind spot.
2. Known exploited exposure. How many components in production match the CISA KEV catalog? The target is zero, and the number is easy to explain to a board.
3. Reachable flaws past deadline. Of findings where vulnerable code is actually called, how many are older than your policy allows? Add EPSS to rank the rest: it publishes a daily probability that a CVE will be exploited in the next 30 days.
4. Time to fix. Median and 90th percentile days from advisory to fix in production, for reachable or exploited flaws. The tail matters more than the average.
5. Share of unknowns. Repositories with no SBOM, components with no version or identifier, and artifacts with no provenance. The 2026 guidance asks authors to mark unknown information explicitly, and you should count it for your own estate too.
What about project health?
For projects you adopt, the OpenSSF Scorecard automates checks of a repository's security practices and can run on repositories you do not own. Use it as an input to adoption decisions and to flag your riskiest dependencies, not as a score to publish.
What does a one page report look like?
Constructed example: a quarterly page lists SBOM coverage at 84 percent of applications, up from 71. KEV matches in production: two, both fixed within policy. Reachable flaws past deadline: seven, owned by three teams. Median time to fix a reachable flaw: 6 days, 90th percentile 31. Unknowns: nine repositories with no SBOM, named. The CISO's ask is one line: fund SBOM rollout for the nine.
What should you not measure?
Avoid vanity numbers: total dependencies scanned, total findings closed and scanner coverage by raw repository count. They rise with effort, not with safety. Avoid composite risk scores whose inputs nobody can explain, since a board will ask how the number moves and nobody will know.
Prefer measures where someone can name the action that moves them. If a number moves and no one can say why, drop it or define it better.
What to do
- Define each measure in a sentence, with its data source.
- Automate collection from SBOMs, KEV and reachability data.
- Report coverage first, so readers know how much the rest represents.
- Show medians and 90th percentiles for time to fix.
- Name the owners of items past deadline.
- Review the measures yearly, and retire ones that no longer change decisions.
- Avoid targets that reward hiding findings, such as "reduce the count by 30 percent".
Safeguard's SBOM and dependency scanning, reachability analysis and policies and gates produce much of this data for scanned code. Which numbers you set as targets is your call.
How often should you review the numbers?
Monthly for operations and quarterly for leadership. Operations teams need the list of items past deadline and their owners. Leadership needs trends: coverage up or down, exploited exposure at zero or not, tail time to fix improving or not. Reporting the same five measures every time lets people see change, and a change in definition should be flagged in the report so no one reads a trend that is really a new counting method.
Quick check
Is a lower finding count always better?
No. It can fall because coverage fell or a scanner broke. Read it with coverage.
Should we publish these numbers to customers?
Share what contracts and trust require. Publish definitions with any number so it can be understood.
Sources
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices (page notes a later update supersedes it)
- CISA Known Exploited Vulnerabilities Catalog
- FIRST: Exploit Prediction Scoring System (EPSS)
- CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
- OpenSSF Scorecard
Last reviewed: 18 October 2026.
