After many years of hard work, the NTIA (National Telecommunications and Information Administration) published an important document in July 2021: The Minimum Elements for a Software Bill of Materials (SBOM). True to its name, the document details a list of the elements a minimal SBOM should include.
Its purpose?
- Enabling the basic use cases for SBOM usage, like vulnerability management, software inventory and licenses.
- Beginning the conversation on future required SBOM elements and features for broader use cases and for scaling operational use.
In this context, it’s important to note that the document’s creation was accelerated by President Biden’s CyberSecurity EO, which tasked the NTIA to publish these guidelines. We believe this is an important step in minimizing the attack surface in both the public and private sectors, as well as deepening the conversation and the standardization processes across the community.
Working with “The Minimum Required Elements of an SBOM”
More and more companies now require SBOMs from their vendors, and rightfully so as SBOMs improves software supply chain security. By creating SBOM standardization, companies and their supply chain vendors can set clear expectations for one another, as well as to shorten iteration cycles, as they engage on the subject of the SBOM.
This document does just that by providing clear criteria of what is expected in an SBOM. These guidelines help build visibility, trust and security awareness amongst the players in the supply chain.
In fact, as more companies accept this document, we can see it becoming the de facto benchmark for SBOMs.
What Does this Document Provide (and What It Doesn’t)?
This document provides companies that produce, purchase and operate software with the key components for an SBOM. This will help them track new and known vulnerabilities and understand the software ecosystem. It will also help them gain transparency and awareness across multiple use cases, like inventory, vulnerability, and license management.
It is important to remember, however, that an SBOM will not solve all security issues. In addition, the list inside is not comprehensive and the existing components on the list are not necessarily complete. Rather this is a list for getting started now, and improving as we progress.
If you’d like to learn more about a solution that provides enhanced visibility into your product’s component software with a detailed SBOM, click here.
Now, let’s dive into the requirements themselves. These are divided into three categories: data fields, automation support, and practices and processes.
Data Fields
Since the purpose of the SBOM is to provide information for identifying the software components, it makes sense that the first minimal required element covers which data should be included about each component. This data can also be used for tracking the components across the software supply chain and mapping them to databases.
The NTIA defines seven baseline fields:
- Supplier Name – the component manufacturer
- Component Name – the name of the unit determined by the supplier
- Version of the Component – the release number or category determined by the supplier
- Other Unique Identifiers – additional unique data. The NTIA recommends using these to support mapping automation efforts across data users and ecosystems. For example, Common Platform Enumeration (CPE), Software Identification (SWID) tags and Package Uniform Resource Locators (PURL)
- Dependency Relationship – the upstream relationship of the component with other software
- Author of SBOM Data – the entity that created the SBOM data (not the software creator)
- Timestamp – when the SBOM data was assembled
Automation Support
The NTIA also encourages the use of SBOM data across departments and organizations, to enable transparency, enhanced security, the meeting of compliance standards, and more. To do this, SBOMs must be machine-readable, so these processes can be automated.
There are currently three interoperable data formats in use across the SBOM community. The NTIA supports them and requires that SBOMs comply with at least one of them:
Other proprietary data formats should not be used.
Practices and Processes
Finally, the NTIA acknowledges that established culture and processes are essential to ensure organization integration. To help, it defines the following guidelines that organizations should address:
- Frequency – new SBOMs must be created with every new version. They should be recreated when updating data about a component. At Cybellum, we call this a “living SBOM”, i.e an SBOM that represents the product with every new update or release.
A “living SBOM” – maintaing and comparing SBOMs, vulnerabilities, licenses and more with Cybellum
- Depth – SBOMs should contain all top-level components with their transitive dependencies. These top-level dependencies should have enough detail so SBOM consumers can find other transitive dependencies. Over time, organizations will be able to provide more in-depth information.
- Known Unknowns – defining whether the dependency graph is complete, or if the dependency graph is unknown and incomplete.
- Distribution and Delivery – making SBOM data available to anyone who needs them, by making SBOM availability known and ensuring the data can be retrieved and accessed.
- Access Control – access to SBOMs can be controlled, but the terms should be specified, including information on how to integrate the SBOM data into the user’s security tools.
- Accommodation of Mistakes – tolerance of errors and mistakes as SBOM practices are implemented, to enable improvement and evolvement.
Areas That Shouldn’t Be Ignored
The minimum elements are only what they are – minimal requirements. But to increase transparency and visibility, the NTIA recommends supporting broader use cases with more elements, and encourages organizations to ask suppliers for them!
These include:
- Additional data fields – hash of the component, lifecycle phase, other component relationships and license information
- Cloud-based software and SaaS – creating and maintaining an SBOM for cloud providers, not just for on-premise software
- Integrity and authenticity – mechanisms to verify the source of SBOM data, like digital signatures
- Vulnerabilities – linking to external vulnerability data sources, instead of just relying on vulnerability data in the SBOM
- Vulnerability and exploitability in dependencies – determining the impact of a vulnerability on a software component and communicating this information downstream through VEX
- Legacy software and binary analysis – implementing binary analysis tools when SBOM data is not available, e.g. with legacy code
- Implementation flexibility/uniformity – combining broader rules and procedures with leeway in specific areas
What the Future Holds
These guidelines should be viewed as a starting point for a wider discussion about supply chain security, both through the SBOM and through other security measures.
Companies and suppliers can see the minimal requirements document as an opportunity to engage with players in the supply chain, to provide more advanced capabilities or to bring their practices up to speed with this standardization.
Going Beyond Minimal Requirements for SBOMs
Cybellum provides lifecycle security management for your supply chain. We provide SBOM management and vulnerability monitoring from design to post-production.
Our proprietary Cyber Digital Twins™ technology creates a blueprint of your software, including detailed SBOMs (beyond the minimal requirements), versions, licenses and architecture, so you can pinpoint vulnerabilities and remediate them.
Our experts can show you how. Talk to us or book a demo.
