Scan results change without a code change because the data around your code keeps moving. New advisories are published, old ones are withdrawn, scores are revised, exploit signals update daily, and the scanner itself gets new rules. Your code is a fixed input, but the vulnerability knowledge it is checked against is not.
Five causes
1. New advisories. A vulnerability that existed all along gets published. Your version was affected yesterday; you just learned it today. This is the most common reason for a new finding.
2. Withdrawn or corrected advisories. Records can be withdrawn. The OSV schema has a withdrawn timestamp for this, and a missing field means the entry stands. A finding can disappear because the source no longer supports it.
3. Changed ranges. An advisory's affected range can be corrected. A version that was caught may now fall outside it, or the other way around.
4. Updated exploit signals. EPSS scores update daily and estimate the probability of exploitation in the next 30 days. A CVE can also be added to the CISA Known Exploited Vulnerabilities catalog, with a date added. The finding is the same, but its priority moves.
5. Scanner changes. A new release may add ecosystems, improve version parsing or change how severity is shown. Results then shift even when advisories did not.
What did not change
Your inventory. If a lockfile and build are identical, the component list is identical. That makes a useful diagnostic: compare the inventory from the two runs. If it is unchanged, the difference is on the data or tool side.
A short diagnosis routine
- Export both results with timestamps.
- Diff the component lists. Same? Then the cause is data or tool.
- For each new finding, check the advisory's published date.
- For each missing finding, check whether the advisory was withdrawn or its range edited.
- For priority changes, look at exploit data dates.
- Note the scanner version for each run.
Write the outcome in one line per finding, such as "new advisory published 17 October" or "withdrawn upstream". That sentence is what a manager or auditor wants to read.
What this means for process
A scan is a statement about a moment. A clean result last month says little about this week. Scheduled rescans of stored inventories catch new advisories without rebuilding anything.
It also means you should keep the data version with each result. Without it, you cannot explain why two runs differ.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new advisory creates a finding on code that did not change.
Where Safeguard fits
Safeguard's continuous scanning of dependencies and SBOMs is built for this case: new advisories are checked against existing inventories. Try the free scan and compare results over time.
Quick check
Is a new finding on old code a scanner bug?
Usually not. The vulnerability was likely published after your last scan, so the code was always affected.
Why did a finding vanish?
The advisory may have been withdrawn or its range corrected, or you may have fixed it. Check the source record.
Sources
Last reviewed: 19 October 2026.
