How to Review an SBOM Before You Buy Software

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

Confirm that the SBOM covers the exact product, release, edition, and deployment components you plan to use.
Test machine readability, component identity, dependency depth, and freshness instead of judging the artifact by its size.
Treat the SBOM as a component inventory, not a permanent vulnerability verdict, and record vendor follow-up conditions.

A software vendor sends you a software bill of materials, or SBOM, during a security review. The file looks substantial. It may contain hundreds of packages, several identifiers, and a long dependency graph. That volume can create false confidence. The buyer's real question is simpler: Can this artifact help us identify what is in the product and act when risk changes?

CISA's 2026 minimum-elements guidance calls an SBOM an ingredients list for software and says it can support more informed risk decisions. That is a useful starting point, not a pass mark. A buyer still needs to check scope, freshness, identifiers, relationships, and the vendor process behind the file.

This guide provides a practical review sequence for a small technology or security team. It does not require a large SBOM platform. A text editor, a supported viewer, and a short vendor call can reveal most of the early warning signs.

First, know what an SBOM can tell you

An SBOM is a structured inventory of software components and their relationships. It can show that a product includes a particular library, package, or module. Good records also make it easier to distinguish similarly named components and understand which item depends on another.

An SBOM is not a complete security verdict. It does not prove that every component is safe, that the product is configured securely, or that a listed vulnerability is exploitable in the vendor's implementation. It also cannot stay current without a release process that generates and shares a new artifact when the software changes.

Keep that boundary clear. Use the SBOM as evidence about product composition. Ask for separate evidence about secure development, vulnerability handling, penetration testing, and incident response. Our broader guide to software-vendor security evidence shows how those pieces fit together.

1. Confirm the product and release scope

Begin with identity. Write down the exact product, edition, release, deployment model, and date that you are evaluating. Then look for those details in the SBOM or its accompanying documentation.

Ask whether the artifact covers the full product you will use. A desktop client, mobile app, cloud service, browser extension, appliance image, and optional connector may have different component sets. A vendor might provide an SBOM for one downloadable agent while your purchase also depends on a hosted control plane.

Record exclusions in plain language. If the vendor says infrastructure, operating-system packages, build tools, or managed-service components are outside the artifact, decide whether each exclusion is reasonable for your risk. Do not silently treat an unexplained gap as complete coverage.

2. Check that the file is machine-readable

A spreadsheet or PDF can be useful for a human review, but a repeatable process works best with a machine-readable format. Ask which specification and version the file follows. SPDX is an international standard, and its official specification page identifies version 3.0 as current at the time of this review. Your tools or suppliers may also support other established SBOM formats.

Open the file with a compatible parser or viewer. A valid extension is not enough. Confirm that the document parses without errors and that the tool recognizes the declared format version. Keep the original bytes so another reviewer can reproduce the result.

If your current tooling supports an older version, do not demand a conversion merely for appearances. Document the compatibility boundary and test whether the fields you actually need survive any conversion.

3. Inspect component identity, not just names

A component name by itself is often ambiguous. Look for a supplier or author, an exact version, and a stable identifier where the ecosystem supports one. Package URLs, cryptographic hashes, or other identifiers can help a matching system distinguish one component from another.

Sample several records instead of checking only the first row. Choose direct dependencies, small transitive libraries, and components from different ecosystems. For each sample, ask whether a reviewer could identify the exact component without guessing.

Flag placeholder values, broad version ranges, missing suppliers, and local names that cannot be mapped to a public or vendor-owned component. A vendor may have a valid explanation for private packages, but the explanation should be recorded.

4. Test relationship depth and completeness

The top-level package list is only part of the picture. Many important libraries arrive through other dependencies. Review whether the artifact records dependency relationships and whether the graph stops unexpectedly after one level.

Ask the vendor how the SBOM was generated: from source declarations, during the build, from the final package, or through more than one method. Each approach can see different things. You are not looking for a universally perfect method. You are checking whether the chosen method can plausibly cover the product and release in scope.

Use a simple completeness challenge. Pick one component you already know the product uses from documentation, license notices, or deployment files. Confirm that it appears with a sensible version and relationship. This is not a full audit, but a failed spot check is a reason to investigate.

5. Verify freshness and release binding

Find the creation timestamp and the software release it describes. Compare both with the version you plan to buy or renew. An artifact generated months before a current release may be historical evidence rather than a current inventory.

Ask what event creates a new SBOM and how customers receive it. A useful answer connects artifact generation to the vendor's release process. It also explains how corrected files are versioned so a buyer can tell which copy is authoritative.

Add this event to your software support calendar. Review the SBOM again at major upgrades, contract renewals, and material architecture changes instead of treating it as a one-time procurement attachment.

6. Separate component inventory from vulnerability status

A vulnerability scanner may match SBOM components against advisory data, but that output is time-sensitive. The SBOM can remain unchanged while new vulnerabilities are published or old findings gain better analysis.

Do not read “no vulnerabilities” in a static report as a permanent product claim. Record the advisory-data timestamp, matching method, and identifier quality. Ask how the vendor communicates whether a finding affects the product, is not affected, has been fixed, or still needs investigation.

SPDX's guidance on vulnerability data distinguishes static component information from dynamic vulnerability information. That distinction matters in a buyer review: preserve the component inventory, but refresh risk status through a process designed for changing data.

7. Review licenses without turning the SBOM into legal advice

Many SBOMs include declared or detected license information. That can help your legal or compliance team find packages that need attention. It does not replace contract review or a qualified interpretation of license obligations.

Look for missing or conflicting license fields, especially in components central to the product. Ask how the vendor resolves scanner guesses and how it handles packages with custom or dual licenses. Keep security and licensing findings in separate columns so one does not hide the other.

8. Ask how the vendor handles errors and customer questions

An SBOM will eventually need a correction. A component may be mislabeled, duplicated, omitted, or assigned the wrong version. The vendor should have a channel for questions and a method for issuing a corrected artifact.

Test the process with one specific question from your sample review. A clear answer that points to the product release, component record, and correction process is more valuable than a generic promise that the SBOM is “industry standard.”

A 20-minute first-pass checklist

Scope: Does the SBOM name the exact product, release, edition, and deployment components you will use?
Format: Does it parse in a tool that supports the declared specification and version?
Identity: Do sampled components have usable names, versions, suppliers, and identifiers?
Depth: Are transitive dependencies and relationships present where expected?
Freshness: Is the artifact bound to the current release, with a clear generation timestamp?
Risk context: Is changing vulnerability status handled separately from the static inventory?
Process: Can the vendor answer questions and issue a corrected, versioned artifact?

Turn the review into a decision record

Finish with a one-page record. List the artifact hash, product release, format, creation time, scope, exclusions, sampled components, open questions, and the person responsible for follow-up. Mark the result as accepted, accepted with conditions, or blocked pending evidence.

Conditions should be testable. “Vendor will improve the SBOM” is vague. “Vendor will provide a release-bound SPDX file that includes the desktop client and connector before rollout” gives both sides a clear finish line.

CISA's minimum elements are a baseline, and its 2026 guidance notes that some software types may need additional elements. Treat the baseline as a floor. A critical service, AI system, managed cloud platform, or safety-sensitive product may justify deeper requirements.

The practical buying rule

Do not grade an SBOM by page count. Grade it by whether your team can identify the product, parse the file, trace meaningful components, connect it to a release, refresh risk context, and get errors corrected.

If those tasks work, the SBOM can become part of normal renewal and vulnerability-management routines. If they do not, the artifact is evidence of an unfinished transparency process—not proof that the software is unsafe, but a clear reason to ask better questions before you buy.