Not necessarily. A rising count of open vulnerabilities often means you started looking harder, added a scanner or widened scope. The count measures discovery effort as much as risk. To judge whether security got worse, compare exposure measures such as reachable, exploited or internet-facing findings, and note what changed in your tooling.
Why the raw count moves for reasons unrelated to risk
A vulnerability count is the product of two things: how many flaws exist and how well you can see them. Change the second and the number changes with no change in the first.
Common causes of a jump:
- A new scanner or a new rule set went live.
- More repositories, images or services were onboarded.
- A scanner began reading transitive dependencies it used to skip.
- An advisory database added a large batch of older records.
- A single popular library was flagged, and fifty services all report it.
None of these mean your code got worse that week. All of them move the chart.
The incentive problem
If a team is judged on a falling count, the cheapest way to improve is to look less. Turn off a noisy rule, scan fewer repos, narrow the severity filter. Goodhart's law is usually quoted as: when a measure becomes a target, it ceases to be a good measure. The Wikipedia entry traces the idea to economist Charles Goodhart's 1975 article on monetary policy. Security counts are a textbook case.
The reverse also happens. Teams that honestly expand coverage get punished with a worse-looking chart, and learn not to expand.
Separate discovery from exposure
Keep two families of numbers on the same page.
| Question | Measure that answers it |
|---|---|
| How much can we see? | Share of repos, images and services scanned; age of last scan |
| How much is there? | Open findings, grouped by how they were counted |
| How much of it matters? | Findings that are reachable, exploited in the wild, or on exposed assets |
| Are we getting faster? | Time from detection to fix, and findings opened versus closed per week |
The first row is a coverage number. If it rises, expect the second row to rise too, and say so in the report before anyone asks.
Steps to read a jump honestly
- Check the change log for scanners, rules, scope and data sources in the period.
- Re-run the old scope with the old settings if you can. If the old-scope number is flat, the jump is visibility.
- Look at the share of new findings that are reachable or known exploited. CISA's Known Exploited Vulnerabilities catalog is a public list of vulnerabilities seen exploited in the wild, and a match there deserves attention whatever the total is.
- Report the jump with its cause: "count rose after we added container scanning, exposure measures unchanged."
What good reporting looks like
State the count, the coverage and the cause in one line. Put a vertical marker on the chart wherever tooling changed. Do not set a target on the raw count. Set targets on time to fix for the findings that matter and on coverage, which are harder to game in a harmful direction.
If you want a starting point, Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates, and you can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the findings and look at how the list is prioritised rather than counted.
Quick check
Is a lower vulnerability count always better?
No. It can mean fewer flaws, or it can mean less scanning. Read it next to coverage.
Should we set a target on the total count?
Avoid it. A target on the total rewards looking less. Prefer targets on time to fix for important findings.
Sources
Last reviewed: 19 October 2026.
