A build can fail on a vulnerability you did not add because the advisory database changed, not your code. A new advisory, a raised severity, or a freshly detected transitive package can turn a green pipeline red overnight. The fix is to separate new risk from existing risk in the gate.
The three common causes
A new advisory landed. Your lockfile did not change, but the database the scanner reads did. A package that was clean yesterday now has a published advisory, so the same commit scans differently. We cover this pattern in more detail in scan results changed overnight with no code change.
The scanner changed. A new scanner version, a new rule, or a new data source can surface findings that were always present. Nothing got worse. You just got a better view.
A transitive dependency moved. If your lockfile is not committed or not honored by the build, a floating range can pull a newer version of something three levels down. The finding is real, but nobody on your team chose it.
How to tell which one you are in
Run three quick checks before you touch any code.
- Re-run the scan on the last green commit. If it now fails too, the cause is outside your change.
- Diff the lockfile between the last green build and this one. No diff means the data changed, not the dependencies.
- Look at the finding's published date. A date after your last green build points to a new advisory.
Write down what you found in the pull request. It saves the next person the same hunt.
What the gate should do about it
A gate that fails every pull request because of an old finding punishes the wrong person. A better design splits two questions.
| Question | Who owns it | Typical gate behavior |
|---|---|---|
| Did this change add a new finding? | The author | Block until fixed or excepted |
| Does the branch carry an existing finding? | The service owner | Ticket with an owner and a due date |
GitHub's own code scanning documentation describes this split for code alerts: new alerts on lines changed in a pull request appear as annotations, while the full set of branch alerts lives in a separate view. Dependency findings can follow the same shape, with the gate keyed to what the diff introduced.
If you must keep a hard gate on existing findings, give it an expiry. An exception with an owner and an end date is better than a failing build that everyone learns to bypass.
What to do right now
If you are blocked today, ask three things. Is there a fixed version? Does the vulnerable code path run in your service? Can the owner grant a short, dated exception? Our exception request template shows the fields to include.
For the longer term, pin versions through a committed lockfile, run the scan on a schedule as well as on pull requests, and send the scheduled results to the service owner rather than to whoever happens to push next.
Safeguard runs dependency scanning and reachability analysis, so a finding can be marked as reachable or not before it blocks anyone, and policy gates can be set to evaluate only what a pull request introduces. You can try a scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch which findings block the merge and which only create a ticket.
Quick check
Is it safe to just re-run the build until it passes?
No. If the cause is a new advisory, a re-run gives the same result, and if it passes by luck you have hidden a real finding. Check the lockfile diff and the advisory date first.
Should I add an exception right away?
Only after you check for a fixed version and whether the code path is reachable. If you do add one, set an owner and an expiry date.
Sources
Last reviewed: 19 October 2026.
