How do you review a vendor SBOM before you sign?

To review a vendor SBOM, check that it is machine readable, covers the whole product, includes transitive components with versions, and is recent. Then look up the riskiest components for known vulnerabilities and maintenance status, and ask the vendor about anything missing. The goal is a better conversation, not a perfect list.

What is in a good SBOM?

CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. Its minimum elements guidance has been revised, and a 2026 update adds data fields and practices, so check the current document for the fields you should expect. Common formats are SPDX and CycloneDX, which NTIA has highlighted alongside SWID.

Step 1: is it usable?

Ask for a machine readable file in SPDX or CycloneDX, not a PDF. A PDF cannot be searched or compared by your tools. Check it opens, lists the product name and version, and states who produced it and when.

Step 2: does it cover the product?

An SBOM for one module of a platform is not an SBOM for what you will run. Confirm it matches the version you are buying and the deployment you will use: hosted, on-premises or a client you install. If it covers only part, ask what is excluded.

Step 3: how deep does it go?

A list of ten direct dependencies for a large application is suspicious. Look for transitive components, with names and versions. Missing versions make the list almost useless, since you cannot match a version to a vulnerability.

Step 4: how fresh is it?

An SBOM from a year ago describes an old build. Ask how often it is regenerated and whether it is produced from the build itself or written by hand.

Step 5: look up the risky parts

Pick the components that matter most: those that handle authentication, parse untrusted input, touch cryptography or sit on the network edge. Look each up for known vulnerabilities, maintenance activity and licence.

The Gold Open Source browser extension from Safeguard is a launcher for gold.safeguard.sh. It lets you check a package, container image, CVE, AI model, MCP server or agent skill without leaving your tab, with no account needed. It does not read an SBOM file for you. Use it to look up components one at a time while you read the document. The Safeguard extension is different: it puts Griffin search in a side panel for people with a Safeguard account.

Step 6: ask the right questions

Does the vendor publish vulnerability exploitability information (VEX) so you can see which listed vulnerabilities do not affect the product? CISA describes VEX as an advisory-style statement of whether a product is affected by known vulnerabilities. How quickly do they patch a critical issue? Who is your contact?

What an SBOM does not tell you

It does not say whether a component is exploitable in the product, whether the code is well written or whether the vendor's build is trustworthy. Pair it with questionnaire answers and, for critical suppliers, deeper review.

What to do

1. Request SPDX or CycloneDX for the exact product and version you are buying.
2. Check for transitive components and versions. Send it back if either is missing.
3. Note the generation date and the process.
4. Look up the ten components that matter most.
5. Ask for VEX statements for the vulnerabilities you find.
6. Record the findings in your vendor file, with a date to ask again.

Quick check

Sources

• CISA SBOM
• NTIA Software Bill of Materials
• Safeguard downloads, extensions
• Gold Open Source on the Chrome Web Store

Last reviewed: 18 October 2026.