Keep your SBOM data portable by storing original files outside the platform, using standard formats, testing a full export each year, recording annotations and statuses in an exportable form, and writing down what a migration would involve. Do this before you sign, not when you want to leave.
Why plan an exit at the start
Every tool is replaced eventually: needs change, a company is acquired, or a contract ends. SBOM data is long lived because customers and assessors ask about old releases. If it can only be read through one product, you have tied a long record to a short relationship. The NTIA guidance names SPDX and CycloneDX as formats used to generate and consume SBOMs. Using them for storage keeps your options open.
What actually needs to move
| Data | Portability question |
|---|---|
| Original SBOM files | Do you hold copies outside the platform? |
| Normalised component records | Exportable in a standard format? |
| Release and product mapping | Exportable as a table with identifiers? |
| Annotations, such as license decisions | Exportable with author and date? |
| Vulnerability status and reasons | Exportable, ideally in a standard exchange form? |
| Audit log | Exportable in readable form? |
| Users, roles and scopes | Exportable for rebuilding access? |
| Integrations and tokens | Documented so they can be recreated? |
The riskiest items are the last four. Original files are easy. The human decisions layered on top are where lock in hides.
Habits that keep you portable
- Archive originals. Write each generated SBOM to your own storage at build time, with a hash.
- Keep identifiers canonical. Package URLs travel between tools. Internal row identifiers do not.
- Export on a schedule. A quarterly full export, stored with your records, is a free backup.
- Record decisions in exchange formats where you can. Status statements in a standard VEX style form are easier to carry than screenshots of a screen.
- Document the integration map. Which pipelines upload, who owns tokens, which webhooks go where.
- Read the contract. Look for data return terms and the period during which you can still export after termination. Have your own counsel review it, because this post is not legal advice.
The annual exit drill
Once a year, do a dry run.
- Take a full export from the platform.
- Import a sample of it into a neutral place, such as a plain directory with a validator and a small script, or a trial of another tool.
- Check counts and identifiers, as in the round trip test.
- List what did not survive.
- Record the result and the date.
If a drill reveals that annotations do not export, you can fix the habit now, perhaps by also writing key decisions to a separate record.
What to ask a vendor
- What is the complete export, and does it include annotations and logs?
- In which formats?
- Is there a size or rate limit on exports?
- How long is data available after contract end?
- How is data deleted when you ask, and is deletion confirmed in writing?
See SBOM platform storage, retention and sharing questions for related checks.
Where Safeguard fits
Safeguard generates SBOM and dependency inventories from scans, and you can keep the outputs in your own storage as well. The free scan at gold.safeguard.sh/scan is a quick way to see what you would hold.
Quick check
Is keeping original SBOM files enough for an exit?
It covers the base data. You also need annotations, status decisions and the audit log, which live only in the platform unless exported.
How often should I test an export?
Once a year at minimum, and after any major platform upgrade.
Sources
Last reviewed: 19 October 2026.
