The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 


Which is the right SBOM format for us?

Tom Alrich's picture
Supply chain Cyber Risk management - emphasis on SBOMs and VEX documents, Tom Alrich LLC

I provide consulting services in supply chain cybersecurity risk management and am now primarily focused on software bills of materials (SBOMs) and VEX (Vulnerability Exploitability eXchange). I...

  • Member since 2018
  • 373 items added with 121,467 views
  • Jan 10, 2022



When they first start learning about SBOMs, some people are dismayed by the fact that there are several SBOM formats, and that the NTIA/CISA Software Component Transparency Initiative so far hasn’t anointed one of these as the Chosen One. In fact, the Initiative makes a point of saying that there is no reason for the software world to standardize on one SBOM format.

Moreover, neither Executive Order 14028 (which mandated that all federal agencies start requiring SBOMs from their suppliers. This will be required starting in August 2022), nor the two supporting documents that were mandated by the EO (the NTIA Minimum Elements document and NIST’s implementation guidance for the SBOM provisions, which is due on February 6 and for which draft language was posted in November) even hints that there will ever be a single “standard” SBOM format. I won’t say the day will never come when there’s a single universally accepted format, but I will say that I don’t think it should be imposed, whether by government regulations or even by some broad consensus of organizations that develop software and organizations that primarily use software (which pretty well means every public or private organization in the world).

Nevertheless, there’s a lot that can be said about formats:

  1. While the Initiative officially recognizes three formats - SPDX, CycloneDX and SWID – only SPDX and CycloneDX should be considered true SBOM formats. SWID was developed as a software identifier, and that is its primary use. While it does contain component information including the seven Minimum Elements, it doesn’t offer the richness of the other two formats.
  2. SPDX and CycloneDX differ in their original use cases. SPDX was originally developed (around 12 years ago) for open source license management – a use case that is very important for software developers, but not very important for organizations that do little or no software development. CycloneDX (CDX) was developed in 2017 for purposes of vulnerability management (it was developed for use with Dependency Track, which I discussed in my last post. Both CycloneDX and D-T are OWASP projects; in fact, CDX was designated an OWASP Flagship Project last June. Steve Springett is lead developer for D-T and co-lead for CDX).
  3. Because of their original use cases, SPDX is probably better at license management, while CDX is probably better at vulnerability management. However, one big advantage of having two major formats is that they compete with each other. The current version of SPDX is 2.2 (this version was designated an ISO standard last year). But the next version 3.0 will be a total rewrite, aimed squarely at vulnerability management.
  4. I have been hearing about v3.0 for a while. It sounds good, but since it has been under development for many years, and since I assumed it was going to be hobbled by the need to maintain compatibility with v2.2, I was not expecting it to be available soon (definitely not this year), or to be very useful when it arrived.
  5. So I was pleasantly surprised to hear Bob Martin of MITRE Corporation - who has been very involved with v3.0 development, and who is someone you run into every time you turn a corner in the world of software supply chain risk management – say last week that a) SPDX v3.0 will be available for general use this March, but b) it will not be compatible with v2.2. I interpret the latter to mean that a v2.2 SBOM will not be comprehensible to a tool that reads v3.0 SBOMs (of course, I’m sure there will be a conversion utility between the two formats).
  6. The latter item was good news. Trying to aim for compatibility with v2.2 would have severely limited how well v3.0 could accomplish its purpose of aiding the vulnerability management process. The fact that v3.0 “cuts the cord” to previous versions means it might well be a serious competitor to CDX in the vulnerability management space.
  7. However, CycloneDX isn’t standing still, either. That project will soon announce (I think imminently, but definitely by the end of January) its new v1.4, which will significantly enhance the vulnerability management capabilities in v1.3 – and I thought those were already pretty good. While I haven’t seen any specs for v1.4 yet, I know that one addition will be a VEX-like capability. That might in itself be a very significant development for several reasons, although the practice of using SBOMs for vulnerability management – as currently envisioned – will need to change, in order to take advantage of this capability. But if it’s going to change, now’s the time to do it, before anything is set in stone. The processes for using SBOMs for vulnerability management – for end users who aren’t also significant developers – is somewhere between infancy and toddlerhood.

But speaking of change, as I described recently, I no longer think the primary responsibility for identifying exploitable component vulnerabilities should rest with the end user. It should rest with the supplier, or perhaps with a third party service provider that has been engaged by the supplier or by the user. I have several reasons for saying this, but the most important is: Why should the 10,000 users of a software product all have to perform the exact same set of steps to identify exploitable vulnerabilities – and each acquire a so-far-nonexistent tool to help them do that – when it can be done much more efficiently, and of course at a significantly lower cost per user (in both money and time), by one or a few central organizations (either the supplier or a service provider)? Especially when the supplier should already be doing this work anyway?

In other words, in the long run I believe the biggest use for SBOMs, for software users that aren’t also significant software suppliers, will be checking the supplier’s (or the third party service provider’s) work of identifying exploitable component vulnerabilities. Some organizations will want to do this and will invest in the required tooling and expertise. Other organizations will decide to leave this work to the experts and just focus on the more important part of vulnerability management: given the current lists of exploitable component vulnerabilities in the software products the organization uses, figuring out where and how the vulnerabilities can affect the organization, and taking mitigation steps (primarily, bugging the developers to patch the serious vulnerabilities ASAP) based on the degree of risk posed to the organization by each vulnerability.

Even in the ideal world I’m outlining, I think most users will still want to receive SBOMs and VEXes from their software suppliers, even though they won’t bear the primarily responsibility for identifying component vulnerabilities. But the decision which SBOM format to request from suppliers (or even whether to ask for a specific format at all, as long as the supplier uses either SPDX or CycloneDX) won’t be quite as crucial as I had thought previously.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

Richard Brooks's picture
Richard Brooks on Jan 10, 2022

I agree that choosing SPDX or CycloneDX are the safe options going forward. I've used both formats and they are equally good at enabling a software consumer to perform a NIST C-SCRM risk assessment following NIST SP 800-161 R2 Appendix F (final version due in February 2022) to meet Executive Order 14028 requirements.

I'm not sure what Bob Martin meant about backward incompatibility with prior versions of SPDX.   From what I've heard, V3.0 will have less constraints than previous versions of SPDX, but I don't think this equates to incompatible. Maybe someone closer to the V 3.0 development can comment.

In my experience, both SPDX and CycloneDX are adequate for EO 14028 and the support provided within each community is exceptional - even better than some paid support I've experienced in the past. The only advice I would offer anyone requesting an SBOM from their software vendors is to request the most mature and proven formats, Tag Value for SPDX and XML for CycloneDX. 

Tom Alrich's picture
Thank Tom for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »