The National Telecommunications and Information Administration (NTIA), under the guidance of the US Department of Commerce, recently released a white paper outlining the minimum requirements for a Software Bill of Materials (SBOM). The Minimum Elements for a Software Bill of Materials (SBOM) describes the requirements that must be met for any company doing business with the US federal government.
This is the second blog in a two-part series. The first blog in this series – Making Sense of SBOMs: The Basics – defines what an SBOM is and details why you should adopt this technology.
Software Bill of Materials (SBOM) Definition and Background
On May 12, 2021, the White House issued Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity. The EO identified cyberattacks as a threat to national and economic security. One of the key outcomes of Executive Order 14028 was the mandate that software companies wishing to sell to the US federal government must deliver an SBOM for each product sold. The NTIA was then tasked with identifying the minimal requirements for SBOMs.
As defined by the NTIA, “an SBOM is a formal record containing the details and supply chain relationships of various components used in building software.” This includes all open source components and third-party software.
SBOM Minimum Requirements
When defining the minimum requirements of SBOMs, the NTIA understood that SBOMs are still rapidly evolving as a technology. Because of this, the NTIA adopted a highly flexible set of guidelines that allow SBOMs to adapt to the developing needs of the market. The three main requirements of SBOMs as detailed by the NTIA are:
- Data Fields
- Automation Support
- Practices and Processes
In this blog, we look at each of these requirements in detail.
Data Fields
SBOMs need to contain baseline information about each component. Information should be presented in a uniform structure to easily identify the components that make up an application. The purpose of these data fields is to be able to track components across the software supply chain and also to map them to other useful data sources, such as license or vulnerability databases. While uniformity is a key requirement, these data fields must be flexible enough to adapt to future changes.
The following are the minimum requirements for data fields in an SBOM:
Automation Support
To achieve the greatest transparency and usability, SBOMs must support automation. This should be achieved via the automatic generation of SBOMs and machine-readability to allow for scaling across the software ecosystem.
Furthermore, SBOMs should be generated in one of the following three formats:
- Software Package Data eXchange (SPDX)
- CycloneDX
- Software Identification (SWID) Tags
Software Package Data eXchange (SPDX)
The SPDX specification is an open standard created by the Linux Foundation. It is now an ISO standard (ISO/IEC 5962:2021). SPDX reduces redundant work by providing common formats to share important data, thereby streamlining and improving compliance, security, and dependability. A wide range of open source and commercial vendors support SBOMs using this format.
CycloneDX
CycloneDX is a lightweight SBOM standard that originated in the Open Web Application Security Project (OWASP) community. Designed from the start to be a BOM format and meet a variety of use cases, CycloneDX provides support for integrity verification of the components associated with the BOMs it is used for through hash values and cryptography.
Software Identification (SWID) Tags
The SWID project is supported by the National Institute of Standards and Technology (NIST), and the specification is defined by the ISO/IEC 19770-2:2015 standard. NIST is working to incorporate SWID tag data into the vulnerability dataset provided by the National Vulnerability Database (NVD). SWID is most often associated with component licensing.
Figure 1. SPDX SBOM for Lemon Ginger Scones
Figure 1 shows what an SBOM might look like for the Lemon Ginger Scones we talked about in the first blog in this series, Making Sense of SBOMs: The Basics. In Figure 2, the image shows the SBOM relationship of one ingredient, sugar, in our scones.
Figure 2. SPDX SBOM Package Detail for Sugar
Practices and Processes
The NTIA states that organizations need best practices and processes in place that identify how an SBOM is requested, created, and used. In many cases, however, the NTIA does not define what that practice or process should be, but rather states that each organization needs to define it themselves. The following are the practices and processes that need to be followed:
- Frequency. A new SBOM must be created whenever a software component is updated in a new build or release. Likewise, if you discover an error or omission in your SBOM, it must be corrected and updated.
- Depth. SBOMs should identify all primary and transitive dependencies. According to NTIA, “At a minimum, all top-level dependencies must be listed with enough detail to seek out the transitive dependencies recursively.”
- Known Unknowns. In some instances, the full dependency graph of a component is unknown. SBOMs should distinguish between whether a component has no further dependencies versus when information about dependencies is unknown or incomplete.
- Distribution and Delivery. SBOMs should be made available in a timely fashion and must have appropriate access permissions and roles in place. Organizations must make the existence and availability of an SBOM known as well as how it is accessed by those who have permission to do so.
- Access Control. Organizations must decide whether to publish their SBOMs publicly or privately. If they decide to keep SBOMs private, the terms of access must be specified, usually in either the sales contract or license agreement.
- Accommodation of Mistakes. Internal management of supply chain data is still evolving, and it is understood that mistakes will happen, particularly in these early days of SBOMs mandates. Suppliers of SBOMs should offer updated data as they identify mistakes or omissions. Likewise, users of SBOMs should be tolerant of the occasional “incidental error.”
SBOM Limitations
Despite these guidelines, the NTIA is clear that the requirements for SBOMs are only a starting point. SBOMs still have limitations. More work needs to be done to expand transparency in the software supply chain and to support visibility for securing software. In fact, the NTIA acknowledges that “Several recent high profile attacks in the supply chain did not target software components, but the tools and systems used to manage the software development and build process.” In these cases, SBOMs as currently defined would not provide effective coverage against a software supply chain attack.
Using an SBOM is not a panacea. NTIA acknowledges that there are gaps in coverage and that SBOMs alone do not address the multitude of software supply chain and software assurance concerns faced by the ecosystem today. SBOMs should not be thought of as the ultimate cure, but rather one tool among many.
Learn More About SBOMs
Though SBOMs have a wide range of use cases, they will only be truly helpful once they gain universal adoption. Currently, SBOM standards and requirements are still developing. Achieving full participation will take some time due to the large number of tools and standards that are now just emerging.
To learn more about what SBOMs are as well as their primary use cases, please read the first blog in this two-part series, Making Sense of SBOMs: The Basics.
About Cycode
Want to learn more about how Cycode provides visibility, security, and integrity across all phases of the SDLC? Schedule a demo today!
