3rd Party Components Supply Chain Management SBOM

NTIA Publishes Minimum Components of an SBOM

By Derek Kruszewski on July, 15 2021

Back

In today’s blog post I’d like to recognize all the hard work done by NTIA (National Telecommunications and Information Administration) and congratulate them on publishing the minimum elements for a Software Bill of Materials… more commonly referred to as an SBOM. In particular, I’d like to give a shout-out to Allan Friedman who has been championing the SBOM cause for some time now. It’s good to see his committed effort captured in this comprehensive report. We now have a clear definition of this first incarnation of an SBOM, developed in collaboration with industry, government, and academia.

It was fast work. Although the NTIA has been conducting a transparent, multistakeholder process since 2018, the starter's pistol went BANG on May 12 when President Biden signed Executive Order 14028 — Improving the Nation’s Cybersecurity (see our other blog posts on the EO). The EO tasked NTIA with publishing the minimum elements of an SBOM. If you are unfamiliar with SBOMs, here is the NTIA definition:

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.

To be clear, the 28-page document established the minimum elements of an SBOM. The NTIA is quite emphatic about that. More than 8 pages are dedicated to Sections 5 “Beyond Minimum Elements: Enabling Broader SBOM Use Cases” and 6 “Future SBOM Work.” So we can look forward to future improvements, while still making immediate progress. Or, to borrow their own phrase, “starting today is better than waiting for perfection.”

I’d like to add that aDolus participated in this transparent process and we’ve been developing our FACT platform with the anticipated requirements very much in mind. FACT can already produce fully-compliant SBOMs with a single click of a button. We generate SBOMs from binaries (as opposed to those generated from source code or during build). In Operational Technology, where ICS equipment life spans range from 25-30 years, binaries are usually the only option as the source code is long gone. And as an advantage, our SBOMs show what was actually installed in a device versus what the development build system believed would be installed by the user.

The minimum elements NTIA describes are organized into these three categories.

Data Fields

Data fields are the baseline data about each component that must be captured and maintained in order to track the component across the software supply chain. With this information in hand, one can map a component to other available sources of data, such as vulnerability databases or license databases. The (minimum) required fields are:

Supplier Name
Component Name
Version of the Component
Other Unique Identifiers

Dependency Relationship
Author of SBOM Data
Timestamp

Capturing this information is surprisingly complicated stuff BTW. For example, thanks to mergers and acquisitions, rebranding, and plain old typos, getting a product name correct can be extremely difficult. (aDolus has employed extensive machine learning to solve this problem.)

Automation Support

This element refers to making SBOMs machine readable, so they are actually usable at scale and across organizations. (Although technically an SBOM is supposed to be human-readable, I don’t recommend it!) NTIA has defined the following approved formats:

SPDX (Software Package Data eXchange) — available now in FACT
CycloneDX — available by request
SWID (Software Identification) — available now in FACT

Practices and Processes

These elements address the actual mechanics of how SBOMs are used. This section discusses what must be explicitly addressed in any policy, contract, or arrangement with respect to SBOMs. It also discusses how the SBOMs are distributed and shared. One interesting element NTIA included was the “Accommodation of Mistakes.” This is an acknowledgement that in order to move fast, industry should, for the moment, waive the expectation of perfection. The overarching objective is to secure the software supply chain and move quickly, focusing on constant improvement.

So by now, you are probably curious what an SBOM actually looks like. Here’s an actual SBOM for real world ICS software in SPDX format. It was generated by FACT, and as you can see the data fields required by NTIA are all in there and it’s fully compliant^*. (FACT also provides enriched SBOMs that allow you to drill down and drill around all the components, and we provide risk scores and other valuable information so you can see which components are problematic.)

An SPDX SBOM from FACT

So that’s a quick introduction to NTIA’s report. We’ll be working on some more technical deep dives around their SBOM definition in the weeks to come.

* Our thanks to OSIsoft for sharing this SBOM sample. They are way ahead of the curve when it comes to SBOMs.

Derek Kruszewski

Derek Kruszewski is a data scientist and mechanical engineer with a passion for automating control systems using AI, particularly at oil and gas facilities. Derek leads the vulnerability management innovations at aDolus and (with his extensive yoga background) can fix your back if it hurts.