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.[1]

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.[2][3][4]

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.[5][6]

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.[7] Attack vectors target dependencies, containers, build infrastructure, and the human factor (maintenancers, developers).[7]

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.[8][9] 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.[10]

In 2018, the U.S. National Telecommunications and Information Administration launched a multistakeholder process on promoting software component transparency.[11] 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.

In 2020, the SolarWinds Orion platform was compromised, and 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.[12][13]

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.[13] 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.[14] 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.[15] 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.[16]

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.”[17] 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.[18]

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.[19][20][21] Areas of SBOM application include vulnerability management, ensuring transparency, component evaluation, risk assessment, and ensuring supply chain integrity.[22]

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.[1][23]

The post-2021 push for SBOMs was aimed at ensuring transparency software components and identifying hidden parts of an application. This information can be used to prioritize patches, manage vulnerabilities, and support compliance work.[24]

Transparency also supports software traceability, which is essential for organizations that are increasingly being required not only to list software components but also to demonstrate how the software was created. Higher levels of assurance require signed, tamper-proof traceability and more isolated, verifiable build environments.[25] This is achieved through build reproducibility, 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.[26]

Incidents

According to the Atlantic Council's "Breaking Trust" project, software supply chain attacks are a common and effective tool used by state actors.[27] They use the SolarWinds compromise as an example: a malicious update was installed by more than 18,000 organizations.[28] The NotPetya attacks (2017 Ukraine ransomware attacks) and Kaseya VSA ransomware attack in 2021 are also examples of software supply chain attacks.[29]

The 2021 vulnerability in Log4j, a widely used piece of software deeply integrated into enterprise software, was in the software supply chains for many companies.[30]

Regulation and limitations

In policy responses adopted after 2021, software supply-chain transparency was viewed as a security control.[31] 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.[32]

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.[28] According to TRACS 2025, which covered the 14 most widely used corporate cybersecurity solutions, only three companies have implemented transparency centers.[33] 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.[22]

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.[34]

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.[35]
  • 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.[36]
  • Enterprise adoption: 60–76% of enterprises require SBOMs from suppliers or integrate them into procurement risk management.[37]

References

  1. 1 2 "The Minimum Elements For a Software Bill of Materials (SBOM)" (PDF). NTIA. July 12, 2021.
  2. ↑ "Cyber Resilience Act". EUR-Lex. 20 November 2024.
  3. ↑ "Request for Comment on 2025 Minimum Elements for a Software Bill of Materials" (PDF). DEPARTMENT OF HOMELAND SECURITY.
  4. ↑ "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)" (PDF). National Telecommunication and Information Administration. 2021-10-21.
  5. ↑ Sanger, David E.; Perlroth, Nicole; Barnes, Julian E. (2020-12-16). "Billions Spent on U.S. Defenses Failed to Detect Giant Russian Hack". The New York Times. ISSN 0362-4331. Retrieved 2026-05-26.
  6. ↑ Canada, Communications Security Establishment (2022-11-28). "The cyber threat from supply chains". Canadian Centre for Cyber Security. Retrieved 2026-05-26.
  7. 1 2 "SoK: Analysis of Software Supply Chain Security by Establishing Secure Design Properties". arxiv.org. Retrieved 2026-05-26.
  8. ↑ "SPDX Workgroup Releases Software Package Data Exchange Standard to Widespread Industry Support - Linux Foundation". www.linuxfoundation.org. Retrieved 2026-01-21.
  9. ↑ "CycloneDX joins OWASP as a flagship project | OWASP Foundation". owasp.org. Retrieved 2026-01-21.
  10. ↑ Wang, Chengjie; Wu, Jingzheng; Lyu, Hao; Ling, Xiang; Luo, Tianyue; Wu, Yanjun; Zhao, Chen (2026). "A Large Scale Empirical Analysis on the Adherence Gap between Standards and Tools in SBOM". ACM Transactions on Software Engineering and Methodology 3788692. arXiv:2601.05622v1. doi:10.1145/3788692.
  11. ↑ "Multistakeholder Process on Promoting Software Component Transparency". Federal Register. 2018-06-07. Retrieved 2026-01-21.
  12. ↑ "Executive Order 14028 SBOM Requirements". Sbomify. Retrieved 2026-01-21.
  13. 1 2 Street, Arch (2021-07-12). "Software Bill of Materials Minimum Elements Defined by NTIA". View from Arch Street. Retrieved 2026-01-21.
  14. ↑ "White House prioritizes software security, assesses OT | Cybersecurity Dive". www.cybersecuritydive.com. Retrieved 2026-08-26.
  15. ↑ "CSDL | IEEE Computer Society". www.computer.org. Retrieved 2026-05-26.
  16. ↑ Przymus, Piotr; Durieux, Thomas (2025-04-24). "Wolves in the Repository: A Software Engineering Analysis of the XZ Utils Supply Chain Attack". arXiv.org. Retrieved 2026-05-26.
  17. ↑ Poireault, Kevin (2025-09-05). "US and 14 Allies Release Joint Guidance on Software Bill of Materials". Infosecurity Magazine. Retrieved 2026-01-21.
  18. ↑ "EU CRA SBOM Requirements: Overview & Compliance Tips". Anchore. Retrieved 2026-01-21.
  19. ↑ "For Good Measure Counting Broken Links: A Quant's View of Software Supply Chain Security" (PDF). USENIX ;login. Archived (PDF) from the original on 2022-12-17. Retrieved 2022-07-04.
  20. ↑ "[Part 2] Code, Cars, and Congress: A Time for Cyber Supply Chain Management". Archived from the original on 2015-06-14. Retrieved 2015-06-12.
  21. ↑ "Software Bill of Materials". ntia.gov. Archived from the original on 2022-11-30. Retrieved 2021-01-25.
  22. 1 2 "Software Bill of Materials in Software Supply Chain Security: A Systematic Literature Review". arxiv.org. Retrieved 2026-05-26.
  23. ↑ "Automating compliance tooling" (PDF). NTIA. 17 June 2021.
  24. ↑ Townsend, Kevin (2023-06-05). "SBOMs - Software Supply Chain Security's Future or Fantasy?". SecurityWeek. Retrieved 2026-05-26.
  25. ↑ "Supply Chain Security: Provenance Tools Becoming Standard in Developer Platforms". InfoQ. Retrieved 2026-05-26.
  26. ↑ Fourné, Marcel; Wermke, Dominik; Enck, William; Fahl, Sascha; Acar, Yasemin. "t's like flossing your teeth: On the Importance and Challenges of Reproducible Builds for Software Supply Chain Security" (PDF). Saschafahl.
  27. ↑ "Breaking trust". Atlantic Council. Retrieved 2026-05-26.
  28. 1 2 "Broken trust: Lessons from Sunburst". Atlantic Council. 2021-03-29. Retrieved 2026-05-26.
  29. ↑ Barrett, Brian. "A New Kind of Ransomware Tsunami Hits Hundreds of Companies". Wired. ISSN 1059-1028. Retrieved 2026-04-22.
  30. ↑ "Widely used software with key vulnerability sends cyber defenders scrambling". Reuters. Archived from the original on 2025-07-22. Retrieved 2026-05-26.
  31. ↑ "Improving the Nation's Cybersecurity". Federal Register. 2021-05-17. Retrieved 2026-08-26.
  32. ↑ "Executive order aims to protect software supply chains". Reuters. Archived from the original on 2021-11-22. Retrieved 2026-05-26.
  33. ↑ "TRANSPARENCY REVIEW AND ACCOUNTABILITY IN CYBER SECURITY 2025" (PDF). WKO.
  34. ↑ "Why a near-miss cyberattack put US officials and the tech industry on edge". Reuters. Archived from the original on 2025-01-17. Retrieved 2026-05-26.
  35. ↑ Novikov, Oleksii; Fucci, Davide; Adamov, Oleksandr; Mendez, Daniel (2025-09-01), Policy-driven Software Bill of Materials on GitHub: An Empirical Study, arXiv:2509.01255
  36. ↑ Nocera, Sabato; Romano, Simone; Di Penta, Massimiliano; Francese, Rita; Scanniello, Giuseppe (2025-12-01). "On the adoption of software bill of materials in open-source software projects". Journal of Systems and Software. 230 112540. doi:10.1016/j.jss.2025.112540. ISSN 0164-1212.
  37. ↑ Ian Barker (2023-08-03). "Supply chain worries drive adoption of SBOMs". BetaNews. Retrieved 2026-01-17.
This page is issued from Wikipedia. The text is available under Creative Commons Attribution-Share Alike 4.0 unless otherwise noted. Additional terms may apply for the media files.