The five dimensions of SBOM quality

In a memo issued on June 9, the Office of Management and Budget clarified details about how agencies will be required to collect cybersecurity attestations from software providers whose services they use.

According to the new guidance:

1. Agencies will have more time to collect letters of attestation
2. Letters of attestation will not be required for open-source software
3. Agency Chief Information Officers (CIOs) will have discretion over whether software is considered “agency-developed”
4. Companies unable to immediately provide letters will be able to submit a “plan of action and milestones” 

The memo comes as the Biden administration works to strengthen the cybersecurity of commercial technology products used in government, and after it last year announced that agencies would have to collect letters from software vendors confirming their products adhere to NIST standards.

“It's high time,” said Tom Kellermann, senior vice president of Cyber Strategy for Contrast Security. “Accountability is paramount given the number of vulnerabilities that are metastasizing in software.   Plausible deniability is no longer acceptable.”

SBOM quality

But the problem remains: How do you handle the flood of self-attestations, particularly given that there’s no one standard to make them machine-readable? While there’s been much talk about Software Bills of Materials (SBOMs) — the new requirements for federal agencies to only use “software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance” — it’s clear that all SBOMs aren’t created equal. 

There’s been a good deal of talk lately about the quality of SBOMs and what it means to have a “quality” SBOM. While there are open-source tools that try to guesstimate quality, none do a good job because there’s minimal data on which to base the assessment. The question of quality has been brought up within the Cybersecurity and Infrastructure Security Agency (CISA), where the OWASP Software Component Verification Standard (SCVS) has repeatedly been suggested as one possible path to assessing SBOM quality. 

While SBOMs have been likened to ingredient labels on packaged food, just knowing what ingredients went into a bowl of soup won’t prevent you from getting food poisoning if you eat it. 

If you don’t want to ingest toxins, you also need to know how that soup was prepared. For example, was the restaurant following proper sanitation rules? Were any kitchen workers who handled the soup ingredients ill with Norovirus at the time? Did the meat delivery truck have any issues with its refrigeration system?

A list of ingredients won’t tell you any of that. The same is true of the components that go into software: Just because you know that software incorporates a component with a known vulnerability doesn’t mean that it poses an Application Security (AppSec) risk, given that much depends on how, and if, that component is actually invoked. 

“SBOMs express a lot more than a list of ingredients,” says Jeff Williams, co-founder and CTO of Contrast Security. “A list of ingredients by itself doesn't tell you much. The same set of ingredients could be in software that is secure or software that isn’t.”

But there’s hope. The Open Web Application Security Project (OWASP) CycloneDX project is going to make it possible for vendors and agencies to use a machine-readable attestation format that will help to handle producing and consuming these attestations, create databases, apply policy, create alerts, and generally manage the massive volume of attestations required in a large agency or a large vendor.

As it is, a complete and accurate inventory of all first-party and third-party components is essential for risk identification. BOMs should ideally contain all direct and transitive components and the dependency relationships between them. There are currently multiple main SBOM standards, but only one, CycloneDX, is designed to provide transparency not just about software components, but also about things such as software dependencies and the services that the software calls. 

In fact, only one of the two standards — again, CycloneDX — has been developed by actual security practitioners.

Introducing CycloneDX 1.5: Turning requirements into code

In keeping with its track record of revealing new, innovative ways to leverage SBOM, OWASP on Friday, June 23 released CycloneDX version 1.5: a version of the SBOM standard that opens up SBOM adoption to new industries and introduces numerous ways to customize CycloneDX SBOMs to indicate quality, show transparency and expedite vulnerability remediation while increasing trust in the supply chain.

CycloneDX v1.5 further expands visibility and security benefits to new industries through generation of xBOMs, which pushes the concept of a CycloneDX BOM beyond being restricted to software in order to bring the same benefits to hardware, operations, manufacturing and many more applications.

For example, SaaSBOM, or a Software as a Service BOM, provides an inventory of services, endpoints, and data flows/classifications that power cloud-native applications. A Hardware Bill of Materials, or HBOM, supports documentation of components, devices, firmware, configurations and many other fields that make it ideal for producers of consumer electronics, IoT devices and embedded devices. CycloneDX xBOMs can also be combined to represent a product ecosystem. For a full-stack product offering, a company can generate an HBOM for devices in the field and a SaaSBOM for the services those devices rely on. Even databases and message queues (MQs) can be expressed in CycloneDX. With ML-BOMs, even a model for machine learning can be expressed in CycloneDX to communicate its provenance, or how it was evaluated and trained.

Adopting CycloneDX allows organizations to quickly meet, and to far exceed, the Minimum Elements for Software Bill of Materials as defined by the National Telecommunications and Information Administration (NTIA) in response to U.S. Executive Order 14028. Adopting CycloneDX allows organizations to quickly meet these minimum requirements and mature into using more sophisticated use cases over time. CycloneDX is capable of achieving all SBOM requirements defined in the OWASP Software Component Verification Standard (SCVS).

A primer on SBOM quality

As it is, depending on which SBOM standard is in use, it’s possible to tinker with the manifests, in that developers can directly manipulate the BOM by, for example, changing  the name of something and thereby rendering the bill of materials untrustworthy. 

In contrast, with CycloneDX, OWASP has carved SBOM quality into five dimensions that bring ways to assure quality directly into the spec itself: breadth, depth, life cycles, techniques and confidence. The table below shows how those quality dimensions are represented in CycloneDX 1.5. 

“Breadth” refers to the number of fields covered in the SBOM, including  author and supplier. “Depth” describes how difficult these things are to obtain. The remaining three dimensions are new features of CycloneDX v1.5, including support for the Software Development Life Cycle (SDLC) and Software Asset Management (SAM) or IT Asset Management ITAM. 

CycloneDX 1.5 also supports the representation of call stacks, meaning that you can describe the existence or nonexistence of a library and whether or not it’s being invoked. Given that something like 90% of libraries are never invoked in applications, you can stop wasting time looking at non-invoked libraries by using technologies such as Contrast. You can also have that call stack represented in a CycloneDX 1.5 SBOM. You can communicate that out to your customers so that they can actually know that a given library that’s on the ingredients label for your software — for example, the vulnerable Log4j library — is not, in fact, reachable, and hence is not a security risk. 

Endorsed by Contrast Security

Contrast Security’s Williams has been involved with OWASP’s CycloneDX project for over a year, helping to hash out the vital SBOM question of “How do you express this stuff in a machine-readable way?”

Williams enthusiastically supports CycloneDX and the release of v.1.5. 

“As we expand the standards, we make it possible to make a really informed decision,” he notes. “This release is a big step forward in the vision of SBOMs and will be useful in making informed decisions.” 

Read more:

• Gartner Report: Innovation Insight for SBOMs
• It’s SBOM time!
• Securing the software supply chain starts with an SBOM
• How to create SBOMs for free with CodeSec by Contrast
• SBOM – Contrast Documentation