Software Bill of Materials: A Practical Buyer’s Guide

MoneyByte Points

• A software bill of materials identifies the components and dependency relationships inside a software product; it is similar to an ingredient list.
• An SBOM is most useful when it is machine-readable, tied to the exact product release, and refreshed whenever the software changes.
• Possessing an SBOM does not make software secure. A business still needs asset management, vulnerability monitoring, vendor support, and a response process.

When a widely used software component develops a serious vulnerability, businesses immediately face a difficult question: is that component hidden somewhere inside the software they use?

A software bill of materials can make the answer easier to find. Commonly called an SBOM, it records the components and supply-chain relationships used to assemble a software product. NIST compares it to an ingredient label for software.

An SBOM does not prevent vulnerabilities or prove that a vendor follows secure development practices. Its value is visibility: it can help a business identify potentially affected products, contact the correct vendors, and prioritize a response without waiting for every supplier to investigate from scratch.

What a software bill of materials contains

Modern applications frequently incorporate open-source libraries, commercial modules, development frameworks, and components inherited from other components. A buyer normally cannot identify all those dependencies by looking at the product interface.

The Department of Commerce’s minimum SBOM elements identify seven baseline data fields:

• Supplier name.
• Component name.
• Component version.
• Other unique identifiers.
• Dependency relationship.
• Author of the SBOM data.
• Creation timestamp.

These fields allow a business to distinguish between similarly named packages and determine whether a particular version appears in the product. ntia.gov

SBOMs are normally supplied in machine-readable formats. NIST identifies SPDX, CycloneDX, and SWID as recognized formats suitable for automated ingestion and version monitoring.

A spreadsheet or PDF may help a person review a small list, but a standardized machine-readable file is more practical when a company must compare many applications against a new vulnerability.

Why a static component list is not enough

An SBOM should represent a specific software release. If the vendor adds a library, changes a dependency, or ships a different build, the earlier inventory may no longer be accurate.

Before relying on an SBOM, check:

• The product and release to which it applies.
• When and how the file was generated.
• Whether direct and transitive dependencies are included.
• Whether proprietary and open-source components are both covered.
• How frequently the vendor provides updated files.
• Whether the SBOM was generated during the build or reconstructed afterward.

NIST warns that an SBOM generated retroactively may not reproduce the exact dependencies used at build time. It also recommends digitally signed, accessible repositories where practical.

Completeness should therefore be evaluated rather than assumed. A valid file containing only a shallow or outdated component list may provide little operational value.

How an SBOM improves vulnerability response

Imagine that a critical vulnerability is announced in a common software library. Without component visibility, an IT team may have to contact every vendor and wait for an answer.

With usable SBOM data, the team can:

1. Search its SBOM repository for the affected component and version.
2. Match potential results to applications actually deployed.
3. Determine which systems support important operations or sensitive data.
4. Check vendor advisories and available updates.
5. Prioritize testing, mitigation, or replacement.

This is where a software bill of materials becomes more than a procurement document. It becomes an input to vulnerability and asset management.

However, a component match does not automatically prove that the product is exploitable. The vulnerable function may not be present, enabled, or reachable in that implementation.

A Vulnerability Exploitability eXchange, or VEX, document can provide additional context. CISA describes VEX as a security advisory that states whether a product is affected by a known vulnerability—including cases in which the component is present but the product is not affected.

Businesses should combine SBOM information with:

• The location and business importance of the affected application.
• Exposure to the internet or untrusted networks.
• Vendor analysis and VEX statements.
• Known exploitation evidence.
• Available patches or temporary mitigations.
• The sensitivity and required retention period of protected data.

CISA’s guidance emphasizes that raw SBOM data must be converted into security intelligence before it can drive useful action.

Questions to ask software vendors

Businesses do not need an advanced software-security department to begin requesting component transparency. These questions can be added to a vendor assessment, contract discussion, or renewal review:

1. Can you provide a machine-readable SBOM?
   Ask which formats are available and whether the file can be imported into standard security tools.
2. Which product and version does it cover?
   Avoid accepting a generic inventory that cannot be connected to the product being purchased.
3. How is the SBOM generated?
   A file created during the build may provide better release-specific information than one reconstructed later.
4. Does it include transitive dependencies?
   A direct component may rely on several additional packages that also introduce risk.
5. How will updates be delivered?
   Determine whether the vendor publishes a new SBOM for every release or requires customers to request one.
6. How are vulnerabilities communicated?
   Ask about security advisories, VEX documents, patch timelines, and emergency notifications.
7. How long will the product receive security support?
   A complete component inventory cannot compensate for a vendor that no longer fixes vulnerabilities.
8. What happens when a critical component issue is discovered?
   The vendor should be able to identify affected products, assess exploitability, and explain mitigation or patch plans.

A vendor’s inability to supply an SBOM is not automatic proof that its software is insecure. It is still useful risk information, particularly when the product will handle sensitive data or support a critical process.

A practical 30-day SBOM adoption plan

A small or midsized business can begin without buying a specialized platform.

Week 1: Prioritize the software

Identify five to ten products with the greatest potential impact. Start with identity systems, financial software, cloud administration, production controls, remote-access tools, and applications holding sensitive information.

Week 2: Request sample SBOMs

Ask each vendor for the current machine-readable SBOM and its vulnerability-notification process. Record which vendors respond, which formats they provide, and which product versions are covered.

Week 3: Test one real workflow

Choose one file and verify that the component names and versions can be searched. Select a known component vulnerability and test whether the organization could locate the affected software and responsible system owner.

Week 4: Assign responsibility

Decide who stores the files, monitors advisories, contacts vendors, and records remediation decisions. Add SBOM delivery and security-support expectations to future purchasing and renewal discussions.

NIST cautions that SBOMs should complement—not replace—vendor assessments and vulnerability-management practices. An organization that cannot ingest, analyze, and act on the data may see little improvement from collecting the files alone.

For related access-security controls, read Money Byte’s guide to passkeys for small business. Additional coverage is available in the Money Byte technology archive.