Understanding OWASP’s Bill of Material Maturity Model: Not all SBOMs are created equal
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.
