How SBOMs for cybersecurity reduce software vulnerabilities

To help prevent another Heartbleed, one strategy to consider is software bill of materials. Like the printed ingredients on a food label, an SBOM provides a list of the underlying software components a given application is dependent on, is packaged with or requires.

SBOMs enable transparency into “what’s inside the box” from an application standpoint. From a security standpoint, it means better understanding of transitive risks from underlying vulnerabilities lower in the application stack. For development teams, it helps ensure compliance with open source licenses — for example, Tremendous interest in SBOMs has emerged among end-user enterprises and regulators. For example, U.S. Executive Order 14028, “Improving the Nation’s Cybersecurity,” tasked the National Telecommunications and Information Administration (NTIA) with publishing a minimum set of elements for an SBOM. Draft guidance from the Food and Drug Administration on premarket submissions outlines the requirement for SBOMs as part of another BOM: the cybersecurity bill of materials, or CBOM, for medical devices.

Having a list of all the software constituting a given application, while useful, has some inherent complexities. Much like logistical supply chains, the software dependency chain is more than just one order deep. Each dependency for a given software module or library might be itself dependent on other software in turn and those modules dependent on others and so on. It’s less like a list and more like a hierarchical tree of relationships.

Because of these complexities, the NTIA documentation emphasizes automation to create and process an SBOM. The three standard approaches in the NTIA “Minimum Elements” document favor machine-readable, portable formats:

• CycloneDX, an Open Web Application Security Project standard using XML or JSON;
• Software Package Data Exchange, or SPDX, international standard codified in ISO/IEC 5962:2021; and
• Software identification, or SWID, tags, codified in ISO/IEC 19770-2:2015.