Social:Transparency in the software supply chain

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. Transparency is one of the key security attributes of the software supply chain, as a deeper understanding of the chain enables participants to identify vulnerabilities and mitigate threats. 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.

Modern software is often assembled from third-party libraries and open-source components. According to research by the Linux Foundation and Synopsys, 96% of the commercial codebases analyzed contained open-source software, and 70–90% of a typical codebase may consist of open-source components. Without transparency, any software component can become a threat. As a result, companies may spend billions of dollars building robust external defenses, but this will not protect against vulnerabilities in legitimate software inside the perimeter. At the same time, supply chain attacks also erode trust between customers and their IT providers, as malicious code is often embedded in official updates with 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 differ from conventional attacks in that they follow a four-stage pattern: compromise, modification, distribution, and subsequent exploitation of the compromised or modified component. A defining feature of a supply chain attack is the introduction or manipulation of a change at an upstream stage, which is subsequently exploited at a downstream stage.

Transparency refers to the availability of knowledge about the chain, while validity concerns the integrity of operations and artifacts and the authentication of participants, and separation involves reducing unnecessary trust relationships and the radius of impact through compartmentalization. In this framework, transparency primarily helps during the pre-compromise and detection phases, as a clearer understanding of participants, operations, and artifacts makes it easier to identify weak links before attackers exploit them. Current major attack vectors include dependencies and containers, build infrastructure, and human participants, such as maintainers or developers.

History

Software supply-chain transparency developed from earlier efforts to document software components, long before the term came into widespread use in the cybersecurity field. Early component-documentation formats included SPDX, first published in 2011, and CycloneDX, first published in 2017. Initially, these formats were created to support license compliance, package identification, and tool compatibility. Their development helped shape a broader concept of software supply chain transparency, 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 SBOM attributes, metadata requirements, and operational recommendations for the creation, exchange, and use of SBOMs.

Major incidents that occurred following the SolarWinds attack have underscored the importance of transparency in vulnerability management and supply chain security. The Log4Shell vulnerability in the Log4j library, disclosed in December 2021, demonstrated how difficult it can be for organizations to identify a vulnerable component deeply embedded within applications and services. In 2024, an attempt to plant a backdoor in XZ Utils showed how attackers could exploit trust in open-source maintenance processes to introduce malicious code into widely used 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). An SBOM is a structured list of components, libraries, and tools used to build and distribute a software product, and it records dependencies in a way that helps organizations understand and assess their software supply chains. It can also be described as a formal record of components and their interdependencies, which gives users insight into their actual exposure to risks and threats. Five key areas of SBOM application in software supply chain security have been identified: vulnerability management, ensuring transparency, component evaluation, risk assessment, and ensuring supply chain integrity. In software supply chains, an SBOM documents all components, both open-source and proprietary.

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.

A related mechanism is build reproducibility. Reproducible builds are defined as build processes that make the compilation process deterministic, ensuring that the same source code always produces the same binary file. These builds are considered a foundational element for distributed verification, transparency-log maintenance, supply-chain workflow integration, and the creation of keyless signatures based on verifiable logs. Although reproducibility does not replace inventory or attestation, it gives external parties the ability to verify that the published binary file 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.

The NotPetya attack demonstrated how a compromised software update can disrupt global business operations. Hackers used the update servers of the Ukrainian company M.E.Doc, a developer of accounting software, to spread the malware. The attack initially affected Ukrainian government agencies and businesses, then quickly spread across the networks of multinational corporations. Its consequences were particularly severe for companies reliant on logistics and large IT systems. Maersk, which operated 76 ports and handled a significant share of global maritime shipping, was unable to carry out key operations and subsequently estimated its losses at approximately $300 million. Merck’s losses amounted to about $870 million, FedEx’s TNT Express unit suffered $400 million in losses, and other major companies incurred hundreds of millions of dollars in losses. The White House estimated the total global damage from 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.