A software supply chain is the components, libraries, tools, and processes used to develop, build, and publish a software artifact. This collection of dependencies is called a software supply chain, by analogy with supply chains of physical goods required for manufacturing. Companies with products that rely on complex software supply chains may implement strategies for supply chain risk management to try to improve supply chain security.
A software bill of materials (SBOM) declares the inventory of components used to build a software artifact, including any open source and proprietary software components. It is the software analogue to the traditional manufacturing bill of materials (BOM), which is used as part of supply chain management. SBOMs are a strategy for improving transparency in the software supply chain.
Most software products include third-party libraries and components, including proprietary software and open-source code libraries, which typically depend on a variety of upstream libraries and components in turn. According to an analysis by Synopsys in 2024, 96% of the commercial codebases they analyzed contained open-source software, and a Linux Foundation study in 2022 reported that 70–90% of a typical codebase consisted of open-source components. Along with the software libraries themselves, software supply chains may include package managers (such as PyPI and npm), tools (such as integrated development environments and static analyzers), and software as a service (such as GitHub and AI-assisted software development products).
The Heartbleed and Shellshock vulnerabilities in commonly-used software packages, discovered by security researchers and publicly disclosed in 2014, were examples of the need for vulnerability management approaches that include software composition analysis. The 2021 Log4Shell vulnerability in Log4j, a widely-used piece of software integrated into enterprise software, was in the software supply chains for many companies.
Software supply chain attacks compromise an upstream component, such as a widely-used library, a build tool, or a distribution channel, in order to simultaneously affect all downstream users of that component. Along with the SolarWinds attack in 2020, where a malicious update was installed by more than 18,000 organizations, the NotPetya attacks (2017 Ukraine ransomware attacks) and Kaseya VSA ransomware attack in 2021 were high-profile examples of software supply chain attacks. Another supply chain compromise, the XZ Utils backdoor in 2024, was caught by a security researcher shortly after it was released.
According to the Atlantic Council "Breaking Trust" project, software supply chain attacks are a common and effective tool used by state actors. Researchers have catalogued the attack surface into a taxonomy covering stages from source-code contribution to package distribution, linking attack vectors to real-world incidents and corresponding safeguards.
Software supply chain attacks are on the rise, and securing the chain is a complex challenge because its components—suppliers and partners—are implicitly trusted. While specific security measures vary widely, building a secure foundation relies on just a few core principles.
There are three complementary security properties: validity, separation, and transparency. Validity authenticates contributors and protects artifacts and build steps from tampering. Separation limits connections through which a compromise could spread. Transparency gives stakeholders information about the components, contributors, and processes behind a release. While SBOMs list dependencies and provenance records show how software was built to help identify exposed products, visibility alone cannot guarantee integrity.
An SBOM allows builders to make sure open-source and third-party software components are up to date and respond quickly to new vulnerabilities. Buyers and other stakeholders can use an SBOM to perform vulnerability or license analysis, which can be used to evaluate and manage risk in a product.
While many companies use a spreadsheet for general BOM management, there are additional risks and issues in an SBOM written to a spreadsheet, such as the inability to automatically enrich it with vulnerability data or integrate it into security toolchains. It is best practice for SBOMs to be collectively stored in a repository that can be part of other automation systems and easily queried by other applications.
Cybersecurity transparency studies, including TRACS 2025, identify the availability of SBOMs as one of the criteria used when purchasing information security solutions. However, not all enterprise security products provide publicly available SBOMs.Of the 14 companies included in the study, only Cisco, Kaspersky, and Microsoft have transparency centers for authorized source code review. Research on open-source ecosystems indicates that policy-driven SBOMs remain rare in practice: one large-scale study found that only about 0.56% of popular GitHub repositories contain SBOMs created in accordance with formal security or compliance policies. Also, according to other research, fewer than half of tested software projects include SBOMs in their releases, and many of those SBOMs are incomplete or do not fully conform to established standards. In the Java ecosystem, a study evaluating six SBOM generation tools found that they frequently produce inaccurate results, including bloated dependency lists that overreport components actually used. According to the results of corporate-level surveys conducted in 2023, approximately 60–76 % of enterprises require SBOMs from suppliers or have integrated SBOMs into procurement and supply-chain risk management processes. A 2025 survey of financial companies showed that 43 % are actively producing software bill of materials.
Signed attestations can record where a software artifact came from, which source and dependencies were used, and which steps in the build pipeline produced it. Provenance frameworks may help downstream users verify that a release was built by an expected process and help detect tampering between source retrieval, build, and distribution.
The Cyber Supply Chain Management and Transparency Act of 2014 was a failed piece of US legislation (bill) that proposed to require government agencies to obtain SBOMs for any new products they purchase and to obtain SBOMs for "any software, firmware, or product in use by the United States Government". The act spurred later legislation such as "Internet of Things Cybersecurity Improvement Act of 2017."
US President Joe Biden's Executive Order 14028 on Improving the Nation's Cybersecurity of May 12, 2021 ordered NIST and NTIA to lay down guidelines for software supply chain management, including for SBOMs. The NTIA outlines three broad categories of minimum elements of SBOMs: data fields (baseline information about each software component), automation support (the ability to generate SBOMs in machine- and human-readable formats), and practices and processes (how and when organizations should generate SBOMs). The "automation support" requirement specifies the need for "automatic generation," which is possible with the use of Software Composition Analysis (SCA) solutions.