A Nested Inventory for Software Security, Supply Chain Risk Management

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.

How SBOMs can be used

There are some good use-cases for how SBOMs can be utilized. They include:

• assisting with software procurement and adoption decisions to reduce compliance issues and prevent duplicate purchases;
• enhancing threat intelligence and vulnerability management by tracking compromised components and remediation planning;
• accelerating incident response and guiding patch implementations, and
• providing the ability to map dependencies in an organization's ecosystem across the external software ecosystem.

Bhat says there aren't any real downsides to SBOMs, but notes that "They are useful only to the extent that they are comprehensive, complete, and accurate. Partially complete SBOMs or obsolete SBOMs are as good as having no SBOMs at all.'' Further, "It's important for us as an industry to converge on a couple [of] easy to produce and easy to consume SBOM formats."

SBOMs are designed to track and share the details of software components and their supply chain relationships across organizations, and this enables greater transparency, auditability, and traceability, Bhat says. This is useful for expediting the resolution of security and compliance issues.

"SBOMs also help organizations determine if they are susceptible to known security vulnerabilities in software components,'' he says. "SBOMs generate and verify information about code provenance and relationships between components, which helps software engineering teams to detect malicious attacks during development."

SBOMs in use

Microsoft is both generating and using SBOMs to prioritize software security and prepare software for customers, says Adrian Diglio, principal program manager of secure software supply chain (S3C) at Microsoft.

The software giant has created an SBOM tool that developers run internally at build-time, which outputs an SBOM in SPDX format that can be shared with customers, Diglio says. Last year, Microsoft open-sourced the SBOM tool to allow the community access to use and further build on it.

Now, "Microsoft is performing necessary organizational preparations across the company to begin consuming and managing SBOMs from third parties,'' he says. "As part of this effort, we have an early version available to those in the Windows Insider program of the Windows Driver Kit (WDK) and Windows Assessment and Deployment Kit (ADK) that contains our SBOM tool."

Some of its SBOMs products are also publicly available, Diglio adds.

"Through our work with the SBOM tool and the Secure Supply Chain Consumption Framework (S2C2F), Microsoft is continuously reiterating the importance of open source software … to address its security,'' he says.  

 

Esther Shein is a freelance technology and business writer based in the Boston area.