Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) is a machine-readable document that inventories all components within a piece of software. An SBOM should be comprehensive covering all of the open-source and third-party components constituting a codebase. It goes beyond merely listing these components; an SBOM also includes vital information such as the licenses governing these components, their specific versions used in the codebase, and their patch status. This detailed breakdown of a software project allows security teams and developers to quickly identify potential vulnerabilities or licensing issues, enhancing overall software security and compliance.

Every software component listed in an SBOM should at a minimum contain the following information:

• Component Name: Designation typically defined by the original publisher or producer.

• Component Publisher/Producer: The entity that creates, defines, and identifies the component.

• Component Version: The supplier's identifier for a change from a previously identified version.

• Component Identifier: A lookup key within a larger software package or relevant database.

• Component License: Indicates how an open-source component can be used, modified, or shared.

• Component Hash Value: A hexadecimal value created by applying a cryptographic hash algorithm to the component.

• Component Hash Algorithm: The cryptographic algorithm used to create the hash value.

• Component Dependency Relationship: Indicates when one component includes another.

In 2026, CISA and partner organizations updated the Minimum Elements for a Software Bill of Materials to include information about the solution that generated the SBOM: SBOM author and signature; data format name and version; generation context; timestamp; tool name and version; and SBOM version identifier.

Minimum Elements update: https://media.defense.gov/2026/Jul/29/2003971159/-1/-1/1/CSI_2026_cisa_sbom_minimum_elements_508c.PDF

Development: Developers use SBOMs to gain crucial insights into their software project's complex dependencies, including open-source libraries and third-party components. SBOMs empower developers to make informed decisions during development, improve code quality and security, assess component quality, and identify vulnerabilities or licensing issues for proactive resolution.

Security: Security teams rely on SBOMs to identify vulnerabilities through an inventory of software components, versions, and patch statuses. This information supports vulnerability prioritization, threat modeling, proactive risk assessment, and a reduced attack surface.

Compliance: Legal and compliance teams use SBOM transparency to cross-reference software licenses with agreements, prevent costly disputes, protect organizational reputation, and monitor component and license changes over time.

Risk management: Risk management teams use SBOMs to assess and prioritize hazards in third-party components, evaluate their impact, plan mitigation, and protect against operational disruption and security compromise.

Supply chain management: Organizations use SBOMs to verify the authenticity and integrity of software acquired from suppliers and third parties. Teams can cross-reference component data with external sources to detect tampering or compromise during transit and strengthen defenses against supply chain attacks.

SPDX v3.0 SBOM code formatted section for us-parser-js v0.7.29

SBOMs are generated using one of two industry-recognized formats: SPDX and CycloneDX.

• SPDX (System Package Data Exchange) is a Linux Foundation standard with a strong emphasis on licensing.

• CycloneDX is an Open Worldwide Application Security Project (OWASP) standard focused primarily on security.

CycloneDX v1.6 and SPDX v3.0 can both represent components such as us-parser-js v0.7.29 in machine-readable form. SWID (Software Identification Tags), while not a true SBOM, is an industry standard used primarily to identify installed software products.

CycloneDX v1.6 SBOM code formatted section for us-parser-js v0.7.29

Software Composition Analysis (SCA) is an application security tool that reviews a software package's source code to identify open-source components that are malicious or contain exploitable vulnerabilities. These components are reflected in a manifest, which an SCA tool can use to generate an SBOM.

SCA-based manifests are not the only means of creating an SBOM and often fail to inventory more than half of the total components in a software package. SCA can miss third-party components, transitive dependencies, and additional components introduced in the final build.

For an SBOM to be comprehensive, it should be generated from the software package's binary rather than only its source code, using complex binary analysis. This approach can produce a more complete SBOM and identify six key areas of software supply chain risk: licensing, secrets exposure, vulnerabilities, hardening, tampering, and malware.

• Security assurance: Visibility into component makeup allows organizations to identify and address vulnerabilities promptly, reducing breach risk.

• License compliance: Knowing the licenses associated with each component helps organizations meet licensing requirements and reduce legal risk.

• Efficient patch management: SBOMs track component versions and patch status so teams can prioritize and apply updates effectively.

• Risk mitigation: SBOMs help teams proactively manage risks associated with third-party software components before issues become critical.

• Software supply chain security: As supply chain attacks become more prevalent, SBOMs play a pivotal role in securing software development and distribution.

Learn more: https://www.reversinglabs.com/glossary/software-supply-chain-security

SBOM rules vary by location and industry.

The European Union has taken a strict approach. Under the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, manufacturers have a legally binding obligation to create, maintain, and retain an SBOM for products with digital elements marketed in the EU — even when the vendor is headquartered elsewhere.

In the U.S., Executive Order 14028 on Improving the Nation's Cybersecurity made SBOM use integral to securing software. This led to the Minimum Elements report, expanded in 2026 by CISA with the NSA, FBI, Department of Energy, NIST, the Defense Department's Cyber Crime Center, and international partners. NIST's Secure Software Development Framework also includes SBOM-related actions: https://csrc.nist.gov/Projects/ssdf

Industry-specific requirements include FDA guidance for medical-device manufacturers and PCI DSS Requirement 6 for the development and maintenance of secure systems and software.

SBOMs are generated at three points in the software lifecycle: before the build, during the build, and after the build. Each point captures software at a different stage, and the point chosen determines how complete and trustworthy the inventory is.

Generating an SBOM before or during the build can leave gaps because the greatest risk often lives in components teams never intended to include. Analyzing the final distributed package produces the most complete and accurate SBOM — and the clearest picture of what an organization is releasing to customers or receiving from a vendor.

Before the build, an SBOM describes software as specified. Developers list the components they intend to include in a manifest. This is the developer's best estimate of what the build should contain. Because it is a declaration of intent rather than a record of fact, it cannot confirm what actually ended up in the software.

During the build — software as built: The build system records components as they are pulled in and generates an SBOM from that activity. This captures more than a manifest, but modern components carry third-party and transitive dependencies that are often invisible beneath the top layer.

After the build — software as distributed: Finished software is packaged with installers, help files, configuration files, and images. These may not appear in a manifest, yet each is a potential vector for compromise. Analyzing the final distributed package therefore produces the most complete and accurate SBOM.

• Development: Developers use SBOMs to understand complex dependencies and make informed decisions that improve code quality and security.

• Security: Cybersecurity and application security teams use SBOMs to identify and prioritize vulnerabilities, perform threat modeling, and assess risk proactively.

• Compliance: Legal and compliance teams use SBOMs to meet licensing agreements and regulations, preventing costly disputes and protecting reputation.

• Risk Management: Risk managers, including TPRM teams, assess hazards in third-party products such as secrets exposure, tampering, and malware.

• Supply Chain Management: Teams verify the authenticity and integrity of software acquired from suppliers and check whether components were compromised in transit.

• Enhanced security: Identify and address risks early to help prevent security breaches.

• Legal compliance: Avoid legal complications and fines by ensuring compliance with licenses.

• Cost reduction: Manage software updates and patches efficiently, reducing maintenance costs.

• Reputation protection: Proactive risk management helps safeguard an organization's reputation.

• Supply chain resilience: Strengthen the software supply chain against cyber threats.

• Conduct regular audits: Review software components regularly to identify vulnerabilities.

• Perform patch management: Build a robust patch strategy from SBOM data, ensure timely updates, and enable VEX integration.

• Provide education and training: Train development and security teams on SBOM best practices.

• Perform vendor assessment: Independently verify a third-party vendor's security practices by generating an SBOM for its software package.

• Integrate continuously: Integrate SBOMs into the software development lifecycle for continuous monitoring.

What's the difference between an SBOM and a software manifest file?

An SBOM is intended to describe everything actually present in the finished software package. A manifest such as package.json or requirements.txt declares direct build-time dependencies. Manifest-derived SBOMs can be incomplete because compilation and packaging may add undeclared components.

How can an SBOM be inaccurate even after it is properly generated?

Tooling that reads declared dependency files can miss statically linked libraries, bundled runtime components, installers, and other additions. Research analyzing 44 packages found this method missed an average of 49.91% of a binary's actual components.

Is generating an SBOM legally required?

It depends on the market and buyer. The EU Cyber Resilience Act makes a complete SBOM a condition of selling products with digital elements in the EU. In the U.S., federal agencies determine SBOM information required for software contracts. Having an SBOM is not the same as being secure; teams must act on its findings, share it appropriately, and verify that it is complete.

How does binary analysis support SBOM accuracy?

Binary and behavioral analysis of finished software confirms what a package actually contains and does. It can reveal components that a manifest-based SBOM structurally cannot see.

• Spectra Assure for Software Supply Chain Security: https://www.reversinglabs.com/products/spectra-assure

Keep Learning:

• What is Binary Analysis? https://www.reversinglabs.com/glossary/complex-binary-analysis

• What is Agentic Supply Chain Security? https://www.reversinglabs.com/glossary/agentic-supply-chain-security

• What is Malware in the Software Supply Chain? https://www.reversinglabs.com/glossary/malware-in-the-software-supply-chain

Blog:

• What is the xBOM? https://www.reversinglabs.com/blog/what-is-the-xbom