The exponential growth of software supply chain attacks has triggered an industrywide push for increased transparency around the provenance and content of the programs and code that are brought into today’s systems. One artifact playing a critical role in that increased transparency is the software bill of materials (SBOM) or, more broadly, bills of material (BOMs), as there are several types.
One organization that continues to be a leader in evangelism for these formal, structured records that detail the components of a software product and their supply chain relationships is the Open Worldwide Application Security Project (OWASP), a nonprofit foundation that works to improve the security of software. OWASP has continued to provide guidance and resources to ensure the industry can successfully adopt and utilize them. In addition to being the home of one of the leading SBOM formats in CycloneDX and the source of the OWASP CycloneDX Authoritative Guide to SBOM, the team recently announced the release of its BOM Maturity Model.
Its goal is to “provide a formalized structure in which bills of materials can be evaluated for a wide range of capabilities.” These include a formal taxonomy of different data types, unique identifiers, descriptions, and other metadata as well as various levels of complexity to support different types of data. Here’s what the BOM Maturity Model consists of and how it may be used by the industry, focusing on SBOMs due to their importance in the cybersecurity ecosystem when it comes to software supply chain security.
What should be in an SBOM?
While there is much debate about what exactly an SBOM should contain and how much data and metadata is sufficient, one leading resource is often cited, the “The Minimum Elements for a Software Bill of Materials” as defined by the National Telecommunications and Information Administration (NTIA). Much of the momentum to consider SBOMs, especially in the federal space following the issuance of Cybersecurity Executive Order 14028 in 2021, was driven by the NTIA.
The minimum elements documents define the below data fields as baseline information that should be tracked and maintained for a piece of software via an SBOM:
| Data Field | Description |
| Supplier name | The name of an entity that creates, defines, and identifies components. |
| Component name | Designation assigned to a unit of software defined by the original supplier. |
| Version of the component | Identifier used by the supplier to specify a change in software from a previously identified version. |
| Other unique identifiers | Other identifiers that are used to identify a component or serve as a lookup key for relevant databases. |
| Dependency relationship | Characterizing the relationship that an upstream component X is included in software Y. |
| Author of SBOM data | The name of the entity that creates the SBOM data for this component. |
| Timestamp | Record of the date and time of the SBOM data assembly. |
Despite these being recommended as the minimum elements for an SBOM, studies by organizations such as Chainguard demonstrate that only 1% of SBOMs sampled were entirely conformant with the defined minimum elements. This was from a sample size of 3,000 SBOMs using an OSS tool known as ntia-conformance-checker. In addition to the lack of entire conformance, it found that one-third of SBOMs didn’t specify a name or version for all components and the existing tooling in the space produced disparate and inconsistent outputs, further complicating the matter. Needless to say, the industry has a lot of maturing to do when it comes to SBOM completeness and quality.
Enter the BOM Maturity Model
The goal of the BOM Maturity Model is to provide a formalized structure to evaluate the maturity of BOMs, including SBOMs, across various criteria. The project states that it can function as a mechanism to evaluate whether incoming BOMs align with organizational requirements, assess BOM generation and consumption tools and determine how current and future BOM formats fit into organizational requirements.
Here are some of the key aspects of the BOM Maturity Model and how it may be used.
Difficulty Levels
First up is the support for measuring the various difficulty levels of obtaining a BOM. These include Low, Moderate and High, with each posing increased difficulty in obtaining an accurate BOM.
- Low: Low-difficulty BOMs can be obtained through automated assessment utilizing existing tooling in the ecosystem.
- Moderate: Moderately difficult BOMs can be acquired through automated assessment but require domain-specific tooling or plugins to be successful.
- High: Unlike moderate and low, high-difficulty BOMs require manual effort, human observation, and data which may involve access control.
Support Levels
Support covers the various weighted levels assessing the level of native support within a specification for data fields and the level of parsing and enrichment that may be required to get the data to the desired completeness. Support levels range from 0-5, going from entirely unsupported to natively supported, as demonstrated in the table below.
| Support | Weight | Description |
| Native support in the core specification | 5 | Specification supports the data field natively |
| Native support through an official extension | 4 | Specification supports the data field through an official extension point in the specification |
| Support through a community extension | 3 | The community has developed an extension to support the data field |
| Partial support through non-standardized parameterized workaround | 2 | The specification does not support the data field but has support for storing the field name and value independently |
| Partial support through non-standardized unparameterized workaround | 1 | The specification does not support the data field and the field name and value must be parsed from a single text field |
| Unsupported | 0 | Not supported |
Taxonomy
The Taxonomy section of the BOM Maturity Model is the most comprehensive and extensible, covering a significant array of metadata that can be used to inform the analysis and information associated with a BOM and the components, software, and systems it represents. Below are some of the key areas of the taxonomy, along with a brief discussion on their associated details and fields.
- Core: Core is the most fundamental and basic of the bunch, providing an identifier for a timestamp to help identify when a BOM was generated and is low in difficulty to obtain.
- Structure: Structure provides support for fields such as Metadata and Inventory.
- Resource: Resource provides support for a comprehensive set of fields such as discussing the diverse set of resources a BOM may represent, such as Software, Hardware and Services. It also provides support for Identifiers such as Common Platform Enumeration (CPE), Package URL (PURL) and SWID, which are the three primary methods used to identify a specific piece of software in the current software identification ecosystem. These three Identifiers were also cited in a recent CISA whitepaper analyzing the current software identification ecosystem. Licensing and relationships are also critical when discussing software, components and BOMs so the taxonomy providers support including licensing details as well as communication of the relationships among components. These may include information such as dependencies, upstream ancestors/sources, and activities such as vulnerability reports and penetration tests.
- Pedigree: Pedigree is used to communicate the lineage of a piece of software, including ancestors, and descendants, and can provide users insight into the origins of a piece of software or component and provides support for fields such as Commits and Diffs.
- Provenance: Provenance supports use cases such as traceability of software from activities such as authorship, build, packaging, release, and distribution across the software supply chain and can be specifically useful for high assurance environments such as defense, where there are concerns of foreign origins and influence.
- Formulation: Formulation can communicate how a software or component was manufactured and deployed and can provide insight into activities such as resources and workflows that were involved in the creation and distribution of a software artifact.
Profiles
Profiles are among the most promising aspects of the BOM Maturity Model, allowing organizations to define globally universal profiles across the organization as well as specific profiles for stakeholders interested in specific data and metrics. The profiles can empower use cases such as analyzing BOMs to determine what use cases they can be used for and defining organizational profiles around what data is desired or required to perform the necessary analysis on a BOM.
A journey toward bill-of-materials maturity
Much as with other industry efforts such as zero trust, the journey towards establishing widespread mature BOMs with sufficient detail and depth will be just that — a journey. That said, resources such as OWASP’s SBOM Guide and the BOM Maturity Model can serve as great tools that organizations, software suppliers and consumers can use to mature their implementation of SBOMs and ensure they are providing sufficient insight and details to be used in activities such as software asset inventory, vulnerability management and software supply chain security.
However, as demonstrated in the study cited earlier, as an industry we’re in the infancy of mature BOM adoption and implementation. While the journey may seem daunting, the alternative is continuing the historical status quo of blind software consumption with limited transparency and insight into the software we are consuming, its lineage, who’s been involved in it and what has occurred to it along the way. We wouldn’t settle for this level of opaque risky consumption in other industries such as food and pharmaceuticals and with software increasingly driving nearly every aspect of society, we shouldn’t settle for a lack of transparency here either.