Ask for a full export during the trial and open it in a second tool. You want original SBOM files, the dependency relationships, version history, and your triage decisions such as suppressions and VEX statements. If any of those cannot leave, you are renting your own records.
Four layers of data
Teams usually think of exit as "download the SBOMs". There are four layers, and they differ in how easily they move.
| Layer | Example | Usually portable? |
|---|---|---|
| Source documents | The SBOM files you uploaded or generated | Yes, in standard formats |
| Derived data | Matched vulnerabilities, license results | Recomputable, but values change with the data source |
| Decisions | Suppressions, risk acceptances, VEX statements | Often trapped |
| History | Which version of each SBOM existed on which date | Often missing |
Decisions deserve the most attention. They hold the work your analysts did: why a finding is not exploitable, who accepted a risk, and until when. If they exist only inside the tool, a switch means redoing triage from zero.
The export test
- Load three or four real projects into the tool, with at least one release history.
- Record a few decisions: one suppression with an expiry, one not affected statement with a justification, one accepted risk.
- Request a full export of everything, using whatever the product offers.
- Open the SBOM files in an independent validator, and check that dependency relationships survived.
- Check whether the decisions came out in a standard exchange format. Open specifications exist for exploitability statements: OpenVEX, CycloneDX's VEX capability and the CSAF standard's VEX profile.
- Check that timestamps, authors and versions of each decision came with them.
- Try to import the export into a different tool or script, and see what is recognised.
What good looks like
- Original files come back byte for byte, or as valid documents in the standard formats.
- The export contains component relationships and identifiers, not just names.
- Decisions export with who, when, why and status, in a documented format.
- History is retained per release, not collapsed to latest.
- Export is available through an API or a self service button, not a support ticket.
Contract questions
- Is data export covered in the agreement, and at what notice period?
- Is there a fee or a delay for a full export?
- How long is your data kept after you leave, and how is it deleted?
- Who owns the derived data and the decisions your team recorded?
An ordinary habit that removes most risk
Keep your own copy of every SBOM and every decision in storage you control, written at the time of creation. Then the platform becomes a viewer and analyser, not the system of record. That also makes comparing tools easier, because you can feed the same archive to each.
Where Safeguard fits
Safeguard produces standard SBOM output and keeps vulnerability and policy results in the platform. Run the free scan at gold.safeguard.sh/scan on a sample project, and ask any vendor, including us, to demonstrate a full export before you commit.
Quick check
Is an SBOM file enough to leave a platform?
It is the start. You also need relationships, history and the decisions your team recorded.
Which decision data matters most?
Not affected statements with justifications, and risk acceptances with owner and expiry.
Sources
Last reviewed: 19 October 2026.
