The CycloneDX team released their eagerly anticipated new version 1.5 on June 26. It both builds on existing capabilities of the current version 1.4 and breaks new ground. However, there’s nothing in it that represents a huge break from previous versions, so current users of CDX 1.4 will feel completely at home with 1.5, allowing them to learn as they go rather than having to make a complete change before they can be productive at all.

Arguably, the most important “enhancement” in CycloneDX 1.5 isn’t v1.5 at all, but the 63-page “CycloneDX Authoritative Guide to SBOM” document that was released along with it. This is the single best document on SBOM that the reviewer has ever read because of its clarity, excellent illustrations, and its focus on why each feature is important and how it can be used (while allowing the reader to pick up technical details in the CycloneDX v1.5 JSON document, also released on Monday). Even though the document is focused on CycloneDX, SPDX users will be able to learn a lot from it as well.

Here are, in the reviewer’s opinion, the most important improvements in CDX v1.5 over v1.4, along with page numbers from the Guide for more information on each improvement:

RELATED: Understanding and Using VEX (Vulnerability Exploitability eXchange)

Improvements in CycloneDX 1.5

  • In “compositions/aggregate,” it is now possible to describe the inventory of components and services and state whether different types of relationships among the components and services (first- and third-party, proprietary, and open source) are complete, incomplete, or unknown. (page 27)
  • Perhaps the most important “feature” of CycloneDX is that it’s not just an SBOM format, but a BOM format in general, and the number of supported BOM types increases all the time. For good, short descriptions of each of the current CDX BOM types, including the new Machine Learning BOM (MLBOM), see pages 8-9.
  • There are four new component types, including Data, Device Driver, ML Model, and Platform. (page 18)
  • CycloneDX has for a long time been able to manage open source component licenses, but now it can be used to manage commercial component licenses as well. (page 23)
  • There is general agreement that the list of minimum fields on page 9 of the NTIA’s “Minimum Elements for an SBOM” document, while certainly good, is incomplete – that other fields need to be considered “essential” as well. After listing the seven minimum fields, the Guide lists eight additional “highly recommended” fields  (pages 29-30).
  • It is an unfortunate (but well-known) fact that the “naming problem” makes it very difficult to positively identify software components. An SBOM user will often want to learn something about how the supplier of a software product that they use identified the components shown in their SBOM. The new “components/evidence/identity” field allows the supplier to list the tools they deployed to identify components, the methods they used, and their level of confidence in their component identifications.
  • Another important OWASP project, which has been in the works for at least four years, is the Software Component Verification Standard, or SCVS. An important part of SCVS is the BOM Maturity Model; this is worth reviewing. (pages 30 and 31)
  • CycloneDX has always had a robust capability to make direct reference to external data sources. A huge number of new “External Reference” types have been added in v1.5. (pages 42-44).
  • There is now a field called “Metadata/lifecycles” that allows the supplier of the SBOM to state the lifecycle phase at which the SBOM was created. Because the characteristics of the SBOM can be very different depending on the phase, it should be very helpful to the user to have this information. The lifecycle phases are described on pages 13 and 14 of the Guide, but, since this is a text field, the supplier could alternatively include one of the six “SBOM Types” described in this document recently published by CISA.

Three Important SBOM Problems and Their Solutions

There are a number of important problems with SBOMs that have never been addressed, let alone solved, in any document by either the NTIA Software Component Transparency Initiative or one of the current CISA workgroups. They are:

  1. Since an intelligent device (such as a medical device or an IoT device in general) is different from a standalone software product, how can those differences be reflected in an SBOM?
  2. How can an SBOM be created for a “system of systems” — i.e., a system consisting of multiple intelligent devices or “modules”?
  3. How should a supplier describe an open source component that they have modified (“forked”) before including it in their product?

The Guide describes a solution to each of these problems, even though none of the solutions requires any of the new features of v1.5.

1. Multi-Product Solution

It is ironic that, even though the NTIA Initiative came about because of the FDA’s announcement in 2017 that it would start requiring SBOMs for medical devices in the future, none of the NTIA or CISA documents to date has even attempted to describe what is different about devices as opposed to “standalone” software (i.e., software that is not provided as part of a device).

The Guide (page 57) describes a typical device (e.g., a medical device or an IoT device) as a “multi-product solution,” meaning a device with multiple software and/or firmware products installed within it. The Guide makes two important recommendations about the SBOM for the device:

First, “the SBOM should have a single ‘bom/metadata/component’ and leverage subcomponents.” This single item is nothing less than the name of the device that the SBOM describes. This might seem like an obvious suggestion; after all, why wouldn’t the supplier provide a reference to the device itself, besides referring to each of the software or firmware products installed in the device? However, from what the author has heard, device SBOMs today usually do not identify the device itself.

Not having such an identifier creates a problem for the device user since they have no way to look up vulnerabilities by searching just for the device itself; instead, each user has to search for vulnerabilities in each software or firmware component individually. This makes little sense since the supplier could report those vulnerabilities to CVE.org using the device’s CPE name — rather than require each of their customers to do exactly the same amount of work, with the same results, as if the supplier did it once for all of their customers.

Second, for every (software or firmware) product included in the device, the supplier should “….ensure each is listed as a subcomponent of bom/metadata/component.” Why is this important? Because most of the software or firmware products installed in the device can easily be removed, upgraded, or replaced. Since components in CycloneDX are meant to be easily moved around within the SBOM or between SBOMs to reflect changes in the real world, having each product be a single component makes these SBOM operations almost trivially easy to execute.

2. Multi-Module Product

The author believes this refers to what is called a “system of systems” – i.e., a single hardware device that consists of multiple other hardware devices. The Guide says (on page 57), “The SBOM should have a single bom/metadata/component without subcomponents.”

The Guide continues, “Each module should be its own component, specified under bom/components. Each module may then either:

  • Include subcomponents, thus creating a hierarchy, or
  • Use external references to link to each module’s independent SBOM”

In other words, the modules (each of which is a device, of course) that are installed in the primary device should not be described as components of the primary device. Instead, they should be included in the BOM for the primary device (i.e., on the same “level” as the primary device). The software and/or firmware products that are included in the module can either be listed as subcomponents of the module or linked to a separate SBOM for the module.

As in the case of the multi-product solution above, taking this approach will make it very easy for the supplier to change the SBOM to reflect the fact that it has removed and/or replaced a module in the device, by removing and/or replacing the single unit of JSON code that corresponds to the module. Both of these solutions are great illustrations of the power of the CycloneDX format.

3. Modified Open Source Software Component

Of course, this refers to the fairly common occurrence in which a software or device supplier has modified an open source component before including it in their product. In this case, the Guide says (page 58), “Include component pedigree for each modified open source component.” In other words, use the “component/pedigree” field to indicate the open source package(s) that is/are the “ancestor(s)” of the component, as well as whether the component is a “descendant” or a “variant” of the ancestor.

In addition, the product supplier should modify the name of the component in the SBOM so that it doesn’t appear with the name of the original open source package. It is important to do this since, otherwise, the user is likely to believe that any vulnerability reported (in the NVD or another vulnerability database) for the original package will apply to the modified component in the product. In addition, the supplier should either:

  1. Start reporting (to CVE.org) vulnerabilities discovered in the modified component as applicable to a new CPE name for the modified component, or
  2. Consider the modified component to be part of the product’s first-party code, and report vulnerabilities in it under the product’s CPE name.

Learn More About CycloneDX

For more information on CycloneDX, consider checking out the following resources: