In recent years, cybersecurity has become increasingly important, not least when it comes to protecting the entire software supply chain. In July 2021, the US National Telecommunications and Information Administration (NTIA) presented a number of minimum requirements for a Software Bill of Materials (SBOM).
These requirements, stemming from an executive order (EO 14028), are intended to enable companies selling to government agencies to show exactly which software components are included in their products.
As part of this work, a detailed set of minimum requirements for SBOM has also been developed, called SBOM Minimum Elements.
By clearly specifying which data fields, formats and processes are needed, better conditions are created to quickly identify and manage vulnerabilities.
Purpose of SBOM Minimum Elements
The idea behind the minimum requirements for SBOM is to give everyone involved – whether government agency or company – a clear and understandable overview of the software's composition. With a complete list of components, you can:
- Support automation: By using standardized data fields and processes, SBOMs can be generated and distributed automatically – saving time and simplifying integration with other security tools.
- Increase transparency: A complete overview makes it easier to see which parts are included and what risks may be associated with licenses and security.
- Facilitate vulnerability management: When you know exactly which components are used, it becomes easier to quickly track and address any security flaws.
This method not only contributes to increased transparency but also makes it easier for all parties to act quickly in security incidents.
Fields included in minimum requirements
For an SBOM to be truly useful, it must contain certain central data fields. According to the guidelines, the following information should be included:
- Supplier Name: The name of the party supplying the software component.
- Component Name: The name of the software component itself.
- Version: Specification of which version or revision applies.
- Unique Identifiers: Identifiers, such as Package URLs (PURL) or Common Platform Enumeration (CPE), that help track the component.
- Dependency Relationship: Information about how components depend on each other, both directly and indirectly.
- SBOM Data Author: The party that compiled the information.
- Timestamp: Date and time when the SBOM was created.
Automation and formats
For SBOM information to be practical in everyday use, it is important that it is both machine- and human-readable. Therefore, standardized formats are used in generation. The most common formats are:
- CycloneDX: A flexible format that can be expressed in several different file types, such as XML and JSON.
- SPDX: A well-established format that captures important information about origin, licenses and security.
Using these formats makes it easier to integrate SBOMs with various security and analysis tools, which in turn facilitates management of the entire software supply chain.
Methods and processes for generating SBOM
It's not enough to just have a complete list – it's also important to think about how the SBOM is created and shared. Here are some practical points to consider:
- Update frequency: Every time a new version of the software is released, or if important changes occur, the SBOM should be updated and stored.
- Completeness: It is crucial to document both the main components and all dependencies that can affect the system's security. If the entire chain cannot be specified, it should be clearly stated which parts are missing.
- Distribution and access: The SBOM should be made available quickly and securely, with clear guidelines for who has the right to access the information.
SBOM Minimum Elements not only contributes to increased insight and transparency, but also to safer and more efficient management of today's digital environment with the help of automation.