Are the major SBOM formats interchangeable? Not very.

 

On Monday May 23, I had the wonderful opportunity to participate in a webinar on SBOMs with three people who have worked with and thought about SBOMs a lot. The panel was sponsored by six IEEE chapters in the NE Virginia/DC area, and also included Dr. Allan Friedman of CISA, Dr. Jean Camp of Indiana University, and Steve Pruskowski of CISA.

The group made some excellent observations, some of which were new to me. I recently listened to the recording, and I suggest it will be worthwhile for you to do that, too. Here is the link to the recording.

One good question had to do with SBOM formats – whether it’s sustainable to have multiple formats and whether they’ll easily interoperate with each other.  One of the other panelists said there were lots of tools for translating between the two major formats (SPDX and CycloneDX), and that it shouldn’t matter which format your SBOM is in – it will be usable in all tools and for all purposes, because it can always be translated to the other format. In fact, I would say this is the consensus opinion in the software community.

When I was asked to comment, I said I agreed with that answer to a point, but I added that it’s important to remember that the two formats both go far beyond the seven minimum fields that should be included in an SBOM. They each have 50-100 fields, and a lot of those aren’t replicated in the other format; so the information in those other fields will be lost in translation. This means that anyone who wants to convert between the two formats needs to make sure that all the fields in the original SBOM are available in the target format.

But I realized later that what I said falls far short of the real problem, which is that the two formats go about what they do in very different ways – so that addressing many of the differences between them requires doing a lot more than simply adding a field on one side or the other (if that’s all that were required, I’m sure all differences between the two formats would have disappeared a while ago).

Here’s an example of what I mean: One longstanding object of discussion (which Allan Friedman mentioned in the webinar) is the fact that a software supplier will sometimes make changes to the code of an open source component before incorporating it into their product. Of course, this is completely permissible, but a problem arises if the SBOM still lists the original name and version string of the component.

Because customers will normally look up the component in a vulnerability database like the NVD in order to find the vulnerabilities that apply to it, it’s possible – if the supplier did modify the code of the component – that they will either a) learn about – and possibly act upon – vulnerabilities that are no longer found in the component implemented in the product they use (because the supplier modified it), or b) not learn about a vulnerability that the supplier themselves inadvertently introduced into the component when they modified its code. Obviously, neither of these is a good thing.

CycloneDX (CDX) can represent this situation, as well as a few similar ones, using the “pedigree” field. Included in that field are five possible relationships: ancestors, descendants, variants, commits and patches.  Can all of these be translated into SPDX? SPDX includes 40 or so “Relationships”, and most of the CDX pedigree fields are included in those relationships.

However, there is a big difference in how the relationships are implemented in the two standards: Those “Relationships” in SPDX only apply to source code files, while “pedigrees” in CycloneDX also apply to libraries and entire operating systems. This means that, if a supplier has incorporated a modified library into their software product, they can represent that fact in a CycloneDX SBOM, but not in SPDX.

On the other hand, SPDX supports snippets, which are small bits of code that can be easily incorporated into a program in an integrated development environment. They can be similar to components, in that they’re sometimes developed by third parties; including them in software can save the programmer a lot of time. However, snippets sometimes come with licensing issues, which a developer needs to be aware of. CycloneDX doesn’t currently support snippets, meaning that, if an SPDX SBOM includes snippet information and is translated from SPDX to CycloneDX, it will not retain that information.

To sum up, you should never assume that an SPDX SBOM can be faithfully translated into the CycloneDX format or vice versa.[i] This means you need to think beforehand about what you need in a format before you standardize on one format or the other.

However, this might be a moot point. If your organization is a software supplier, I recommend you consider creating SBOMs in both formats, since it’s likely that some end-user tools that utilize SBOMs will only support one or the other format.

And if you’re an end user, I would strongly recommend that you not announce that you’ll only support SBOMs in one or the other format. You may miss out on SBOMs from some suppliers, who might feel they’re too small or under-resourced to support both formats. If you find a tool that only accepts one of the two formats,[ii] you’ll initially have to require SBOMs in only that format – and if one of your suppliers says they’re only going to provide SBOMs in the other format, you should have a discussion with them about whether they’ll change their mind.

But there’s another option on the software consumer side: In probably the next 3-6 months, there will be at least one subscription-type service available that will ingest SBOMs and VEX documents and perform risk analysis based on them (as well as on other information sources).[iii] Services like that will be able to handle both SBOM formats, so the Format Wars (and the need even to receive SBOMs) will go away forever, for their customers.

Unrelated note about the webinar: When asked about how SBOMs could gain acceptance by organizations in general, Jean Camp made the interesting point (starting at about 27:50 in the recording) that SBOMs might initially be positioned similarly to how the EnergyStar label was positioned: If a supplier is willing to provide SBOMs for their products, they obviously are committed to transparency about their security posture. Even if the user never does anything with the SBOM when they receive it, the fact that the supplier is willing to provide a regularly updated SBOM means they feel they have nothing to hide from their customers. This alone will be a great driver for improving software security.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

---

[i] I need to point out that, while SPDX 2.2, the current version, is descended from an original version developed ten years ago for the purpose of open source licensing risk management, a new version 3.0 will appear later this year or next year, which is designed from the bottom up as a cybersecurity risk management tool – so it may be able to handle pedigree information for libraries. On the other hand, I’m told that an upcoming version 1.5 of CycloneDX will support snippets, so that difference between the formats will also go away. 

But I’m sure there will always be things that one format does and the other doesn’t, or at least that they do in significantly different ways. Let’s face it: The two formats are competing with each other. It’s not at all in their interest to become bland variants on each other. 

[ii] The only complete SBOM consuming tool that I know of (where “complete” means that it can ingest both SBOMs and VEX documents) is the next version of Dependency-Track, which will be available soon. This tool only supports CycloneDX SBOMs and (soon) VEX documents in the CycloneDX VEX format. 

[iii] There are currently services that will perform this type of work on an hourly consulting basis. Those are fine, but they won’t scale well, especially with significant increases in the volume of SBOMs and VEX documents being produced. What’s needed are subscription-based services, whose costs will decline in the future, as volume increases.