SBOM Key Concepts

SBOM Requirements

Understand What You Need for Meeting SBOM Requirements

Learn the Federal Requirements of SBOMs

In an effort to improve cyber security for the private and public sectors, the US government has issued cybersecurity requirements, which include the use of an SBOM. Over the past few years, increased dependence on software in critical systems and the number of recent security incidents involving open-source software have led to a need for SBOM regulations. In this article, we cover the requirements and how to meet them.

What is an SBOM?

A software bill of materials (SBOMs), have emerged in software security and software supply chain risk management as a critical asset for ensuring security and transparency in software. With the emergence of open source usage, and decoupled architectures with complex dependencies, SBOMs are essential for understanding what transitive software packages are used across the organization’s software supply chain. To encourage the use of SBOMs for understanding the software supply chain, the US government has established recent regulations regarding SBOMs to enhance software cybersecurity.

SBOM Requirements for Federal Agencies

Regulatory agencies such as the U.S. National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA) advocate for SBOM requirements as a necessary practice for software supply chain security.

The use of SBOMs for software supply chain security was mostly attributed to the SolarWinds software supply chain attack, which occurred in December 2020. Other recent hacks that helped propel these changes include the hacks of Microsoft Exchange and Colonial Pipeline, which occurred in early 2021. Since these attacks, government agencies have begun to require that any software being delivered to the US Government must be accompanied by an SBOM.

Executive Order 14028: “The Response to Improving Cybersecurity” calls for a list of all components used to create a software product delivered to the US Government with a software bill of materials (SBOM) report as proof. The goal is to remove barriers to sharing threat information, allowing the US government to be better prepared to respond to a potential threat or attack. At the core of the SBOM requirements are critical details about the open-source packages that are needed to run the software. This information is what the US Government needs to understand their risk if an issue with an open-source package is identified. The White House mandate selected the NIST cybersecurity framework as the governing system for software development within the federal government. It also applies to companies selling software to the federal government.

For highly regulated industries that service the US government, SBOMs are now a requirement for every release. In a decoupled architecture SBOMs are dynamic, changing each time a single component is updated. For this reason, organizations will require Federated SBOMs, showing all component-level SBOM data aggregated to the logical application.  In coordination with the NTIA and CISA, EO 14028 requires publishing the minimum elements for a Software Bill of Materials (SBOM). The Executive Order states: 

“An SBOM advances transparency in the software supply chain, similar to a ‘list of ingredients.’ NTIA is directed to publish a list of ‘minimum elements for an SBOM.’”

In addition to the public sector, the EO encourages private organizations to use SBOMs and requires the development of security guidelines and standards for SBOMs.  One essential guideline from the NIST is a new requirement to use a software bill of materials (SBOM) to document an inventory of all third-party components used inside any given application. After all, if you don’t know what software was used to build your software, you can’t address critical vulnerabilities that may find their way into major projects.

Minimum SBOM Requirements from NTIA

Here are the minimum elements SBOMs require according to the NTIA.

Minimum Elements SBOMs
According to NTIA
Data Fields Document baseline information about each component that should be tracked: Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp.
Automation Support Support automation, including via automatic generation and
machine-readability to allow for scaling across the software
ecosystem. Data formats used to generate and consume SBOMs include SPDX, CycloneDX, and SWID tags.
Practices and
Processes
Define the operations of SBOM requests, generation, and use, which includes: Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes.

The Future of SBOMs

SBOMs will continue to be redefined, and regulations and SBOM requirements will continue to evolve and adapt. In particular, SBOM requirements must evolve around cloud-native, decoupled architectures where hundreds of SBOMs are generated for each component’s container image. SBOM consumption and aggregation will be critical for meeting the demands of the US Government’s stated goals. Overall, SBOM consumption will be the focus of SBOM technology. At present, most SBOMs are generated in a log file format. The information is difficult to read and somewhat unusable, leading to long periods of time towards containment when an attack occurs. While SBOM standards have been well defined, the data they generate needs to be consolidated, tracked with historical trends, and used in AI to generate threat models.

Conclusion

SBOMs are becoming increasingly important in the effort to harden software cybersecurity. SBOM requirements are now clearly stated as defined by the US Government’s Executive Order 14028. While SBOMs can be generated in traditional monolithic architectures, creating an application SBOM in a decoupled architecture is difficult. DeployHub addresses this issue by aggregating component-level SBOM data up to the logical application. By doing so, DeployHub’s federated SBOM helps organizations meet the US Government’s SBOM requirements.

DeployHub’s Federated SBOM

DeployHub’s Open-Source Software Supply Chain Management catalog integrates into your Continuous Delivery pipeline to gather SBOM data for every component version. It tracks the logical applications that consume the component, delivering a Federated SBOM to support the SBOM requirements. This aggregation ability is essential in delivering SBOMs in a decoupled architecture where the SBOM data is fragmented across hundreds of components.

Learn More

Start Meeting SBOM Government Requirements Today

Signup for DeployHub Team and Meet Government SBOM Requirements in a Decoupled Architecture for Free

Signup for DeployHub Team, the free SaaS software supply chain security platform. DeployHub Team is based on the Ortelius Open-Source project incubating at the Continuous Delivery Foundation.

Signup Today

Learn More - SBOM Key Concepts

SBOM Automation

SBOM automation automatically generates a list of all software components, libraries, and dependencies that make up a software application as part of your DevOps Pipeline and then consuming the data.

SBOMs and Cybersecurity

SBOMs play a key role in solving the cybersecurity challenge. Learn why generating SBOMs is essential to harden the software supply chain.

SBOM Consumption

SBOM consumption is the process of analyzing and utilizing the data contained within an SBOM document.

Understanding SBOMs

Software Bill of Material has finally been recognized as an essential tool in the security toolbox. In this article, we review what to know about Software Bill of Materials.

SBOM Management

SBOM management collects Software Bill of Material reports as they are generated across the DevOps pipeline with data aggregation.

Suggested Whitepaper

Aggregating SBOM data to the ‘logical’ Application level is required if you need to produce an Application SBOM in a decoupled architecture. Learn how DeployHub provides aggregated SBOM reports from hundreds of component SBOMs.

Get the Whitepaper

SBOMs in a decoupled architecture

Further Reading