SBOMs: the Premise, the Promise, the Peril

Are software bills of material (SBOM) the solution to your software woes? While there are opinions on both sides, the White House has begun to promote their use. Executive Order 14028 proposes that distributors of software “[provide] a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website.”

Some claim that SBOMs will revolutionize information security, enabling automation that will substantially reduce labor and risk. Others claim that they’re just another marketing gimmick piggy-backing on regulation. As usual, the truth is probably somewhere in between, but it’s clearly becoming important for organizations to understand what SBOMs can – and can’t – do today.

Bill of Materials

You might be familiar with the concept of a “bill of materials” (BOM) if you’ve ever worked in an engineering or manufacturing environment. And in many ways, bills of materials aren’t much different than the more common “bills of lading.” Bills of lading (BOL) date back to the 1500s, when their adoption was triggered by the growing complexity of supply chains as long-distance maritime trade and finance expanded.

One if By Land, Two if By Sea

The UN Convention on the Carriage of Goods by Sea, commonly referred to as the Hamburg Rules of 1978, codifies these historical standards, specifying that bills of lading should include:

  • a list of goods, including their “leading marks” – i.e., unique identifiers
  • the condition of the goods, including whether they have a “dangerous character”
  • basic legal facts and terms like title, agents, shipper names, and liability information

These BOLs helped all parties in the supply chain. Suppliers and shippers could better secure insurance, obtain trade financing, or settle disputes. Personnel handling materials on vessels or at ports or warehouses would better understand risk and value. And when new risks or policy changes arose – like blighted foodstuffs or excise taxes – institutions could react in more systematic ways.

Physical → Digital

In many ways, the modern bill of materials – and its Software Bill of Materials’ cousin – embody this original spirit of maritime supply chain. Except instead of a supply chain of physical goods crossing the world to create value-added products, our “digital” economy has created a vast trade in “digital” goods being combined into modern software and services.

Software Supply Chain Analysis

In this light, we can see how software bills of material can play an important role in software supply chain analysis, information security, and risk management broadly. Like their historical BOL ancestor, an SBOM is essentially:

  • a list of (software) goods, including their unique identifiers (e.g., package, version, hash)
  • basic legal facts and terms, like the author, copyright holder, and licensing terms

SBOMs help organizations understand what is “inside of an application,” just like BOMs and BOLs help organizations understand what’s in a product or shipment. The truth is that the exact nature of an SBOM is still evolving. Today, there are multiple – possibly conflicting – standards or formats being adopted or proposed by consumers, producers, and regulators of these digital goods. Yet despite this fragmented situation, there is increasing consensus around the “common denominator” of information. This consensus is best reflected by Executive Order 14028 and the National Telecommunications and Information Administration’s subsequent publication, The Minimum Elements For a Software Bill of Materials.

From the NTIA’s perspective, an SBOM is meant to provide foundational transparency. In their own words,

An SBOM is a formal record containing the details and supply chain relationships of various components used in building software. […] An SBOM provides those who produce, purchase, and operate software with information that enhances their understanding of the supply chain, which enables multiple benefits, most notably the potential to track known and newly emerged vulnerabilities and risks. […]

SBOM-Driven Solutions

Machine-readable metadata for software has the potential to revolutionize many areas of modern business. Here are a few examples of how SBOMs could improve the current state of affairs:

  • When vulnerabilities are disclosed today, many organizations struggle to identify affected components. SBOMs can provide this information quickly and efficiently without manual review or complex software composition analysis (SCA).
  • When regulations or standards related to export control, cryptography standards, or geopolitical sanctions change, legal and IT can immediately identify the impact.
  • Sales tax or value-added tax (VAT) programs can be implemented that are more fair and efficient.
  • Open source commercialization and sustainability can be promoted through clear, transparent usage metrics.

Achieving this vision would clearly have huge impacts on organizations, institutions, and even society as a whole. But will enough organizations actually adopt the SBOM standard to make these examples realized? And what regulatory or contractual “teeth” will ensure that software producers don’t share inaccurate or incomplete SBOMs?

Adoption + Coverage

For newly-created software or actively-maintained applications, software bills of material can both reduce risk and decrease labor costs for all parties involved. However, while adoption has been enthusiastic in some communities, broader adoption is unlikely to be rapid. For legacy software or abandoned and unmaintained libraries or applications, it’s not clear how the SBOM requirement would be effective.

Looking back over the last two decades, a number of organizations like OWASP have already pioneered similar standards or released basic, freely-available tooling. The NTIA’s SBOM proposal even incorporates other existing standards like SPDX, VEX, and SWID, none of which are uniformly adopted today.

While EO 14028 might serve as the catalyst to drive better adoption, it is also possible that pockets of the market will continue not to provide such information – for example, to protect trade secrets or obfuscate architecture to protect security. Based on these factors, many organizations should plan to maintain their own software composition analysis (SCA) capabilities for the foreseeable future. If your vendor doesn’t provide an SBOM, you will need to discover the components yourself.

From our perspective, SBOMs – along with standards like OpenChain (ISO/IEC 5230:2020) – have the potential to play an important role in the future of the digital economy. Realistically, however, they will become a necessary – but not sufficient – tool for organizations to manage risk. As long as legacy applications and smaller open source projects make their way into the software supply chain, additional audit and investigation will almost certainly be required for decades to come.

Perils of Transparency

While SBOMs present many opportunities for risk reduction, it is also true that they may expose some organizations to new risks. For example, producers or consumers of software could find themselves dealing with disputes related to trade secrets or reverse engineering related to SBOM information. Since SBOMs effectively provide a roadmap to the architecture and components of an application, the disclosure of this high-value IP might create uncomfortable situations.

Furthermore, what will happen when an SBOM is incorrect? We talk about at least four reasons why SBOMs generated using Software Composition Analysis (SCA) tools are wrong here. It’s easy to imagine other scenarios where software producers distribute “incorrect” SBOMs, either due to negligent practices or understandable errors or omissions. In some cases, components might be “lost” in the compilation or distribution process, or a transitive dependency installed via dynamic script might slip through the cracks. In other cases, components might be present – but metadata, like licensing or export control status fields, might be wrong.

Who will be liable in such a situation? Will further regulation like EO 14028, for Federal use or broader commercial application, create incentives or penalties to drive better data quality? Only time will tell, but such risks could disincentive adoption or create contracting frictions. Minimally, parties involved in producing or consuming SBOMs need to have strategies for risk management and contracting.

If you’re an organization that produces software and need help navigating this future, we’d love to talk. We provide both strategic and technical services, assisting in the evaluation of legal and business impact as well as implementing SDLC enhancements through CI/CD or other automation. Unlike other vendors, we understand the importance of legal and business considerations in this process.

If you’re an organization that is looking to enhance your vendor and risk management programs, we can also work with you to implement these technologies and standards as part of your compliance programs. As the scale of software usage increases in many organizations, automation can provide significant efficiencies and cost savings for ongoing ISO 27001 or SOC2 compliance.