How do you review a vendor SBOM with the Safeguard CLI?

To review a vendor SBOM with the Safeguard CLI, run safeguard validate on the file to confirm it is well formed, then safeguard scan --sbom to match its components against vulnerability data. Read the JSON output, and send questions about gaps back to the vendor. Neither step proves the SBOM is complete.

Why validate before you scan?

A scan trusts whatever is in the file. If the SBOM is malformed, truncated or missing component versions, the scan result looks clean for the wrong reason.

Validation checks the document against its specification. The CLI docs say it covers CycloneDX (JSON and XML), SPDX (JSON, YAML, tag-value and RDF), and VEX documents in CSAF and OpenVEX form.

safeguard validate vendor-sbom.json

Two flags are worth knowing. --strict treats warnings as errors, which is what you want for a document you are going to rely on. -o with a file name writes the report to a file you can attach to a vendor ticket.

safeguard validate vendor-sbom.json --strict -o validation-report.json

If a vendor sends a folder of files, one per product, point the command at the folder:

safeguard validate ./vendor-sboms --recursive

Use --fail-fast when you only need to know whether anything is broken and do not care how many problems there are.

How do you scan the SBOM for known vulnerabilities?

The scan command takes exactly one target. For an existing SBOM, that is --sbom:

safeguard scan --sbom vendor-sbom.json

The format is detected automatically between SPDX and CycloneDX. If detection gets it wrong, pass --format spdx or --format cyclonedx.

Results go to ./output by default, in one folder per scan. Expect files such as vuln.json, license.json and collection.json. Use --output with a directory name to keep each vendor in its own place.

Two more flags matter for vendor files. --resolve-transitive asks the CLI to resolve transitive dependencies through deps.dev, which can fill in components the vendor did not list directly. --org-namespace takes namespaces for private packages, such as @mycompany, so internal names are not treated like public ones.

What does the exit code mean?

This trips people up. safeguard scan exits 0 when the scan ran, even if it found vulnerabilities. It exits 1 if the command failed, and 2 if results were written but the vulnerability scan did not run.

So a script that only checks for 0 will let a vulnerable SBOM through. If you want a hard stop on severity, that belongs in a policy gate in the platform, not in a shell test. Treat exit code 2 as a failure in any automation, because it means you do not have a real answer.

What should you look for in the output?

Start with what the file says, then what the scan says.

• Coverage. Does the SBOM list the components you know the product ships? A container product with ten entries is suspicious.
• Versions. Components without versions cannot be matched to advisories.
• Licenses. Open license.json and look for terms your contracts do not allow.
• Vulnerabilities. In vuln.json, sort by severity, then ask which ones the vendor says are not exploitable.

That last question is what a VEX document is for. If the vendor supplies one, validate it with the same command, then read its statements next to your scan results.

What are the limits?

The CLI documentation describes scan as building an SBOM and matching it against vulnerability databases. It does not say how it judges whether a vendor's SBOM is complete, and a scan cannot find components the file leaves out. The same goes for newly published advisories: run safeguard update to refresh the vulnerability databases before you read anything into a clean result.

Also, the docs say safeguard --help wins if the page and your build disagree. Check it before you script anything.

What to do

1. Ask the vendor for the SBOM in SPDX or CycloneDX, plus a VEX document if they have one.
2. Run safeguard validate with --strict and keep the report.
3. Run safeguard update, then safeguard scan --sbom with a separate output folder per vendor.
4. Fail your automation on exit codes 1 and 2, not only on 1.
5. Review coverage, versions and licenses by hand before you read the vulnerability list.
6. Send the vendor a short list of gaps and questions, and keep their answers with the report.

Quick check

Sources

• Safeguard CLI usage guide, fetched 18 October 2026
• Safeguard CLI overview, fetched 18 October 2026

Last reviewed: 18 October 2026.