What’s Driving the Adoption of SBOMs? What’s Next for Them?

As the software bill of materials (SBOM) becomes ubiquitous for compliance and security purposes, what has previously been a nice-to-have option is fast becoming indispensable. If you want to do business with significant partners, such as public and federal organizations, and if you want to grow your business by floating your company or engaging in M&A activity, then you’re going to need SBOMs. This demand is driven by two key trends, one technical and the other legislative. Let’s take a brief look at each, how they drive this demand, and what they mean for the evolution of SBOMs.

Technical considerations: Components, dependencies, and the attack surface

More and more software and applications are being developed, using an escalating volume of components, each with its own growing set of dependencies. In many cases, as much as 90 percent of the code that organizations use comes from third-party open sources, and this doesn’t include the proprietary code that they also use and create. As a result, the potential attack surface is constantly and rapidly expanding. Consequently, Gartner estimates that by 2025, 45 percent of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021.

According to Mend.io’s Open Source Risk Report, open source vulnerabilities are on the rise. In the first nine months of 2022, Mend.io recorded a 33 percent growth in the number of open source software vulnerabilities that we added to our vulnerability database, compared with the same period in 2021. Moreover, our new research, Malicious Packages Special Report: Attacks Move Beyond Vulnerabilities, shows that the number of malicious packages published to npm and rubygems alone grew by an eye-popping 315 percent from 2021 to 2022. 

To do business effectively, and to assure partners that your software and applications are safe and compliant, you need to apply modern security best practices — and that means SBOMs. Robust security requires that every component and dependency be scanned, tested, and updated to ensure that they do not have vulnerabilities that can be exploited by malicious actors, or used as points of entry for malicious packages. This requires comprehensive visibility into every layer of your code bases, so that you can then swiftly identify and fix issues when necessary. SBOMs are vital for this.

Legislative considerations: Governments seek to impose guidelines for transparency

The global regulatory landscape is shifting as governments increasingly impose new cybersecurity guidelines and strategies designed to combat the rising threat of software supply chain attacks. Once again, these require the transparency and visibility of information that SBOMs provide.

Since 2022, the U.S. government has been escalating its action on software supply chain security, by publishing new guidelines, issuing an Executive Order on improving the nation’s cybersecurity, passing the Strengthening American Cybersecurity Act, and announcing the release of the Biden administration’s national cybersecurity strategy in 2023.

Meanwhile, the European Union has announced the introduction of its Digital Operational Resilience Act (DORA) for financial institutions and the Cyber Resilience Act (CRA) for software and hardware providers, both of which have been created to enforce software security and secure delivery of services.

The Australian government has released a discussion paper intended to develop a nationally coordinated cybersecurity strategy to make it the most cyber-secure nation in the world by 2030. And most recently, 10 agencies from Australia, Canada, Germany, The Netherlands, New Zealand, the United Kingdom, and the United States have collaborated to create a cybersecurity guide for software development organizations. The joint guidance, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default, addresses concerns raised in response to several recently identified critical vulnerabilities in multiple vendors’ software, particularly in industrial control systems (ICS) and supervisory control and data acquisition (SCADA) software.

In every case, these guidelines, recommendations, and strategies require more accountability from vendors and optimal visibility into their code bases, software, application components, and dependencies. SBOMs, which provide the high level of transparency that these governments now demand, have consequently become a key compliance tool. 

How will SBOMs evolve and how will their use develop?

SBOMs are primarily used to tell others what you have in your code base. They also act as an inventory to help track your components and dependencies to identify issues that may impact dependency health.

The challenge comes when you ask, “What should I do with all this information?” An ingredients list like this is only helpful for ensuring that these ingredients are correct. To ensure that your software and applications are secure and compliant, you need to do more than that. You need to make sure that these ingredients are being used and mixed in the right way. In short, the information that SBOMs provide only becomes powerful when you can do something with it to effect a positive outcome.

You can achieve this in two main ways. The first is to integrate your SBOM tool with your application security solution. The process of detecting and identifying vulnerabilities in your code bases necessitates a thorough review of your software, so it’s logical that a tool designed to audit and catalog your components would form part of these efforts. The second is to make your SBOM automatically actionable. Effectively, this means that your SBOM doesn’t simply catalog your components and dependencies; it also works within your application security solution to detect vulnerabilities and trigger the process of automatically remediating them.

As the technical, commercial, and governmental pressure mounts on developers and DevOps teams to produce secure code, SBOMs will become an integral part of how software is sold. You’ll need to adopt SBOMs to demonstrate to prospects and customers that what you’re offering is secure and compliant. I anticipate that, in the not-too-distant future, every contractual negotiation will eventually require the use of SBOMs.  To maximize their effectiveness, they’ll be actionable and will serve as a springboard into the automatic remediation of software vulnerabilities.