.png)
What is an SBOM? Software Bill of Materials Explained
An SBOM is a machine-readable inventory of all software components in an application. Learn why it's now a federal requirement and what PE-backed software companies need to know.
Why SBOMs Exist: The Supply Chain Transparency Problem
Modern software is almost never built from scratch. An application running in a corporate environment might depend on hundreds of open-source libraries, which themselves depend on additional libraries, creating dependency chains that extend multiple levels deep. The Log4Shell vulnerability — discovered in December 2021 — existed in Log4j, a Java logging library so ubiquitous that it was embedded in thousands of enterprise applications whose developers and operators often did not know it was there. When the vulnerability was disclosed, organizations had to scramble to determine whether they were affected — because they lacked comprehensive visibility into their software dependencies.
An SBOM answers the question 'what is in this software?' with enough specificity to determine vulnerability exposure. When Log4Shell was disclosed, organizations with SBOMs for their applications could determine affected software in hours. Organizations without SBOMs spent days or weeks attempting to enumerate dependencies manually — during which time attackers were actively exploiting the vulnerability.
What an SBOM Contains
A complete SBOM includes: a list of all components in the software (libraries, frameworks, dependencies), the version of each component, the supplier or origin of each component, the license governing each component's use, the relationships between components (which depends on which), and the known vulnerabilities associated with each component at time of generation.
Two primary SBOM formats have emerged as standards: SPDX (Software Package Data Exchange), developed by the Linux Foundation and now an ISO standard, and CycloneDX, developed by OWASP. Both are machine-readable formats that can be integrated with vulnerability management tools for automated exposure assessment when new vulnerabilities are disclosed.
The Regulatory Mandate
SBOMs shifted from a best practice to a regulatory requirement through Executive Order 14028, signed by President Biden in May 2021 following the SolarWinds breach. The order directed NIST to publish guidelines for software security in the government's supply chain and required SBOMs for software sold to the federal government. CISA subsequently published guidelines on SBOM minimum elements and use cases. The FDA has required SBOMs for medical device software since 2023. The EU Cyber Resilience Act, effective 2024-2027, includes SBOM requirements for connected products sold in the EU.
The regulatory trajectory is clear: SBOMs are moving from federal government supply chain requirement to broader commercial expectation. Enterprise software buyers are increasingly requiring SBOMs from vendors as a condition of procurement.
SBOMs for PE Portfolio Companies
For PE due diligence, SBOMs are relevant in two distinct contexts. First, software companies in the portfolio — ISVs, SaaS businesses, technology-enabled services companies — may face SBOM requirements from their enterprise and government customers. A portfolio company that cannot produce SBOMs for its products is increasingly disadvantaged in enterprise sales processes and may face contract requirements it cannot fulfill. SBOM production capability is now a product maturity indicator for software businesses.
Second, all portfolio companies that run software are SBOM consumers — they benefit from requiring SBOMs from their software vendors as a condition of procurement. An organization that requires SBOMs from its critical software suppliers can assess vulnerability exposure systematically when new CVEs are disclosed, rather than manually auditing each supplier relationship after the fact.
The due diligence question for software portfolio companies: can they produce SBOMs for their products? Do they have the build pipeline tooling to generate SBOMs automatically? Is SBOM delivery part of their enterprise contract workflow? These questions distinguish mature software supply chain practices from those that will require post-close investment to meet enterprise customer requirements.
Related Reading
Log4Shell: The Vulnerability That Changed SBOM Policy
CVE-2021-44228, Log4Shell, was a critical remote code execution vulnerability in Log4j — a Java logging library embedded in an estimated 3 billion devices and thousands of enterprise applications. When it was disclosed in December 2021, CISA issued an emergency directive and the security industry scrambled to identify affected systems. The problem was that Log4j was so pervasively embedded in software supply chains — often as a transitive dependency of a dependency, invisible to the application developer — that most organizations could not quickly determine whether they were affected. Log4Shell was the inflection point that moved SBOMs from a niche software supply chain concept to a federal regulatory requirement. Executive Order 14028, which established the SBOM mandate for federal software procurement, followed Log4Shell by less than a year.
of enterprise software buyers plan to require SBOMs from their software vendors within the next two years, according to Gartner research. The SBOM requirement is moving from federal government mandate to commercial expectation, driven by the documented supply chain attack risk that SolarWinds and Log4Shell demonstrated.