Triage history is every human decision attached to a finding: whether it was dismissed or accepted, why, by whom, when, and which ticket tracks the work. Scanner output alone is not history. Before you switch dependency scanners, export these decision records, because the new tool will rediscover the vulnerabilities but not your judgment about them.
Findings are cheap, decisions are expensive
A new scanner will re-find nearly every vulnerable package in a few minutes. What it cannot recreate is the afternoon an engineer spent proving that a library is only used in a test harness, or the exception a director signed for a legacy service. Those decisions are the asset. If they live only inside the old tool's database, they vanish the day the contract ends.
The first job in any migration is therefore to define what you are protecting. Many teams skip this and export a flat list of open findings, which is the one thing they can regenerate for free.
The fields worth keeping
Public schemas show what a decision record tends to contain. The GitHub REST API for dependency alerts, for example, exposes a state, a dismissed reason, an optional dismissed comment, who dismissed the alert, and timestamps for creation, dismissal and fix. The CycloneDX 1.6 schema carries an analysis block with a state, a justification, a response, free text detail, and first issued and last updated dates. Together they suggest a sensible minimum.
| Field | Why you need it later |
|---|---|
| Package identity and version | Matches the decision to the right component |
| Advisory ID and known aliases | Survives a change of advisory source |
| Decision state | Open, dismissed, accepted, fixed |
| Reason category | Lets you group and audit decisions |
| Free text comment | The actual reasoning, in the engineer's words |
| Decider and decision date | Accountability and audit trail |
| First detected date | Keeps age and SLA math honest |
| Expiry or review date | Stops permanent exceptions by accident |
| Linked ticket | Connects the finding to the work |
| Project or repository | Scope of the decision |
If a field is missing from your old tool's export, note that now. It tells you which decisions you will have to re-confirm rather than import.
How to inventory what you actually have
Sample ten decided findings in the old tool and write down every attribute you can see in the screen, not just in the export. Then compare that list against the API or export format. Anything visible in the UI but absent from the export is at risk. Comments and attachments are the usual casualties.
Also look outside the scanner. Decisions often leak into pull request threads, chat messages and spreadsheets. Decide which of those you will mine and which you will treat as lost.
What not to carry across
Not everything deserves a seat in the new system. Findings tied to repositories that were archived, or exceptions that expired a year ago, should be left behind. A smaller, cleaner history is easier to trust and easier to audit.
Try it yourself
Open the demo and look at how a dependency inventory ties each package to its version and project. Those identity fields are the join key for every decision you will migrate.
Click through it at your own pace, or open it full screen.
A note on Safeguard
If you want an independent baseline of what a fresh scan reports on your repositories, Safeguard offers SBOM and dependency scanning, and a free scan at gold.safeguard.sh/scan. Compare it against your old tool's open list, not against its decisions.
Quick check
Is a CSV of open findings enough to migrate?
No. Open findings can be regenerated by any scanner. The CSV that matters holds closed and dismissed decisions with reasons, owners and dates.
What if the old tool does not export comments?
Screenshot or copy the comments for high risk exceptions, and mark the rest as needing re-review in the new tool.
Sources
Last reviewed: 19 October 2026.
