• United States



Chris Hughes
Contributing Writer

Understanding OWASP’s Bill of Material Maturity Model: Not all SBOMs are created equal

Nov 15, 20239 mins
DevSecOpsSecurity PracticesSoftware Deployment

The push to create more detailed, reliable, and mature BOMs with sufficient detail and depth to counter supply chain attacks continues to advance with the latest OWASP model.

Japan Asia woman female software developer programmer code
Credit: Shutterstock

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 FieldDescription
Supplier nameThe name of an entity that creates, defines, and identifies components.
Component nameDesignation assigned to a unit of software defined by the original supplier.
Version of the componentIdentifier 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 relationshipCharacterizing the relationship that an upstream component X is included in software Y.
Author of SBOM dataThe name of the entity that creates the SBOM data for this component.
TimestampRecord of the date and time of the SBOM data assembly.
Source: NTIA's Minimum Elements for an SBOM

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 specification5Specification supports the data field natively
Native support through an official extension4Specification supports the data field through an official extension point in the specification
Support through a community extension3The community has developed an extension to support the data field
Partial support through non-standardized parameterized workaround2The specification does not support the data field but has support for storing the field name and value independently
Partial support through non-standardized unparameterized workaround1The specification does not support the data field and the field name and value must be parsed from a single text field
Unsupported0Not supported


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 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.

Chris Hughes
Contributing Writer

Chris Hughes currently serves as the co-founder and CISO of Aquia. Chris has nearly 20 years of IT/cybersecurity experience. This ranges from active duty time with the U.S. Air Force, a civil servant with the U.S. Navy and General Services Administration (GSA)/FedRAMP as well as time as a consultant in the private sector. In addition, he also is an adjunct professor for M.S. cybersecurity programs at Capitol Technology University and University of Maryland Global Campus. Chris also participates in industry working groups such as the Cloud Security Alliances Incident Response Working Group and serves as the membership chair for Cloud Security Alliance D.C. Chris also co-hosts the Resilient Cyber Podcast. He holds various industry certifications such as the CISSP/CCSP from ISC2 as holding both the AWS and Azure security certifications. He regularly consults with IT and cybersecurity leaders from various industries to assist their organizations with their cloud migration journeys while keeping security a core component of that transformation.

More from this author