Keep one decision record outside either tool, keyed on package, version and advisory ID, with a reason, an owner and an expiry. Then translate that record into each scanner's own ignore format. The record is the source of truth, and the tool configs are generated from it.
Why decisions get lost
You mark a finding as accepted in tool A. Tool B has never heard of that decision, so the finding appears again, and a developer spends half an hour re-deciding it. Worse, two people may decide differently. Over months the two tools drift apart and nobody remembers why.
Suppression formats are also not portable. Each tool has its own file or console, its own matching rules and its own expiry behavior. Some match on advisory ID, some on package, some on path. A rule that is narrow in one tool can be broad in the other.
The decision record
Store it as a plain file in version control. One row per decision.
| Field | Why it matters |
|---|---|
| Ecosystem and package name | Identifies the package, using one normalized form |
| Version or range | A decision for 1.2.3 does not cover 1.3.0 |
| Advisory ID plus aliases | One flaw can carry several IDs, so list them |
| Decision | Not affected, accepted risk, or fix scheduled |
| Reason and evidence | A sentence plus a link, for later review |
| Owner | A named person or team |
| Expiry date | Forces a second look |
The OSV schema says aliases are symmetric and transitive, which makes them a sound basis for matching the same flaw across databases.
Steps to port decisions
- Write the record first. Do not start in a tool console.
- Generate each tool's ignore file from it. A small script reading the record and emitting the right format keeps the two in step.
- Match narrowly. Use package, version and advisory together. Avoid blanket rules by package alone.
- Set the expiry in both. If a tool has no expiry feature, the record's expiry date drives a review reminder.
- Review on a schedule. Monthly is enough for most teams. Remove entries whose package version is gone from the tree.
- Log tool behavior. Note any tool that ignores a rule silently, so you know which ignores are real.
Not affected is a different statement
Accepting a risk and saying a flaw does not affect you are different claims. "Not affected" means the vulnerable code or condition is absent or not reachable in your use, and it needs evidence. "Accepted" means the flaw applies and you chose to live with it for now. Record them separately, because an auditor reads them differently. If you publish exploitability statements to customers, keep that process distinct from this internal register.
What to watch for
- Version drift. When the package version changes, the old decision no longer applies. Treat the new version as a fresh finding.
- Stale data. A not affected decision made last year may be wrong after a code change that makes the flaw reachable.
- Over broad rules. A path based ignore can hide a different package that lands in the same folder later.
Quick check
Can I rely on one tool's ignore list for both?
No. Formats and matching rules differ. Generate each from a shared record instead.
How long should an accepted risk last?
Set a short expiry, often a quarter, and extend it only with a fresh look at the reason.
Sources
Last reviewed: 19 October 2026.
