Because the scan compares your code to a database that changes daily. New advisories appear, scores are revised, exploitation status is updated and fixes ship. Your dependency list stayed the same, but the answer to the question "is any of this vulnerable?" did not.
What changes underneath you
CVSS itself has parts that move. The specification describes temporal metrics as measuring the current state of exploit techniques or code availability, which can change over time. The Known Exploited Vulnerabilities catalog is described by CISA as a living list, and adding an entry can flip a rule that keys off it. Fix availability changes too, as maintainers release patches.
| Input | How it can change | Effect on a gate |
|---|---|---|
| New advisory | Published for an old package | New failure, no code change |
| Score revision | Severity raised or lowered | Crosses or leaves threshold |
| Exploitation status | Added to a known exploited list | Hard block rule triggers |
| Fix available | Patch released | Unfixed filter stops hiding it |
| Scanner update | New detection logic | New or removed findings |
Telling drift from a regression
Ask three questions when a build suddenly fails:
- Did the lockfile or dependency manifest change? If not, it is probably data drift.
- Does the failing finding have a recent published date?
- Did the scanner or its database update in the last day?
If the answers point to drift, treat the failure as a real new finding, because it is one. The package was vulnerable all along. You just learned it today.
How to keep builds predictable
Two goals pull against each other. Developers want repeatable builds. Security wants fresh data. A workable split:
- Run pull request gates against the latest data, since stale data gives false comfort.
- Run a scheduled scan on the main branch daily, so drift shows up in a report before it hits an unrelated pull request.
- Record the scanner version and database date in each result, to explain differences later.
- Route drift failures to the owner of the affected service, not to whoever opened the pull request.
That fourth point matters for fairness. A developer fixing a typo should not inherit a fresh advisory. A good gate can separate "this change introduced it" from "this was already there".
Do not pin the database to avoid noise
Pinning the vulnerability database makes builds stable and blind. You will pass checks while known flaws sit in your code. Accept some drift as the price of accurate results.
Try it yourself
Open the continuous monitoring demo and watch how a new advisory appears against software that did not change.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning can be rerun against your inventory as advisories change, and its zero-day discovery adds new findings. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a failure on unchanged code a false positive?
Usually not. It is a true finding that was unknown yesterday.
Should I rerun the build to see if it clears?
No. A rerun gives the same answer unless the data changed again. Fix or formally except the finding.
Sources
Last reviewed: 19 October 2026.
