This is my second post in SBOM series where I would explain why we chose CycloneDX over SPDX for our projects. The first post was focusing on the need to have more than one bill of materials to describe any particular product.
Table of Contents
I Introduction
If you search the web or ask ChatGPT about CycloneDX vs SPDX, you will see a bunch of canned responses that do not have a lot of meaning. As always, I’m trying to approach this choice from purely practical prospective.
II Historical Reasons – JSON format
I started Reliza as a Release Metadata and then DevOps company in 2019. We are a Release Metadata and Supply Chain Security company now. We are building a soon-to-be-released product that maintains and organizes storage of various release artifacts. Bills of materials take significant proportion of those artifacts.
In 2019, the CycloneDX project was less than a year old, while SPDX was an 8-year old standard.
Still, CycloneDX was a clear winner for us – first of all because it was using XML / JSON serialization format (with eventually JSON becoming mainstream) rather than SPDX own format.
While SPDX supported JSON and other serializations, most documents were never using it and it is only becoming a trend now in version 3.x.
I believe that this rather minor looking difference in serialization formats led to explosion of CycloneDX tooling and usage in its early days relative to more mature SPDX.
III In CycloneDX, everything is Component
Our primary use case was to programmatically create OBOMs. Our product Reliza Hub handles information about software components to be deployed on infrastructure instances (mainly, Kubernetes clusters or VMs). Each instance would poll Reliza Hub for this OBOM document and perform deployment based on its data.
Here, CycloneDX provided us with a universal notion of components and their types. Everything was a component. We could even screw up a type sometimes – like frequently it was not that important for our use case whether something is called an application or a container.
If we would go with SPDX, we would have to figure out every time whether we are dealing with files, packages or something else – we had to know that, otherwise OBOM parsing would fail.
IV Purl is King
Another cool thing about CycloneDX is that it treats package URL (purl) as a first class citizen. Purl solves one of the main problems in modern supply chain management, namely – identifying things. Subtle differences in naming mean that we cannot be sure whether we are referencing the same product or a different one. Purl aims to solve that problem.
Note that we are not quite there yet – meaning that the problem is still present despite the efforts. However, this is one of the most important things to be focusing on at the moment and CycloneDX team is working on it. Also, we are already able to apply certain internal conventions on purls to have local solutions for this problem at least within the organization.
V CycloneDX Reaches Beyond Software
CycloneDX is not positioning itself as a software-only standard. While the industry very much likes the term SBOM, a better term to describe what CycloneDX produces would be xBOM. That can be interpreted as a bill of materials of everything. Specifically, CycloneDX already allows to document vulnerabilities, hardware, manufacturing, operations and other things (see current list here).
VI Limitations and Expansion of Standards
One more thing that I want to mention here is periodically I see information that CycloneDX is not suitable for certain use cases. I believe this is something not worth bringing up.
Of course, there are real-life use-cases that are not well covered by CycloneDX and / or by SPDX. For example, one of the current ones is related to external dependencies as mentioned here. However, this is a universal problem with any bureaucratic approach where the real world is always bigger than any specific set of definitions that we can come up with.
Going forward both standards are expanding in terms of what they describe and eventually we can expect that corner cases would be addressed.
VII Conlusion
SPDX has improved significantly in its latest 3.x iteration (released in 2024) – essentially becoming more like CycloneDX in many regards.
However, I believe it is not ideal to have 2 standards describing the same thing. It is challenging to convert from one standard to another which makes tooling non-interoperable.
For the reasons I mentioned above, I believe that CycloneDX is just a better standard with a stronger vision to become more universal and going beyond the limits of just software which allows to describe complex multi-modal systems. It should be highly beneficial for the industry to converge around a single standard and that should be CycloneDX.
