Transparency in the software supply chain is a condition in which participants involved in the development, procurement, operation, auditing, or regulation of software can determine which components, dependencies, build stages, identifiers, and relationships within the supply chain make up the delivered product. The disclosure of information about software components, their interrelationships, origins, and development methods—for the purposes of risk management, vulnerability detection, and compliance—takes place throughout the software lifecycle. Problems in the software supply chain can cause billions in losses and create operational challenges for government and commercial entities, as demonstrated by incidents involving SolarWinds, Bybit, 3CX, Jaguar Land Rover, GitHub, and NotPetya. Software often uses third-party open-source libraries and components (according to a study by the Linux Foundation and Synopsys, 96% of the commercial codebases analyzed contained open-source software, and 70–90% of a typical codebase consisted of open-source components), which, if transparency is not maintained, can pose a threat within the security perimeter. Supply chain attacks undermine trust between customers and their IT vendors, as malicious code is often embedded in official updates that are accompanied by certificates and digital signatures. One of the primary ways to ensure transparency is through a software bill of materials, which documents the components used to create the software and the relationships within the supply chain.
Concept The software supply chain is the collection of systems, devices, people, artifacts, and processes involved in the creation of the final software product. Attacks on the software supply chain follow a four-stage pattern: compromise, modification, distribution, and subsequent use of the compromised or modified component. A distinctive feature of a supply chain attack is the introduction or manipulation of a change at one of the preceding stages, which is then exploited later. Transparency ensures that all elements are visible, reliability guarantees their integrity, and compartmentalization limits trust to minimizing consequences of breach. Transparency is effective before a breach occurs and when it is detected, making it easier to identify vulnerabilities before attackers can exploit them. Attack vectors target dependencies, containers, build infrastructure, and the human factor (maintenancers, developers).
History Transparency in the software supply chain has evolved from earlier efforts to document software components using the SPDX (since 2011) and CycloneDX (since 2017) formats. Developers created these formats to ensure compliance with license agreements, identify software packages, and guarantee tool compatibility; this development gave rise to a concept encompassing component documentation, disclosure practices, risk management, security analysis, and regulatory compliance. In 2018, the U.S. National Telecommunications and Information Administration launched a multistakeholder process on promoting software component transparency. This process helped move work on SBOMs from a specialized technical practice into the realm of policy and procurement to identify components used in software products. The 2020 compromise of the SolarWinds Orion platform made software supply chain security a central issue in government cybersecurity policy. An analysis of the “Sunburst” campaign prepared by the Atlantic Council noted that the vulnerability of the software supply chain had become a realized risk for national-security agencies. In May 2021, U.S. President Joe Biden issued Executive Order 14028, which directed federal agencies to improve cybersecurity and increase transparency in the software supply chain, including requirements related to SBOMs. Reuters reported that the executive order required software developers selling their products to the federal government to provide greater visibility into their software and make security data available. In July 2021, the NTIA published the document “The Minimum Elements for a Software Bill of Materials (SBOM)”, defining the basic data fields and practices for creating SBOMs. Between 2021 and 2025, the U.S. Cybersecurity and Infrastructure Security Agency updated its guidance on “Framing Software Component Transparency”, expanding the set of attributes, metadata requirements, and operational recommendations for the creation, exchange, and use of SBOMs. The SolarWinds attack and other incidents have highlighted the importance of transparency in managing vulnerabilities and maintaining supply chain security. The Log4Shell vulnerability in the Log4j library, which came to light in December 2021, demonstrated the difficulty companies face in identifying vulnerable components deeply embedded within applications and services. In 2024, an attempt to implant a backdoor in XZ Utils demonstrated how attackers exploit trust in open-source software maintenance processes to inject malicious code into infrastructure software. By the mid-2020s, software supply chain transparency had become part of international cybersecurity coordination and regulation. On September 3, 2025, Japan's Ministry of Economy, Trade and Industry and the National Cybersecurity Office, in collaboration with cybersecurity agencies from 15 countries, released the document “A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity.” In the European Union, the Cyber Resilience Act required manufacturers of products with digital elements to create, maintain, and retain SBOMs as part of the technical documentation for software placed on the EU market.
Transparency mechanisms
The primary mechanism for ensuring transparency is the Software Bill of Materials (SBOM), a structured list of components, libraries, and tools used to create and distribute a software product. Another definition is a formal list of components and their interdependencies, which gives users insight into their actual exposure to risks and threats. An SBOM documents dependencies between elements and helps assess and understand software supply chains by identifying all components—both open-source and proprietary. In software supply chains, the SBOM documents all components—both open-source and proprietary. Key areas of SBOM application include vulnerability management, ensuring transparency, component evaluation, risk assessment, and ensuring supply chain integrity. Under Executive Order 14028, U.S. federal agencies require software suppliers to provide SBOMs for government-procured software. The list of minimum required SBOM elements defined by NTIA includes three main categories: required data fields for describing each component (name, version, identifiers), automation support (machine-readable format, generation tools), and recommendations for creating SBOMs during development and purchasing. The post-2021 push for SBOMs was intended to provide visibility into the components used within software and to expose parts of an application that would otherwise remain hidden. This information can be used to prioritize patches, manage vulnerabilities, and support compliance work. Transparency also supports software traceability, which is becoming a standard feature of developer platforms. Traceability has become important because organizations are increasingly required to demonstrate how software was created, rather than simply listing its components. Higher levels of assurance require signed, tamper-proof traceability and more isolated, verifiable build environments. This is achieved through build reproducibility—a deterministic compilation process (the same source code always generates the same binary file). This is an element of distributed verification, transparent logging, supply chain workflow integration, and the creation of key-less signatures based on verifiable logs. Reproducibility does not replace inventory or attestation, but organizations can verify that the published binary corresponds to the declared source code and build process.
Strategic consequences of opacity The strategic importance of transparency lies in the scale and impact of attacks on the software supply chain. The Atlantic Council's “Breaking Trust” project notes that attacks on the software supply chain are a common and effective tool used by state actors, and that attackers use such attacks to gain access to critical infrastructure, including power systems and nuclear facilities. At the same time, the security of the software supply chain remains underestimated in national security policymaking precisely because modern government and private institutions depend on software that is constantly updated and often developed outside the institutions that rely on it. The SolarWinds compromise is an illustrative example. A malicious Orion update was installed by more than 18,000 organizations, and this campaign was a large-scale intelligence operation, not an incident involving a single specific vendor. The attackers gained access to the email systems of the U.S. Department of the Treasury, the Department of Justice, and the Department of Commerce, and CISA assessed that this campaign affected not only federal agencies but also state and local governments, critical infrastructure, and private organizations. In the NotPetya attack, a compromised software update distributed via the update servers of M.E.Doc, a Ukrainian accounting software developer, disrupted global business processes. Ukrainian government agencies and businesses were the first to be targeted, and the attack then spread across the networks of multinational corporations. Companies reliant on logistics and large IT systems were hit the hardest. Maersk, which operated 76 ports and accounted for a significant share of global maritime shipping, was unable to carry out key operations and suffered losses of approximately $300 million. Merck’s losses amounted to about $870 million, while FedEx’s TNT Express division lost $400 million. The White House estimated the total global damage caused by NotPetya at more than $10 billion. In the 2021 compromise of Kaseya’s remote management software, used by managed service providers, between 800 and 1,500 companies were affected; in Sweden, hundreds of supermarkets closed due to failures of point-of-sale systems; and in New Zealand, schools and daycare centers were shut down. The Log4j vulnerability demonstrated how difficult it is for organizations to respond to incidents if they do not know which software components they are using. Log4j was widely used and deeply integrated into enterprise software, forcing security professionals to quickly identify vulnerable systems and apply patches. Experts also warned that this vulnerability was likely to appear across many software supply chains. This incident became a key example in discussions about transparency in the software supply chain, as the problem—beyond the vulnerability itself—was that many organizations could not easily determine exactly where the vulnerable library was present in their own software and infrastructure.
Regulation and limitations In policy responses adopted after 2021, software supply-chain transparency was increasingly viewed as a security control. Executive Order 14028 was aimed at protecting U.S. federal software supply chains by introducing new security requirements for software sold to the government. Specifically, developers were required to provide greater transparency regarding their software and to submit SBOMs and security data. By 2025, transparency and verifiable provenance had become increasingly important—regulators began to expect evidence of these practices, citing both the framework of U.S. presidential executive orders and the European Union's Cyber Resilience Act as driving forces behind this trend. Transparency is not a complete remedy for software supply chain risks. There are practical limitations, including generation tooling, standardization, sharing, maintenance, false positives, hidden components, data privacy, and tampering. Even after the policy push that followed Executive Order 14028, effective use of SBOMs remained difficult. According to TRACS 2025, which covered the 14 most widely used corporate cybersecurity solutions, only three companies have implemented transparency centers. A 2025 review also reported that only 18% of the 412 organizations surveyed by the Linux Foundation had SBOM practices, although the survey also showed that 90% of the surveyed organizations had started or were planning their SBOM practices, and that 54% were already addressing SBOMs in some form. The XZ Utils incident in 2024, when attackers were almost able to introduce a backdoor into a critical component used by virtually all Linux systems running servers around the world, showed that transparency systems still depend on the social and institutional health of the ecosystems they are intended to make visible.
Adoption Policy-driven SBOMs in open-source projects: 0.56% of popular GitHub repositories contain SBOMs created in accordance with formal security or compliance policies. SBOM adoption in projects: Less than 50% of the software projects studied include an SBOM in releases or version control systems, with many SBOMs being incomplete or not conforming to relevant standards. Enterprise adoption: 60–76% of enterprises require SBOMs from suppliers or integrate them into procurement risk management.
References