Not all BOM's are Created Equal
An analysis of the new OWASP BOM Maturity Model
We continue to see an industry wide push for increased transparency, especially in the wake of exponential growth of software supply chain attacks. One critical artifact playing a role in the increased transparency are Software Bill of Materials (SBOM)’s and BOM’s more broadly, as there are several types. One organization continues to be a leader in the evangelism of BOM’s and has continued to provide guidance and resources to ensure the industry can successfully adopt and utilize BOM’s, and that is OWASP.
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”, at OWASP Global AppSec D.C the team announced the release of their “BOM Maturity Model”.
Its goal is stated as 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.
In this article, we will take a deeper look at the BOM Maturity model to understand what it consists of and how it may be used by industry. We will specifically focus on SBOM’s in particular, due to their focus from most entities in the ecosystem when it comes to software supply chain security.
What should an SBOM contain?
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. That is the “The Minimum Elements for a Software Bill of Materials” as defined by the National Telecommunications and Information Administration (NTIA), where much of the SBOM momentum began, especially in the Federal space, as a result of the Cybersecurity Executive Order (EO) 14028. 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:
Source: NTIA’s Minimum Elements for an SBOM
However, despite these being recommended as the minimum elements for an SBOM, studies by organizations such as Chainguard demonstrate that only one percent of SBOM’s sampled were entirely conformant with the defined minimum elements. This was from a sample size of 3,000 SBOM’s using an OSS tool known as the “ntia-conformance-checker”. In addition to the lack of entire conformance, it found a third of SBOM’s didn’t specify a name or version for all components and the existing tooling in the space product 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
As we mentioned above, the goal of the BOM Maturity Model is to provide a formalized structure to evaluate the maturity of BOM’s, including SBOM’s, across various criteria. The project states that it can function as a mechanism to evaluate if incoming BOM’s align with organizational requirements, assess BOM generation and consumption tools and determine how current and future BOM formats fit into organizational requirements.
So let’s take a look at 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 BOM’s can be obtained through automated assessment utilizing existing tooling in the ecosystem.
Moderate - Moderately difficult BOM’s can be acquired through automated assessment but require domain specific tooling or plugins to be successful.
High - Unlike moderate and low, High difficulty BOM’s 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 desired completeness. Support Levels range from 0-5, going from entirely unsupported to natively supported, as demonstrated in the table below.
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 BOM’s so the taxonomy providers support for including licensing details as well as communication 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, 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 either 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 BOM’s 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 Towards BOM Maturity
Much like other industry efforts such as Zero Trust, the journey towards widespread mature BOM’s 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 SBOM’s 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 our 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.