A Guide to Standard SBOM Formats
The software bill of materials (SBOM) has become an increasingly important tool for providing much-needed clarity about the components that make up software — both for application security purposes and governmental compliance.
Unlike manual spreadsheets, SBOMs standardize everything into a particular format to minimize inconsistencies. There are three primary SBOM formats currently available, which allow companies to easily generate, share, and consume SBOM data. However, there are some differences that may make one a better choice depending on your company’s needs.
How do you know which one is right for you? Let’s take a look.
Software package data exchange (SPDX)
SPDX is an open standard for software bill of materials (SBOM) that identifies and catalogs components, licenses, copyrights, security references, and other metadata relating to software. Primarily designed to improve license compliance, it is also used to improve software supply-chain transparency and security. SPDX is authored by the community-driven SPDX Project under the auspices of the Linux Foundation. SPDX uses a standardized, machine-readable format that makes it consistent across different companies and industries. This reduces the need to reformat information, makes it easier to share, and consequently improves compliance and security efficiency. It is arguably the largest, most heavyweight SBOM format, and it’s the only one of the three main formats that has an ISO (International Organization for Standardization) accreditation.
Who is it for? SPDX is commonly used by large, complex organizations such as Intel and Microsoft. Users with a preference for Linux inevitably gravitate towards SPDX, as do those that build software or operate enterprise software. More and more organizations are implementing SBDX, especially those that increasingly use open source projects and create commercial software.
Strengths and weaknesses. This format is good for providing a big picture of your software supply chain, components, and dependencies, which allows for a multiplicity of annotations and the most detail. That’s because SPDX identifies the software package, the package level, the file-level licensing and copyright data, and also shows the file creator, as well as when and how it was created. Its size and capacity make it a particularly flexible option, and it’s meant to be an all-inclusive format.
See how you can generate an SBOM report in SPDX here.
CycloneDX (CDX)
Created by the Open Worldwide Application Security Project (OWASP), CycloneDX is very similar to SPDX, albeit lighter. It is described as a full-stack bill of materials standard that provides advanced supply chain capabilities for cyber risk reduction. The specification supports:
- SBOM
- Software-as-a-Service Bill of Materials (SaaSBOM)
- Hardware Bill of Materials (HBOM)
- Operations Bill of Materials (OBOM)
- Vulnerability Disclosure Reports (VDR)
- Vulnerability Exploitability eXchange (VEX)
The CycloneDX project provides standards in XML, JSON, and protocol buffers, as well as a large collection of official and community-supported tools that create or interoperate with the standard. Strategic direction of the specification is managed by the CycloneDX Core Working Group and is supported by the global information security community.
Who is it for? CycloneDX is often preferred by nimbler organizations and by teams that use open source heavily.
Strengths and weaknesses. The lighter-weight nature of CycloneDX tends to make it more agile. It includes fewer details, which makes it simpler to use and perhaps more user-friendly than SPDX, although it’s also less inclusive.
Software identification tags (SWID)
Established by the U.S. National Institute of Standards and Technology (NIST), SWID is an industry standard used by different commercial software publishers. According to NIST, SWID tags provide a transparent way for organizations to track the software installed on their managed devices. SWID tag files contain descriptive information about a specific release of a software product. SWID uses the following four types of tags:
1. Primary: Identifies and describes a software product installed on a computing device.
2. Patch: Identifies and describes an installed patch that has made incremental changes to a software product installed on a computing device.
3. Corpus: Identifies and describes an installable software product in its pre-installation state. Used to represent metadata about an installation package or installer for a software product, a software update, or a patch.
4. Supplemental: Allows additional information to be associated with any SWID tag, to ensure that primary and patch Tags provided by a software provider are not modified by software management tools, while allowing these tools to provide their own software metadata.
Who is it for? Organizations that want a quick, easy-to-use, and simple inventory of its software components and dependencies may prefer to use SWID, providing they understand that this format’s capabilities are much more limited than those of SPDX and Cyclone DX. Nevertheless, a number of standards bodies, including the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF) use SWID Tags in their standards.
Strengths and weaknesses. If your aim is simply to create an inventory and catalog components and dependencies, SWID offers the easiest-to-use option. However, its use is limited to this. SWID focuses on being an inventory and isn’t as inclusive as the others. It doesn’t provide details such as vulnerability information, annotations, or license information, so it doesn’t solve as many issues as the other formats.
If you want to use an effective SBOM, you’re recommended to stick to one of the three main formats or a combination of them. While there are numerous other specifications out there, they aren’t standardized, so their use and influence are negligible. For a comprehensive list, consult the NTIA’s Survey of Existing SBOM Formats and Standards report.
Why so many formats?
SBOM development and adoption is not yet fully mature, which means that further standardization will happen as SBOM use becomes even more widespread.
For Generation X-ers — those of us of a certain vintage — the current situation brings to mind the video format war of the 1980s between Betamax and VHS video-cassette formats, and the high-definition optical disc format war of the early 2000s, between HD DVD and Blu-ray disc. The differentiators that drove VHS and Blu-ray to victory weren’t technical. Rather, cost, adoption, ease of use, availability of content to users, and sharing capabilities were the deciding factors. I anticipate a similar dynamic will take place with SBOM formats. As governments increasingly introduce guidance that requires SBOMs, and more open source software components are used from an expanding volume of sources, SBOM use will increase and users’ demand for standardization into one format will amplify and gather momentum. Watch this space.
Predicting the winner
We can confidently say that SBOMs are going to play an important part in the process of developing and selling applications and software. Each of the main formats will serve an SBOM’s purpose. The one you choose depends on how granular you want and need to be, or perhaps how detailed the recipient of your SBOM requires you to be. That could vary depending on whether this party is a government body, a potential buyer in an M&A situation, or more simply a prospect or customer. If I were to bet on a format that wins out, I’d choose Cyclone DX for a couple of reasons:
- It combines more detail than SWID and enables you to retain vulnerability information, annotations, or license information.
- It provides you with an ease of use that beats SPDX.
If you’re looking to choose an SBOM format, then that’s my recommendation. Most importantly for your business, is to put an effective SBOM in place because as you progress, it will become essential and unignorable.
