It should not survive automatically. An exception is bound to a specific finding on a specific version. When the version changes, the old exception either closes because the issue is fixed, or must be re-evaluated because the new version may carry different findings.
What the exception was really about
An exception says: "advisory X on package Y at version Z, in service S, is accepted until date D for reason R." Change Y or Z and the sentence is no longer true. Tools that match exceptions on package name alone quietly extend old decisions to new code.
Three upgrade outcomes
| Outcome | What should happen to the exception |
|---|---|
| Upgrade fixes the advisory | Close it as fixed, with the date and the new version |
| Upgrade does not fix it | Keep it, but update the version in the record and re-check the evidence |
| Upgrade introduces new findings | Do not inherit, each new finding needs its own decision |
The second case deserves care. If the exception relied on "the vulnerable function is never called", a new version may change what is called. Re-run the reachability check rather than assuming.
Matching rules to insist on
- Match on advisory ID plus package plus version range, not name alone
- Keep the asset or service in the key
- Let version bumps flag the exception for review, not pass it silently
- Never let a range like "any version" be the default
Version ranges are a classic trap. An exception for "below 2.4.0" covers 2.3.9 but should not cover 2.4.1, and your tool should know the difference.
Automatic closure
When a scan shows the advisory no longer applies, the exception should close itself and record why. This avoids a pile of zombie records, a problem described in report unused suppression comments so old exceptions do not pile up.
It should also notify the owner. A closed exception is good news and a useful data point: it shows the process leads to fixes.
Transitive dependencies
When a direct dependency upgrade pulls a different transitive version, the finding may disappear or change. Treat the transitive package as its own subject. The post on transitive dependency you cannot upgrade covers options before accepting.
Downgrades and rollbacks
If a release is rolled back to the version that had the exception, the old exception does not come back to life if it already closed. Create a new request, because the time window and the approver's context have changed.
Checklist for upgrade pull requests
- List exceptions that reference the changed package
- Mark each as fixed, still applies or needs review
- Re-run scans on the new lockfile
- Update or close records in the same pull request
- Note the result in the PR description
Safeguard's dependency scanning and SBOM generation give you the before and after inventory, and its autonomous remediation can open fix PRs (off by default, every category on Manual).
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how components and versions are listed, since exceptions should key to exactly these.
Quick check
Should an exception follow a package to a new repository?
No. Scope includes the asset, so a new place needs its own decision.
What if the new version has the same advisory?
Keep the exception only after re-checking the evidence, and update the version in the record.
Last reviewed: 19 October 2026.
