To avoid lock-in with a security scanner, demand open exports for the data you would need to rebuild elsewhere: SBOMs in CycloneDX or SPDX, results in a standard format such as SARIF, exploitability statements in a standard such as VEX, and a full dump of policies and audit history. Test each export during the pilot, not at termination.
What lock-in looks like
You find out a year in that your history lives in a proprietary schema, your policies cannot be moved, and your inventory export drops fields. Switching then means starting over, which is exactly why some teams stay with tools they dislike.
The exports to ask for
SBOM. CycloneDX and SPDX are the widely used open formats. Ask which versions are supported and whether the export includes transitive dependencies, licences and hashes.
Findings. SARIF is a common interchange format for static analysis results. Ask whether all finding types can be exported in it or in a documented JSON schema.
Exploitability statements. VEX documents record whether a product is affected by a given vulnerability. If you will share such statements with customers, check import and export.
Policies. Rules written in a vendor language cannot always be ported. At least ask for a readable export so you can rewrite them.
Audit history. Exception approvals, gate decisions and scan timestamps may be needed for an audit long after you leave.
API. A documented API lets you extract data on a schedule.
How to test during the pilot
- Export an SBOM for one project in each supported format.
- Load it into a free open source viewer or a second tool.
- Compare package counts and key fields against the source.
- Export findings and try to import them elsewhere.
- Time the whole thing.
If something fails, ask the vendor to explain. Fixing it during evaluation costs them little. After signing, you have less leverage.
Contract points
Write the export right into the agreement, along with a retrieval window after termination and deletion confirmation after that window.
A fair caution
Open formats do not remove every difference. Two tools may produce slightly different SBOMs for the same project, because discovery methods vary. That is a reason to check the data, not a reason to avoid the formats.
Try it yourself
Open the dependency inventory demo and imagine exporting that list. Which fields would you need to keep: versions, licences, hashes, relationships?
Click through it at your own pace, or open it full screen.
Where Safeguard fits: it provides SBOM and dependency scanning with SBOM export, and a free scan at https://gold.safeguard.sh/scan lets you test an export yourself.
Quick check
Which SBOM format should I pick?
Either CycloneDX or SPDX works for most uses. Choose based on what your customers and other tools expect, and support both if you can.
When should I test an export?
During the pilot, while you still have leverage with the vendor.
Last reviewed: 19 October 2026.
