Last updated: May 2026 

A Software Bill of Materials (SBOM) addresses seven core risk areas in software supply chain security: vulnerability management, license compliance, dependency risk, provenance verification, incident response, regulatory compliance, and software transparency. Each area represents a category of exposure that organizations can reduce by maintaining an accurate, up-to-date SBOM across their software assets. 

As software supply chain attacks grow in frequency and federal mandates accelerate, SBOMs have moved from a best practice to an operational requirement. This article covers the seven risk areas an SBOM addresses and why each one matters for organizations managing software risk across critical infrastructure environments. 

How do SBOMs help identify and prioritize software vulnerabilities?  

In order to determine the severity of potential vulnerabilities, each component of the software – including its international equivalents and private sources – should be evaluated against published vulnerability databases such as the National Vulnerability Database (NVD).

Vulnerabilities should then be evaluated for exploitability using sources such as CISA’s Known Exploited Vulnerabilities (KEV) catalog and the Forum of Incident Response and Security Team’s (FIRST) Exploit Prediction Scoring System (EPSS).

To reduce false positives caused by vulnerabilities that might be present but not reachable (due to inoperative functions or other reasons), reachability should be evaluated. Reachability is presently a challenge when evaluating third-party software, as automated methods are still in the early stages of development. Vulnerability Exploitability eXchange (VEX) is one solution a supplier can be use to indicate the status of a software or software component with respect to exportability (e.g., affected, not-affected, etc.) – since they can more easily determine reachability through analysis of their own source code.

How do SBOMs address open-source dependency risks?

Software should be built upon well-maintained code. The Linux Foundation estimates that 70%-90% of any given piece of modern software solutions utilize free and open-source software (FOSS) as a dependency10. FOSS should be evaluated for being up to date, how well it is being supported, if there are any known compromises or malware, the reputation of those contributing to it, the appropriateness of its code review practices, and that its upstream dependencies are also up to date.

In some cases, FOSS components are abandoned, causing significant concerns for downstream consumers. This issue has become so prevalent that there are now companies that broker transactions between FOSS communities and commercial software providers to ensure that FOSS is actively maintained.

How do SBOMs help detect malware and compromised components? 

All components used should be evaluated for code contributions from a list of known or suspected malicious contributors, source code compromises, malicious packages, and build system compromises. The Open-Source Security Foundation’s (OpenSSF) Scorecard, for example, is one tool that the industry uses to evaluate risks in FOSS. Additional malware scans should be performed on the compiled software as well.

How do SBOMs verify the integrity of software components?

Most methods for identifying vulnerabilities rely on proper fingerprinting of software. If an SBOM includes a dependency but the hash value of the dependency does not match the source’s hash value, this means the code may have been altered, and there could be hidden risks such as malicious code or vulnerabilities.

How do SBOMs support software license compliance and obligation tracking?  

There are certain standard software licenses that bring obligations with them. Examples include the GNU General Public License (GPL) that requires any software that includes the license to also be made available under the same license, also known as copyleft. Mozilla Public License (MPL) allows for code modifications, as long as any code licensed under the MPL is kept in separate files and these files are distributed with the software. There are several other licenses with variations of these requirements. SBOM analysis tooling should indicate these obligations.

How do SBOMs identify foreign adversary influence in software? 

 Through various U.S. Government publications, China, Cuba, Iran, North Korea, Russia, and Venezuela have been designated as foreign adversaries. Software components should be evaluated for any potential influence from these adversaries, including reviewing code contributors and the affiliations of commercial entities contributing to software dependencies. 

How do SBOMs support secure software development attestation under EO 14028? 

NIST SP 800-218, Secure Software Development Framework, was released on February 3, 2022, as a framework for developing secure software throughout five phases of development: planning, architecture & design, implementation, testing, and deployment & operations. By using this framework, software producers (and their customers) can expect their software to have a lower risk of vulnerabilities, increased security, and long-term security cost savings from applying a secure-by-design approach.

The Cybersecurity and Infrastructure Security Agency (CISA) is preparing a Secure Software Self-Attestation Common Form to be used by suppliers to attest that key practices of NIST SP 800-218 are being followed. In general, suppliers selling software to U.S. government agencies will be required to attest to these practices under Executive Order (EO) 14028 and subsequent Office of Management & Budget (OMB) Memo No. M-22-18 and OMB Memo No. M-23-16.

The regulatory momentum around SBOMs has accelerated significantly since 2022. Executive Order 14028 established federal requirements for secure software development, including SBOM production for government software vendors. NIST SP 800-161r1 provides the C-SCRM framework that operationalizes these requirements across the supply chain. CIRCIA, currently in final rulemaking with enforcement expected in late 2026, further reinforces the need for software transparency as a prerequisite for rapid incident reporting. Organizations that wait for enforcement deadlines to build SBOM capabilities will find themselves behind — both regulatorily and operationally. 

Frequently Asked Questions About SBOMs

What is an SBOM and why does it matter?

A Software Bill of Materials (SBOM) is a complete inventory of all components, libraries, and dependencies that make up a software product. It matters because it gives organizations the visibility needed to identify vulnerabilities, verify software provenance, and demonstrate compliance with federal mandates, including Executive Order 14028 and emerging CIRCIA requirements.

Is an SBOM required by law?

For organizations providing software to the federal government, Executive Order 14028 establishes expectations around SBOM production and sharing. NIST SP 800-161r1 provides the implementation guidance. CIRCIA further reinforces the need for software transparency as part of incident reporting preparedness. While enforcement timelines continue to evolve, the regulatory direction is clear.

What is the difference between an SBOM and an HBOM?

An SBOM (Software Bill of Materials) catalogs the components of a software application. An HBOM (Hardware Bill of Materials) catalogs the components of a hardware product. Both are increasingly required for critical infrastructure vendors. Fortress supports both SBOM and HBOM analysis through the NAESAD network.

How does an SBOM help with incident response?

When a new vulnerability is disclosed, such as Log4Shell, organizations with current SBOMs can immediately determine which products in their environment contain the vulnerable component. Without an SBOM, identifying exposure requires manual scanning across every system, which takes days. With an SBOM, the answer is available in minutes.

Who needs to produce an SBOM under EO 14028?

Software producers and vendors who supply software to federal agencies are expected to produce and provide SBOMs as part of secure software development attestation requirements. Downstream, any organization in the federal software supply chain, including contractors and subcontractors, should be prepared to both produce and consume SBOMs.