Import a suppression only if it passes four tests: it has a written reason, a named owner, a recent date, and a component that still exists. Everything else should start fresh in the new scanner and be triaged again. A smaller imported set is more trustworthy than a bulk copy of years of stale exceptions.
The case for importing everything
Importing all of it feels safe. Nobody loses work, and the new tool's open count looks reasonable on day one. For small teams with a few dozen suppressions, a full import can be the right call, because re-triage is cheap.
The case for starting fresh
Suppressions rot. A package was unused two years ago and now sits in a hot path. A reason that read "test only" now refers to code that moved into production. A bulk import preserves the decision and loses the context that made it valid. The risk is not the exceptions you remember, it is the ones nobody can explain.
Starting fresh has a cost too: the first scan in the new tool will be loud, and engineers will feel they are redoing work.
Four tests to sort the pile
- Reason test. Is there a written explanation a stranger could follow? "Not an issue" fails. "Only loaded by the unit test runner, never packaged" passes.
- Owner test. Is a person or team named, and do they still exist? Exceptions owned by someone who left fail.
- Age test. Was the decision made or reviewed in the last 12 months? Pick your own window, but pick one.
- Existence test. Does the component and version still appear in a current scan of the default branch? If not, the suppression has no target.
A suppression that passes all four is imported. One that fails any is parked in a "review later" list, not deleted.
A simple sorting routine
Export the suppressions with their reason, owner and date. Add a column for each test and mark pass or fail. Sort by the number of failures. The top group is your import set, the bottom group is your archive, and the middle is a short list for a human to read.
For the imported set, set a review date. If the old tool had no expiry, give each one 90 or 180 days, so the next review does not depend on anyone's memory.
What to do with the archive
Keep it as a read only file, such as a CSV stored with your compliance records. Do not load it into the new tool as dismissed findings. If one of those findings reappears, the file is there for context, and the new scanner treats it as a fresh item to triage.
Make the policy explicit
Write a one paragraph rule and put it in the migration plan: "We import suppressions with a reason, an owner, a date within 12 months and a matching component. Others are re-triaged." Having the rule written down stops arguments during the cutover.
Quick check
What if the old tool never recorded owners?
Use the repository code owners as a proxy and flag the suppression for owner confirmation within the first review cycle.
Does re-triage mean the same work twice?
Partly, but it is bounded. Only suppressions that fail a test are re-triaged, and the first pass can use the old comment as a starting point.
Last reviewed: 19 October 2026.
