Store every triage decision in a file in your own repository, with the finding id, package, reason, owner and expiry date. Use a standard exchange format such as VEX where your tools support it. Then a move from an open source scanner to a managed platform, or back, loses no history.
Why this is the real exit cost
Most people think of exit paths as data export from the vendor. For triage, the bigger risk is that decisions live only inside a tool's interface or in an ignore file with a private syntax. After a switch, hundreds of reviewed findings reappear as new. Developers lose trust and the old reasoning is gone.
What to record per decision
| Field | Why |
|---|---|
| Vulnerability id (CVE or advisory id) | Matches across tools |
| Package, version and location | Scope of the decision |
| Decision | Not affected, accepted risk, false positive, fix planned |
| Reason in plain words | Lets a reviewer judge later |
| Evidence link | Ticket, code reference or test |
| Owner and approver | Accountability |
| Expiry or review date | Stops permanent exceptions |
| Date and tool that produced the finding | Audit trail |
Use a standard where you can
CISA publishes minimum requirements for Vulnerability Exploitability eXchange (VEX) documents, which are a way for a supplier to state whether a product is affected by a vulnerability. Not every scanner reads or writes VEX, so check support in your tools before relying on it. Our post on building a VEX document for consumers shows the structure.
Where a standard is not available, keep a plain structured file, such as YAML or JSON, that a script can convert later. A spreadsheet is better than nothing but harder to keep in step with code.
Steps
- Inventory where decisions live today: ignore files, tool settings, tickets, chat messages.
- Define the record above and a single location in the repository.
- Write a small exporter that pulls decisions out of the current tool into that location.
- Require new decisions to go through a pull request that edits the file, so each has a reviewer.
- Test portability. Take ten decisions and see if they can be imported or translated for another tool, even in a trial.
- Review expiries monthly. Our guide on migrating risk acceptances to a new tool covers the move itself.
Why it helps in both directions
If you are on an open source scanner, portable records make a later platform purchase cheaper to adopt. If you are on a managed platform, they make renewal conversations honest, since leaving is a real option. That is good for you and also keeps vendors accountable.
Safeguard supports policies, exceptions and compliance evidence, and you can start with a free scan at gold.safeguard.sh/scan. Ask about export formats for your own setup during evaluation.
Quick check
Is an ignore file enough?
Only if it carries reasons, owners and expiry dates and uses an identifier other tools understand. A bare list of ids is hard to defend later.
Do all scanners support VEX?
No. Check each tool, and keep a structured file as a fallback.
Sources
Last reviewed: 19 October 2026.
