The code did not change; the knowledge about it did. New advisories, updated affected-version ranges, daily exploit probability scores and additions to the known exploited list can all turn a release that passed last month into one that fails today, without a single line of code moving.
A scan is a snapshot of two things
A vulnerability scan compares what is in your software with what is publicly known. The first half is fixed once you build. The second half moves every day. So a "pass" really means: "against what we knew on that date, nothing blocked."
That is why release evidence needs a timestamp and, ideally, the version of the vulnerability data used. Without them, a later failing scan looks like a contradiction when it is simply new information.
What changes under a stable release
| Change | Effect on an unchanged release |
|---|---|
| New advisory published for a component | Release now has a finding |
| Affected version range corrected | Finding appears or disappears |
| Exploit scoring updated | Priority shifts; EPSS scores are published daily |
| Added to CISA KEV | Gate rule for known exploited now triggers |
| Fix released upstream | A blocked finding becomes fixable |
EPSS estimates the probability of exploitation in the next 30 days and is published every day for every CVE, so the ordering of your findings can change without any new CVE appearing. The CISA KEV catalog likewise grows as exploitation is observed.
How to handle it in a regulated process
- Separate the release-time result from later results. Both are valid evidence of different things.
- Do not edit the original record. Add a dated follow-up entry.
- Decide in policy which later findings trigger action on already released versions, for example known exploited and reachable.
- Give the follow-up its own remediation clock, starting from when you learned of it, not from when you shipped.
- Tell customers according to your commitments if a shipped release is affected.
Avoid two mistakes
The first mistake is re-running the gate on old releases and blocking them retroactively. A shipped release is already out; the response is remediation and, where relevant, a new release, not a failed check on a historical record.
The second is the opposite: never rescanning. That leaves you blind to exactly the situation described here.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a newly disclosed issue is matched against components that were already shipped.
Safeguard offers zero-day discovery and continuous dependency scanning, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Does a later finding mean the release gate failed?
No. The gate judged what was known at the time. A later finding is new information that needs its own response.
How often should released versions be rescanned?
Often enough to match your remediation commitments. Daily or on new advisories is common for exposed software.
Sources
Last reviewed: 19 October 2026.
