Building a Better SBOM

Software is an important part of every business in 2023. And whether you are building it or deploying it, it’s absolutely crucial you know more than the potential attackers do about the weak links in your software supply chain.

The future usefulness of software bills of materials (SBOMs) depends on their ability to conform to standards, account for the entire codebase, and allow for interoperability at enterprise scale — something our industry has struggled to do in a uniform way.

Generating an SBOM is relatively easy. But generating a comprehensive and accurate SBOM that conforms to standard specifications and allows enterprises to interoperate with them at scale can be difficult. That’s why I coined the term “full Monty SBOM” to describe a comprehensive SBOM solution that provides the content and interoperability needed for its future utility for security, legal, and operational purposes. An SBOM that lacks this comprehensiveness could lead to invalid security or operational assumptions.

Standardization

For SBOMs to be universally exchanged and automatically read, their exchange format must conform to a standard specification.

The two standards that the industry is converging on are SPDX and CycloneDX. The goal of these standards is to establish uniformity in output, such that when two different SBOM generation tools are used to produce an SBOM of the same software, they produce the same results. These formats can be tailored to include, exclude, or link to certain information, such as licenses, copyrights, and vulnerabilities, depending on the use case and industry vertical.

It’s important to note that SPDX and CycloneDX are just standards describing the structure of an SBOM file. They do not address accuracy or comprehensiveness. If your SBOM generation process or tool feeds garbage into the file, it will produce (nicely formatted) garbage out.

Comprehensiveness

In almost any software application, the biggest attack surface consists of open source components. These make up an average of 76% of a software application and are developed by individuals from around the world. Log4j is an example of how a single vulnerability in a single open source component can have a massive global impact. For most organizations, one of the highest priorities in securing their software supply chain and safeguarding information infrastructures is rapid identification and remediation of open source software vulnerabilities.

There is a knee-jerk reaction by many that an SBOM is just an open source software (OSS) inventory. Most software composition analysis (SCA) vendors will produce some type of SBOM that lists the OSS components, with varying levels of transitive dependencies. However, an OSS-only SBOM can leave an organization exposed through vulnerabilities within other types of code that make up its software supply chain.

But a comprehensive — or full Monty — SBOM reveals all of an application’s ingredients, which includes custom code, open source components, and third-party non-OSS components. Since vulnerabilities can stem from all types of code and not just open source, this is critical.

Interoperability

SBOMs are static documents. Therefore, having one from a software supplier is of limited value if you can’t do anything other than inspect it. The real value is in your ability to do something with it — that is, its interoperability — and incorporate it into other life-cycle risk management processes, such as patch management and deployment risk assessments, all at enterprise scale.

Let’s look at three common things teams can do with an SBOM that’s interoperable: merge, query, and monitor.

• Merge: Automobile manufacturers will often need to aggregate multiple SBOMs produced by several different software vendors, using different standard formats, into a single system SBOM.
• Query: If there is a new zero-day vulnerability in a widely used software component, you will want to query all your SBOMs to determine which of your many software applications contains that specific vulnerable software component. This can be technically daunting when you have thousands of apps that must be examined for about 60 new CVEs per day. Being able to query thousands of SBOMs from one single interface is a key element of interoperability and effective software risk management.
• Monitor: With SBOMs that are designed to be interoperable, teams can integrate them with threat intelligence and vulnerability management systems so that, when a new zero-day vulnerability has surfaced, they can automatically inspect all their existing SBOMs for that specific vulnerability and notify its product life-cycle management system of the risk.

Not a Silver Bullet

A full Monty SBOM, albeit incredibly important, is just one small part of software supply chain risk management (SSCRM). Other factors include ensuring that custom code and OSS are free of security weaknesses and known vulnerabilities, that the software is compliant with regulations, and that the development pipeline is secure and tamper-resistant. You expect your food supply chain not to endanger your health; for example, you wouldn’t eat cookies containing unknown ingredients, manufactured in a factory open to cross-contamination, in conditions that violated health regulations. So too, you need assurance that your software supply chain is safe for your enterprise.

Whether dealing with cookies or software, ensuring that the product is safe to consume is the outcome of many safety and security processes and periodic testing performed during manufacturing — not simply having an SBOM in place.