How to Review an SBOM Before You Buy Software

Technology buyer inspecting an abstract software dependency map with a magnifying glass

Check that the SBOM covers the exact product build, edition, and agent you plan to deploy.
Open the file in a real parser to verify machine readability, package URLs, and dependency depth.
Treat the SBOM as an inventory, not a fixed safety certificate, and record vendor update terms.

You can review an SBOM before buying software in eight practical steps. Start by checking the exact product release scope. Next, confirm the file is machine-readable and inspect real component IDs. Then test dependency depth, verify release freshness, separate inventory from live alerts, check licenses, and test how the vendor fixes errors.

A vendor shares a software bill of materials, or SBOM, during procurement. The file looks huge. It lists hundreds of packages and long dependency trees. That size gives false comfort. Your job is simple: confirm what is inside the tool and check if your team can act when risks change.

The 2026 CISA minimum elements guidance calls an SBOM an ingredients list for code. It helps buyers make sound risk choices. Yet a shared file is not an automatic pass. You still need to test scope, freshness, package IDs, and vendor support before signing a contract.

This guide offers a clear review workflow for IT and security buyers. You do not need costly tools. A basic text editor, an open parser, and a direct vendor talk will catch most red flags early.

First, know what an SBOM can tell you

An SBOM gives you an inventory of software parts and their links. It shows whether a product uses a specific library, package, or open module. High-quality files also make it easy to separate similar names and trace nested code.

An SBOM is not a complete security clean bill of health. It does not prove that code is bug-free. It does not show if safe settings are in place. Nor does it confirm if a known flaw is reachable in your setup. It also grows stale unless the vendor ships a new file with every software build.

Keep these boundaries clear during vendor talks. Use the SBOM to learn what code is in the box. Demand other proof for secure development, patch speed, penetration tests, and response plans. Our guide on software vendor security evidence explains how these pieces connect. If the software uses automated tools, also review our playbook on AI access reviews for SaaS.

1. Confirm the product and release scope

Start with clear product identity. Note the exact product name, edition, version number, host model, and date under review. Match those facts against the header of the SBOM.

Ask if the file covers the full system you plan to buy. Many systems mix a desktop app, a cloud back end, and local worker agents. Each piece uses different libraries. A vendor might hand you an SBOM for a tiny agent while hiding a complex web core.

Write down all exclusions in plain words. Vendors often exclude base OS tools, build scripts, or managed cloud services. Review each gap with your team. Never assume an unlisted part is safe or covered.

2. Check that the file is machine-readable

A PDF or sheet helps human eyes, but software checks require structured data. Find out which format and version the vendor used. SPDX is an accepted global standard. The official SPDX specification lists version 3.0 as current. CycloneDX is another common format used by engineering teams.

Open the file with an open-source parser or validator. A valid file extension is not proof of good data. Verify that the file parses cleanly without syntax faults. Make sure your local tool reads the declared schema version without loss.

Keep the raw file safe for your audit records. If your team uses older scanners, test whether needed fields convert cleanly. Do not demand format changes just for show.

3. Inspect component identity, not just names

A plain component name is often too vague. Look for a verified author, a fixed version number, and a standard package URL (purl). Unique hashes and identifiers help vulnerability tools match the right package.

Sample five to ten records across the file. Pick direct libraries, small nested helpers, and code from different languages. Make sure your team can identify each item without guessing.

Watch out for empty fields, wide version ranges, missing publishers, and odd internal names. Private packages need clear notes. Ask the vendor to explain any internal code names that appear in the tree.

4. Test relationship depth and completeness

A list of top-level dependencies gives only half the story. Most serious bugs hide deep inside indirect packages. Confirm that the SBOM tracks parent-child links instead of flattening the list into one tier.

Ask how the vendor generated the file. Teams can pull data from source code manifests, build steps, or final binary scans. Each method sees different items. You want to see that the process truly scans the built software you run.

Run a fast completeness test. Find a third-party library mentioned in user guides, legal notices, or release notes. Search for that name in the file. If known libraries are missing, ask the vendor why.

5. Verify freshness and release binding

Check the creation date and the build number inside the file. Match them with the software build you want to buy. An SBOM built six months ago gives no view into current code risks.

Ask what build trigger creates a fresh SBOM. In modern teams, every release pipeline should output an updated file. Ask how new files reach buyers when security updates ship.

Tie this check to your internal software support calendar. Recheck the SBOM at major upgrades and yearly contract renewals. Never treat the review as a one-time onboarding task.

6. Separate component inventory from vulnerability status

Vulnerability scanners match SBOM parts against public security alerts. That scan output changes daily. An SBOM stays the same, but new flaws appear in public databases every week.

Never treat a clean scan report as permanent proof of safety. Note the scanner date and rule sets used. Ask how the vendor shares whether a flaw truly affects their code or cannot be triggered.

Official SPDX advice separates static component lists from moving vulnerability records. Keep that separation in mind. Store the component map in your archives, and refresh risk checks on a steady schedule.

7. Review licenses without guessing legal outcomes

Most SBOMs list declared license types for open packages. This helps your team spot risky terms before rollout. However, an automated tool does not replace qualified contract review.

Look for missing or disputed license tags on core libraries. Ask how the vendor verifies scan flags and custom terms. Keep legal flags and security flags in separate tracker columns so neither gets lost.

8. Ask how the vendor handles errors and customer questions

Every software inventory will contain minor errors at times. A package may have an old name, a wrong version tag, or a missing sub-module. The vendor needs a defined path to answer questions and issue fixes.

Test the vendor team during the sales call. Ask one pointed question about an odd entry found during your sample check. A direct answer with a clear update plan is worth more than generic marketing promises.

A 20-minute first-pass checklist

Scope: Does the file name the exact product, edition, build, and client agents you will run?
Format: Does the document parse cleanly in standard SPDX or CycloneDX tools?
Identity: Do components have clear names, fixed versions, and package URLs?
Depth: Are nested dependencies and child links shown clearly?
Freshness: Does the file timestamp match the latest production release?
Risk tracking: Are changing flaw alerts tracked separately from static component lists?
Support: Can the vendor answer technical questions and ship corrected files promptly?

Turn the review into a decision record

Finish your work with a concise decision memo. Record the file SHA-256 hash, product build, format, date, gaps, sampled packages, open issues, and the owner for next steps. Classify the result as approved, approved with conditions, or blocked.

Write clear, measurable conditions for the sales team. Do not write vague notes like "vendor will fix SBOM." Instead, write: "Vendor must provide an SPDX 3.0 file covering the desktop client and server agent before deployment." This sets clear goals for both teams.

The CISA minimum elements provide a baseline standard. Treat that baseline as a starting floor. High-impact tools, cloud systems, and core data stores warrant deeper checks.

The practical buying rule

Never judge an SBOM by file size or total line count. Judge it by whether your team can read the data, trace components, match releases, track flaws, and get prompt vendor fixes.

When those checks pass, the SBOM becomes a helpful tool for contract renewals and vulnerability audits. If they fail, the file shows an unfinished transparency process. That is a clear sign to ask tough questions before you sign.