Supply chain attacks are on the rise, but many organizations aren’t ready to address them. In this LinkedIn Newsletter, Gonda Lamberink, cybersecurity executive at Bureau Veritas, explains how SBOMs will help you prepare for future supply chain threats. She emphasizes understanding the context of vulnerabilities, like whether software is truly exploitable, is indispensable to maximizing the value of SBOMs.

The threat: increased supply chain attacks

The widespread use of open-source components in software and vulnerabilities like Log4j and SolarWinds have exposed the fragility of supply chains.

In 2024, Sonatype in their 10th Annual State of the Software Supply Chain Report states that software supply chain attacks surged, doubling from the previous year. By August, more than 700,000 malicious open source software (OSS) packages had been identified - a staggering 156% year-over-year increase - underscoring the escalating risks for organizations that fail to manage their OSS dependencies effectively.

Despite rising risks to supply chains, organizations’ ability to respond is low. According to the World Economic Forum’s (WEF) Global Cybersecurity Outlook 2024, 55.9% of leaders believe that technologies like Generative AI currently give attackers an advantage, while only 8.9% see the cyber landscape favoring defenders. When it comes to supply chain attacks, 54% of organizations have an insufficient understanding of cyber vulnerabilities in their supply chain.

SBOMs: part of the solution

As a cybersecurity industry professional, I believe that SBOMs are a big part of the solution to this supply chain security problem and especially a current lack of software supply chain transparency. They have the potential to become an essential element of software security practices: they can facilitate supply chain collaboration and accountability to mitigate risks.

First: what is an SBOM?

An SBOM (Software Bill of Materials) is essentially a detailed list of all the components that make up a piece of software, much like the ingredient list on packaged food, written in a standard format. It catalogs all the open-source and proprietary software components. SBOMs give organizations transparency into their software supply chain, so that they can better manage their security risks, compliance requirements, and operational vulnerabilities.

Why do SBOMs matter?

Because SBOMs document the components of a software system or product, they are instrumental creating visibility into potential vulnerabilities and dependencies. Two high-profile incidents highlight the importance of SBOMs:

• SolarWinds (2020): Attackers injected malicious code during the software build process, compromising over 18,000 customers, including federal agencies and major corporations. While SBOMs couldn’t have prevented the attack, they would have provided crucial support: it could have helped organizations verify whether they were using the affected software version and act faster to address the risks.
• Log4j (2021): Everybody remembers this attack. A critical flaw in a widely-used Java library impacted millions of applications. Unlike SolarWinds, where the attack targeted a process, Log4j highlighted the risks of component dependency. Many organizations were unaware they relied on Log4j, causing delays in their response. Here, SBOMs would have been transformative. By giving organizations detailed visibility into software dependencies, SBOMs could have enabled to quickly identify Log4j usage, prioritize remediation, and would have really reduced the vulnerability’s enormous impact.

Regulatory push for use of SBOMs

Regulators and policy makers all over the world have recognized the importance of SBOMs. These are some regulation and policy key examples referencing and also mandating use of SBOMs:

• EU Cyber Resilience Act (CRA): Requires SBOMs for all digital products to address software vulnerabilities and strengthen accountability in supply chains.
• US Executive Order 14028: Mandates SBOMs for federal procurement of software, with guidelines from NTIA, NIST, and CISA supporting adoption.
• Sector-Specific Rules: Industries such as healthcare, transportation, and critical infrastructure now emphasize SBOMs to align with e.g., FDA cybersecurity guidelines, UNECE regulation for vehicle type approval, and NIS2 regulation.

How to use SBOMs in practice

Of course, regulations and policy do not equal action. I see a few things that the industry can do to help SBOMs take off and I would recommend software vendors and users to do the following:

• Vendors: Generate SBOMs at each stage of the software lifecycle (source, build, deployment) in accordance with widely used SBOM standard formats such as SPDX and CycloneDX. Implement automated systems for real-time updates to maintain accuracy.
• Integrators: Incorporate SBOMs into their solutions and maintain open communication with asset owners about their use and impact.
• Asset owners and operators: Leverage SBOMs to align procurement, operations, vulnerability management, and incident response processes with software security best practices.

The adoption of SBOMs becomes far more effective when organizations follow established or also still emerging standards, not only for their generation - such as formats like SPDX and CycloneDX - but also for their sharing and consumption.

In addition, my main advice is to integrate SBOMs with existing tools, including Software Composition Analysis (SCA), Continuous Integration/Continuous Deployment (CI/CD) pipelines, Governance, Risk, and Compliance (GRC) systems, and vulnerability management solutions, which greatly increases their usefulness, especially if used alongside other artifacts, just as important as an SBOM, like a Vulnerability Exploitability eXchange (VEX) file, containing the status and impact of vulnerabilities associated with an SBOM.

This approach transforms SBOMs from a static list into actionable knowledge that strengthens security, compliance, and operational workflows:

• Automation tools can streamline the creation, updating, sharing and consumption of SBOMs across the software lifecycle, reducing errors and increasing efficiency.
• Linking SBOMs with contextualized vulnerability data, threat intelligence feeds and governance frameworks enables organizations to address vulnerabilities and risks more effectively.

My conclusion: yes, SBOMs are a game-changer

Concluding: SBOMs are transforming supply chain security by addressing the need for visibility and accountability, particularly in critical sectors. They deliver insights that allow organizations to manage risks and identify vulnerabilities more effectively, as seen in industries like energy, where SBOMs play a key role in meeting compliance needs and maintaining operations.

So yes, to answer the question at the heart of this article: I believe SBOMs are a game-changer to supply chain security, especially when they are combined with context about exploitability of vulnerabilities through VEX files. SBOMs identify vulnerabilities, whereas VEX files effectively help prioritize and remediate real risks. Neither should be static artifacts: their full potential is realized through integration with among others CI/CD pipelines and vulnerability management systems, with automation ensuring they are consistently updated and remain actionable.