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
|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.
|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.
|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.
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.
Start Meeting SBOM Government Requirements Today
Learn More - SBOM Key Concepts
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.
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.
- Software Supply Chain Management Catalogs Explored Whitepaper
- Aggregated SBOM Reports
- Open-Source Inventory and Risk Management
- Supply Chain Versioning with Historical Trends
- Component Impact and Blast Radius
- Logical Application Views in a Decoupled Architecture
- SBOMs and Cybersecurity
- Federated Software Composition Analysis Data