Add two steps to the pipeline that produces or receives an SBOM: validate the file with safeguard validate, then scan it with safeguard scan and an SBOM target. Validation catches malformed documents early. Scanning then matches the listed components against vulnerability data.
Why validate first
An SBOM that does not parse, or that omits fields, produces a scan that looks fine and means little. Validating before you scan separates two questions: is this a well formed document, and what is in it. The CLI documentation says validate checks SPDX, CycloneDX and VEX documents.
The validate step
safeguard validate sbom.json --strict --fail-fast -o validation-report.txt
The usage page lists these options. Strict treats warnings as errors, fail fast stops at the first error, and an output option writes the report to a file. A recursive option checks a whole directory of SBOMs, which suits a pipeline that receives several from suppliers. Exit codes for validate are not documented on that page, so test how your version behaves on a deliberately broken file before you rely on it as a gate.
The scan step
safeguard scan --sbom sbom.json --format auto --output out/
The format option takes auto, spdx or cyclonedx and describes the document you pass. Auto detects it. Remember that scan takes one target per run.
Your own SBOM versus a supplier SBOM
For an SBOM you generated, validation guards against a broken generator step. For one received from a supplier, validation is a first quality check, and it will not tell you whether the contents are accurate. Treat the result as one input to vendor review.
Do not skip the prerequisites
Scan needs syft and grype on the runner, as covered in the scanner prerequisite post. If a scan returns exit code 2, the vulnerability matching did not run.
Keep both outputs
Archive the validation report next to the scan folder. Together they say what you checked, with which version of the tool, on which commit. Pin the CLI so the answer is repeatable, following the version pinning post.
What neither step proves
Valid does not mean complete or true. A well formed SBOM can still leave out components. Compare it with what the build really contained, for example by also scanning the directory or the image, and look at the differences.
Failing the right way
Decide whether a validation failure should block a release build. For an SBOM you generate, yes, because it means the generator broke. For a supplier SBOM, often no: record the failure and ask the supplier for a corrected file, while the delivery proceeds under your own risk rules.
Quick check
Does validate check vulnerabilities?
No. It checks the document against the SPDX, CycloneDX or VEX format. Scan does the vulnerability matching.
Do I need to tell scan which format my SBOM uses?
Not usually. Auto detects it, or you can name spdx or cyclonedx.
Sources
Last reviewed: 19 October 2026.
