A Nested Inventory for Software Security, Supply Chain Risk Management

 A Nested Inventory for Software Security, Supply Chain Risk Management

By Esther Shein, July 20, 2023

An SBOM is meant to provide visibility into risks and vulnerabilities. 

The Software Bill of Materials (SBOM) is comprised of all the components and libraries used to create a software application. It includes a description of all licenses, versions, authors, and patch status.

With high-profile data breaches like Kaseya and Apache Log4j still causing repercussions, securing the software supply chain is under scrutiny like never before. This prompted the Biden Administration's 2021 Executive Order on Improving the Nation's Cybersecurity, which requires developers to provide a Software Bill of Materials (SBOM).

Think of an SBOM like the ingredients in a recipe—it is comprised of all the components and libraries used to create a software application. It includes a description of all licenses, versions, authors, and patch status.

Many of these components are open source, and an SBOM is meant to provide visibility into risks and vulnerabilities. After all, if you don't know what code you're protecting, how can you maintain it?

The role of SBOMs

When organizations have this visibility, they are better able to identify known or emerging vulnerabilities and risks, enable security by design, and make informed choices about software supply chain logistics and acquisition issues. "And that is increasingly important because sophisticated threat actors now see supply chain attacks as a go-to tool for malicious cyber activity,'' according to Booz Allen Hamilton.  

By 2025, 60% of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs in their software engineering practice, up from less than 20% in 2022, according to market research firm Gartner.

"Multiple factors are driving the need for SBOMs,'' says Manjunath Bhat, a research vice president at Gartner. Those factors include the increased use of third-party dependencies and open-source software, increased incidence of software supply chain attacks, and regulatory compliance mandates to secure the use of OSS, Bhat says.

 "The fine-grained visibility and transparency into the complete software supply chain is what makes SBOMs so valuable," he says.

SBOM elements

The National Telecommunications and Information Agency (NTIA) and the U.S. Department of Commerce were tasked with publishing the minimum elements for an SBOM, along with a description of use-cases for greater transparency in the supply chain.

They determined there should be data fields for a supplier, component name, and version, as well as the dependency relationship, among other areas, the NTIA and Department of Commerce said.

They also recommended there be automatic data generation and machine readability functionality to allow for scaling an SBOM across the software ecosystem. There are also three formats for generating SBOMs that are generally accepted: SPDX, CycloneDX, and SWID tags.

SBOMs are designed to be part of automation workflows, Bhat observes. "Therefore, standardization of data formats and interoperability between them is going to be paramount."  

The data fields within an SBOM "include elements that help uniquely and unambiguously identify software components and their relationships to one another,'' he says. "Therefore, the basic elements include component name, supplier name, component version, unique identifiers (most likely a digital signature or a cryptographic hash), and dependency relationships."

SBOM platforms that are automated and dynamic are ideal because they can be continuously updated to ensure software developers have an accurate view of the components and dependencies they use in their applications.  ... '