Paying the bill: will SBOM save the software supply chain?

Open-source software is the basis of almost every single application – but it also hides a multitude of threats.

By identifying and tracking its various components, a software bill of materials (SBOM) can help organisations identify and manage the risks associated with bad code. SBOMs are now mandated by the US government, but not everyone is jumping for joy. 

Why SBOMs are more important than ever 

Recent analysis suggests open-source software amounts to around 80% of code in use today. It’s a crucial resource for developers, but there’s a sting in that tail. Once malware has been inserted in open-source dependencies, it can spread like wildfire, with an attack spreading from one software vendor to tens of thousands of customers. The SolarWinds hack hit organisations right across the world, while Log4Shell impacted countless unpatched applications and assets. 

Many experts feel supply-chain attacks will only get bigger. Aanchal Gupta, who leads Microsoft's Security Response Center, describes these attacks as “just the tip of the iceberg”, thanks to the ubiquity of libraries such as Log4j (the source of the Log4Shell vulnerability). “I compare it to salt in the food items in your pantry," she says. "If I were to tell you to throw out all the things that have salt, you would say: do you want my pantry to be empty? Because it's just everywhere.” 

The US government wants you to use SBOMs 

Gupta isn’t the only commentator to compare the software we put into our networks with the food we put into our bodies. A software bill of materials is the recipe that tells us whether open-source code does what it should – or whether it contains poisonous additives like malware. It provides metadata that identifies a software component and its dependencies, offering visibility into the software supply chain. 

SBOM has friends in high places. In 2021, US President Joe Biden signed an executive order declaring that open-source software must try to provide an SBOM, and that government agencies must obtain SBOMs from their suppliers. Then in 2022, the Linux Foundation released a series of research tools on the topic, describing SBOM as “no longer optional”, and noting that 4 out of 5 organisations expected to use SBOMs that year. The Australian Cyber Security Centre (ACSC) recommends that an SBOM is “produced and made available to consumers of software”, and recommends using the US standard as a start point. 

SBOMs can help your organisation manage software supply chain risks 

By identifying components and therefore possible vulnerabilities, SBOMs can help you choose which software to use and how to manage any risks its code may carry. A comprehensive SBOM can save hundreds of hours of analysis and remediation for a single organisation, and mean vulnerabilities that might have sat unidentified for months or even years (as happened with Log4Shell) can be patched in minutes. 

SBOMs bring other benefits. They can make code easier to manage and facilitate policies such as having a list of components that can be automatically approved or rejected. The widespread use of SBOMs, meanwhile, can help governments and other bodies assess the prevalence of certain vulnerabilities or understand the spread (and potential overlap) of different dependencies. 

By showing the origin of individual components, meanwhile, an SBOM can make it easier to triage and cross-reference vulnerabilities. By offering visibility, SBOMs build trust and help assure you and your partners that any product you are providing or using is secure and reliable. SBOMs allow communication throughout a supply chain that is only as strong as its weakest link, and make it easier to track not just cybersecurity vulnerabilities, but also of the legal and licensing issues that may accompany individual components. 

But SBOMs aren’t for everyone (yet) 

Linux’s survey flags real benefits to SBOMs, with 51% of respondents saying they make it easier to understand dependencies across components, and 49% saying that they make it easier to monitor for vulnerabilities. But while that’s plenty of approval, it’s not unqualified support. SBOM faces serious challenges: 

• SBOMs take time. Tracking components can be a lengthy process, and staff must be trained in appropriate tools that hit appropriate standards for you and your partners. 

• As software changes, so must its bill of materials. Every new component release requires an update, taking time and resources – particularly for frequently updated cloud-based services. 

• The data in SPOMs is most useful for comparison and exchange when it is presented in a universal way, but there are several different formats (including SPDX and CycloneDX). You may need to support more than one. 

• SBOMs can create false confidence. Some only go one layer deep, and thus miss vulnerable components, while others may not track individual lines of code or functions or may simply contain mistakes. An SBOM should delve into the deepest dependencies and be verified by binary scans to ensure full coverage and accuracy. 

• Vulnerabilities emerge when components are used together. Context is therefore vital – an individual component may only become a problem if it is used in a certain way. Recording this takes extra time – but without it SBOMs may generate false alarms. 

SBOMS may not be flawless, but they’re a vital security tool 

A software bill of materials can help organisations identify vulnerabilities, manage risks and track compliance. But building effective SBOMs is a time-consuming, ongoing project, and businesses should think carefully about the potential rewards before moving forward. Given the growing enthusiasm for SBOMs, they may become mandatory in more and more contexts. But until then, organisations must weigh up the costs and benefits of a software bill of materials.