How do you move risk acceptances and exceptions to a new scanner?

Export every dismissal and exception from the old tool, re-validate each against the current code, then re-apply the valid ones in the new tool with an owner, a reason and an expiry date. Do not bulk copy them. Old exceptions often hide stale decisions, and a migration is the best chance to clean them up.

What you are moving

• False positive marks.
• Accepted risks with a business reason.
• Ignored paths and files.
• Rule disablements.
• Temporary exceptions that should have expired.

Each carries a different level of trust.

Step by step

1. Export. Get the list with finding ID, location, reason, author and date. If the tool exports poorly, take screenshots and notes now, before access ends.
2. Triage the list. Mark each as still valid, no longer applicable, or unknown.
3. Re-test. Check whether the finding still exists in the new tool. Many old exceptions refer to code or versions that no longer exist.
4. Re-apply with metadata. Owner, reason, date and expiry. No exception without an end date or review date.
5. Approve high impact ones again. Accepted risks on critical findings deserve a fresh sign off.
6. Record the migration. Note which exceptions were dropped and why.

Watch for blanket rules

Path wide ignores and disabled rules cover more than a single finding. Treat them as policy decisions and ask whether the new tool's own settings make them unnecessary. Our post on tracking exceptions in a patch exception register gives the fields to keep.

Match findings carefully

Findings may not carry over because identifiers differ between tools. That is normal. For code findings, GitHub's SARIF documentation explains that matching depends on stable rule IDs and file paths, so expect to match on advisory ID plus package, or on rule plus location, instead.

Try it yourself

Click through it at your own pace, or open it full screen.

Click through the exploitability check and note the evidence it gives for or against a finding. That is the evidence an exception reason should contain.

Sources

• GitHub Docs: SARIF support for code scanning

A minimal exception record

For each re-applied exception, keep: what it covers, why it is acceptable, who approved it, the date, the review date and the compensating control if any. Put the record where the scanner can link to it, such as a ticket. When the review date arrives, the owner either renews with a new reason or removes the exception. This turns a pile of silent dismissals into a short, owned list.

Quick check

Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. You can try a free scan at gold.safeguard.sh/scan.

Last reviewed: 19 October 2026.