Software Bill of Materials (SBOM)

What is Software Bill of Materials (SBOM)?

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component, library, dependency, and module that makes up a software application — including open-source packages, third-party frameworks, and their specific versions. The concept extends the manufacturing bill of materials to software, giving organizations visibility into exactly what is running in their environments. U.S. Executive Order 14028 mandated SBOMs for software sold to the federal government, and CISA has been driving SBOM adoption as a foundational supply chain attack defense since 2021.

Description

SBOMs address a fundamental visibility problem in software security: most organizations cannot answer the question 'are we affected by this vulnerability?' quickly, because they have no complete inventory of what software components are running in their environment. When a critical vulnerability is disclosed — like Log4Shell, which affected millions of applications using the Log4j logging library — organizations with SBOMs could query their inventory and identify affected systems in minutes. Organizations without SBOMs spent weeks manually searching. SBOMs are commonly produced in two standardized formats: SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP), both supported by automated generation tools that analyze source code or compiled binaries. In DevSecOps pipelines, SBOM generation is integrated into CI/CD workflows so that every build produces an updated inventory. The closely related Vulnerability Exploitability eXchange (VEX) standard extends SBOMs by documenting whether a known vulnerability in a listed component actually affects the product — reducing false-positive noise in vulnerability management. As AI systems become software components themselves, AI Bills of Materials (AI BOMs) are emerging as a specialized variant, inventorying model weights, training datasets, and fine-tuning parameters alongside traditional software dependencies.

Usage and Examples

A healthcare software vendor ships a medical device management platform to hospital systems. When a critical vulnerability is disclosed in a popular JSON parsing library, each hospital's security team needs to determine if the vendor's product is affected. Without an SBOM, this requires manual analysis of the vendor's code — which hospital security teams cannot perform. With an SBOM, a simple query against the component inventory answers the question in seconds. The vendor can also issue a VEX document clarifying whether the specific code path containing the vulnerability is reachable in their product, further reducing unnecessary patching effort. For organizations managing third-party risk, requiring SBOMs from software vendors is increasingly a procurement standard, creating contractual accountability for software supply chain transparency.

How Does This Relate to Penetration Testing?

SBOMs directly inform penetration testing scope and efficiency. During application penetration testing engagements, testers use SBOM data to identify known-vulnerable components that warrant focused exploitation attempts, rather than rediscovering the component inventory from scratch. For supply chain attack scenario testing, SBOM analysis reveals third-party dependencies that represent transitive attack paths — a compromised upstream library could affect the target application even if the application's own code is secure. Organizations implementing SBOMs as part of a DevSecOps program benefit from faster time-to-remediation when penetration tests identify vulnerable components, because the inventory context already exists to determine scope of impact. Evolve Security's Application Penetration Testing engagements assess both application-layer vulnerabilities and the security posture of third-party components — helping organizations understand their full software supply chain exposure.