Check five things: the required data fields are present, the SBOM names your exact product version, it goes deep enough, it flags what it does not know, and it scans cleanly against a vulnerability database. A file that fails any of these is not useless, but you should ask the vendor to fix it.
What an SBOM is
A software bill of materials is a formal record of the components used to build a piece of software and how they relate. The NTIA describes it that way in its minimum elements report. As a buyer you use it to match components against vulnerability data.
Check 1: the minimum fields
The NTIA minimum elements list seven data fields: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp. Open the file and look for each. Missing versions or identifiers are the most common gap, and they make automated matching unreliable.
Check 2: the version matches what you run
An SBOM for version 4.1 does not describe version 4.2. NTIA guidance on frequency says a new SBOM should be created when the software is updated with a new build or release. So confirm the product name, version and timestamp in the file match what you deployed. If the SBOM is a year old, ask for a current one.
Check 3: depth
NTIA says an SBOM should contain all primary, top level components with their transitive dependencies, or else say where it stops. Look at the dependency relationships. If every component appears flat with no relationships, you only see the top layer.
Check 4: known unknowns
Where the full dependency graph is not listed, the NTIA text says the author must explicitly identify "known unknowns." A file that admits what it lacks is more trustworthy than one that implies completeness. If the file says nothing about its limits, ask.
Check 5: scan it
Run the SBOM through a vulnerability scan and read the result with the vendor's advisory page open. For each finding, ask whether the flaw is reachable in the product. A vulnerable component present in the product may not be exploitable in practice. The vendor can answer with an exploitability statement, such as VEX. See our post on SBOM versus VEX.
Steps in order
- Confirm the file opens in a standard format, and note which one.
- Check the seven fields.
- Match name, version and date to your deployment.
- Look at depth and any known unknowns statement.
- Scan, and send the vendor a list of findings with questions.
- File the SBOM with your product record.
What to send back
Be specific. "Component X version Y appears in your SBOM. Advisory Z applies to it. Is the affected function used in your product?" Specific questions get specific answers. A vague "please confirm you are secure" gets a vague reply.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the version and relationship columns, which map to checks 1 and 3.
You can drop a vendor SBOM into the free scan at gold.safeguard.sh/scan, which checks dependency manifests and SBOMs for known vulnerabilities. Safeguard also offers SBOM and dependency scanning at scale, and reachability analysis for your own code.
Quick check
What if the SBOM lacks versions?
Ask for a corrected file. Without versions, vulnerability matching is unreliable.
Does a flagged component mean the product is exploitable?
Not necessarily. Ask the vendor whether the affected code is reachable in the product.
Sources
Last reviewed: 19 October 2026.
