putilov_denis - stock.adobe.com
How SBOMs for cybersecurity reduce software vulnerabilities
With SBOMs, companies will know what components constitute the software they purchase, making it easier for security teams to understand and manage vulnerabilities and risks.
If you want to know how important ingredient labeling is in food products, just talk to someone with a food allergy. Buying the wrong item at the grocery store could potentially kill them. Then, for the sake of argument, consider what shopping would be like if products didn't list ingredients at all.
The need to know what's in our food is much like the situation we're in as customers of purchased software. Modern applications are seldom monolithic. Each application we install, software package we purchase and cloud service we employ relies on a multitude of dependencies. These can take numerous forms:
- shared objects/libraries, such as dynamic link libraries;
- statically linked libraries;
- "borrowed" source code;
- supporting middleware, such as MariaDB, Tomcat and .NET;
- JavaScript libraries, such as jQuery and React; and
- underlying services, such as Apache and Nginx.
An application today is less a single product and more like a well-orchestrated supply chain of work product from a global development marketplace.
Unfortunately, this means that, when an underlying component has a security vulnerability, that risk propagates to the entire application. Remember the Heartbleed flaw that impacted the commonly used OpenSSL library? One reason that issue was so extensive had a lot to do with the ubiquity of OpenSSL as a dependency for other software. Large software vendors reported dozens to hundreds of vulnerable products that used the underlying library -- the Cisco alert page, for example, lists 80 affected products.
Considering organizations use 900 unique applications on average, according to MuleSoft, the complexities for users -- such as keeping track of resolution statuses, impacted versions of software and workarounds -- were legion.
Introducing software bill of materials (SBOM)
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, by identifying areas where attribution or other requirements are required. For operations teams, it means better visibility into packaged modules that might be deployed as a unit, such as what's running within a given Docker container.
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.
How SBOMs help cybersecurity
Security teams seeking to better understand, track and manage the vulnerabilities that may exist in the software they purchase and use will find it beneficial to know these resources and standards exist.
If your software suppliers won't provide an SBOM for cybersecurity, ask why. It's harder and harder for software suppliers to refuse to supply details about the software when there are multiple international standards -- along with supporting tools in the marketplace -- to facilitate sharing that data. As a software consumer, asking for these details and asking to be informed when they change enable you to make more informed decisions.
SBOMs can help suppliers, too. Alongside completing a security questionnaire or providing information about security practices, suppliers may also detail the provenance of components that constitute the software they distribute. This means they need to understand what goes into their software. While the exercise of documenting the underlying components may be challenging at first, establishing the discipline to be able to create and update it in an ongoing way is ultimately advantageous.
Whether you're a software customer or vendor, it's useful to start the SBOM discussions with internal teams now. At vendors, the security team should be planning for how to easily and reliably share provide SBOM information to customers. At customers, the security team should think through how they can use this information to maximum effect. Either way, SBOMs are here to stay.
