An imported suppression should reopen when something it depended on changes. Five triggers cover most cases: the package version changes, exploitability data changes, the review date passes, the code that used the package changes, or the scope of the project changes. Set these rules when you import, not later.
Why reopening is part of migration
A decision is a claim about a moment in time. "Not reachable" was true for a given version of your code and a given state of public knowledge. If either changes, the claim may not hold. A migration is a good moment to add reopen rules because you are touching every record anyway, and many old tools never had them.
The five triggers
1. Version change. If the package is upgraded or downgraded, the dismissal was about the old version. The finding should be re-evaluated against the new one. Most of the time it simply disappears because the fix was included, which is the happy outcome.
2. New exploitability data. An advisory may be updated, the vulnerability may be added to a known exploited list, or a public exploit may appear. A dismissal made when the issue looked theoretical may deserve another look. Define which signals matter to you and who gets notified.
3. Review date passes. Every imported exception gets a review by date. When it arrives, the finding returns to a reviewer, who confirms or closes the decision with a fresh note. Ninety or 180 days are common windows, but choose based on severity.
4. Code change. If the justification was about how the code uses the library, a change to those files is a reason to check again. Reachability style evidence is strongest here: a call path that did not exist last quarter might exist now.
5. Scope change. A service that was internal becomes internet facing. A test only package moves into the production build. A repository changes owner. The assumption behind the exception no longer holds.
How strict to be
| Severity | Review window | Reopen on version change | Reopen on exploit signal |
|---|---|---|---|
| Critical or high | 90 days | Yes | Yes |
| Medium | 180 days | Yes | Review only |
| Low | 12 months | Yes | No |
Treat the table as a starting point. The right values are the ones your team will actually follow.
Make triggers visible in the decision
For each imported suppression, record which trigger or triggers apply. A comment such as "Reopen on version change or code change in the payments module" tells the next reader what the decision relied on. It also lets you check later whether the trigger fired.
Check that the new tool enforces it
Some tools reopen on version change automatically, others need a policy rule. Test one case: import a suppression for a package version, change the version in a test project, and rescan. If the finding does not return for re-evaluation, add the rule or a scheduled report.
A note on Safeguard
Safeguard offers reachability analysis and continuous dependency scanning, which supply the kind of evidence that can justify or reopen a decision. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Open the demo and check how an exploitability view changes the picture of a finding. Think about which of those facts, if they changed, should reopen a dismissal.
Click through it at your own pace, or open it full screen.
Quick check
Do all suppressions need an expiry?
For anything with real risk, yes. For clear false positives, a long review window or none can be reasonable if you note why.
Who decides when a trigger fires?
The finding returns to its owner or reviewer, who confirms the old decision or changes it with a new note.
Last reviewed: 19 October 2026.
