No. An open vulnerability count can fall because findings were fixed, but also because scans failed, filters changed, assets were removed, the counting unit was altered or advisory data lagged. Treat a drop as a question until you have matched it to evidence of real change.
Reasons a number can fall
| Cause | Real risk reduction? |
|---|---|
| Version upgrades and removals | Yes |
| Assets decommissioned | Yes, if truly gone |
| Scan failed or covered less | No |
| New default filter, such as hiding suppressed items | No |
| Counting unit changed | No |
| Findings closed as not seen after a partial scan | No |
| Fewer advisories published that month | Partly outside your control |
A drop checklist
- Match to change. Count merged dependency upgrade pull requests and removed components in the same period. Do they plausibly explain the drop?
- Check scan health. Did the number of completed scans and components per scan hold steady? See failed scans can look like fixed vulnerabilities.
- Check filters. Compare the dashboard's current filters with those of the previous period.
- Check the unit. Confirm nothing changed in how rows are grouped.
- Check asset changes. Compare the asset list at both dates.
- Check for reopens. Watch the following weeks for findings that come back.
Also read what did not fall
Total counts are dominated by many small items. Look at the oldest open items and at the highest severity ones separately. A falling total with a steady count of aged critical items says that easy work is being done and hard work is waiting.
Look at inflow and outflow
Plot new findings per week and resolved findings per week as separate lines, rather than only the stock. A drop in the stock with flat resolution and falling inflow means fewer issues are arriving, perhaps because fewer advisories were published or a scan is missing things. A drop with high resolution is a better sign.
Cohort view
Take the findings open at the start of a period and track what happened to that group: fixed, suppressed, still open. This avoids confusion from newly arriving items and shows whether older work is actually moving.
Writing it up
When you report a decrease, give the cause alongside it: "down because of two library upgrades across the payments services", not "down". If you cannot name the cause, say the cause is under review. That habit makes the metric harder to game and easier to trust.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Continuous monitoring and fix pull requests give evidence for why a finding closed. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and follow one finding from detection to resolution, noting which number on screen changes and which stays put.
Click through it at your own pace, or open it full screen.
Quick check
What is the fastest check on a sudden drop?
Compare component counts per scan before and after. A big fall in components usually means a scan problem, not a fix.
Why look at inflow and outflow?
The open total hides both. Separate lines show whether you are resolving more or simply receiving less.
Last reviewed: 19 October 2026.
