Software BOMs (SBOMs) are becoming an essential part of vulnerability management. However, many organizations still struggle to understand the fundamental topics of the SBOM discussion, such as the differences between SBOM formats.
What are SBOM formats?
SBOM formats are standards for defining a unified structure for generating SBOMs and sharing them with end users or customers. They describe the composition of the software in a common format that other tools can understand.
The main SBOM formats are Software Package Data Exchange (SPDX), Software Identification (SWID) Tagging and CycloneDX. Only SPDX and CycloneDX are adopted for security use cases. SWID is primarily licensing-focused and therefore not covered in this discussion. As stated by the US Cybersecurity and Infrastructure Security Agency (CISA) and others, we will have multiple SBOM formats for some time.
SPDX, a project of the Linux Foundation, was created with the aim of creating a common data exchange format for sharing and collecting software package information. SPDX supports the largest collection of file formats among the major SBOM formats. These include RDFa, .xlsx, .spdx, .xml, .json, and .yaml. SPDX also aims to be a dynamic specification by being able to describe a set of software packages, files or extracts.
SPDX is the only SBOM format that has achieved International Organization for Standardization (ISO) certification status, meaning it has met all standardization and quality assurance requirements as defined by ISO . This achievement, announced in September 2021, highlighted the adoption of SPDX by major companies such as Intel, Microsoft, Siemens and Sony who participate in the SPDX community.
The SPDX specification at the time of writing this article is on version 2.2.2. To be considered a valid SPDX document, specific fields and sections must be present, which are defined in the SPDX specification. SPDX documents can be composed of fields and data such as document creation information, package information, file information, snippet information, license information, relationships, and annotations.
Document creation information is used for backward and forward compatibility when using processing tools. Package information is used to describe different entities, such as products, containers, and components, and can be used to group related items that share context. File information includes file metadata such as names, checksum licenses, and copyright information. Extracts are optional and are mainly used when the data comes from a different original source or is linked to another license. SPDX also supports relationships for documents, packages, and files. Annotations allow a reviewer to include information about their review activities in an SPDX document.
SPDX also offers an SPDX Lite profile, which is a subset of the SPDX specification, with the aim of aligning with industries specific workflows while balancing compliance with the standard and overall SPDX specifications. The Lite profile focuses on the fields in the document creation and package information sections, and the basic information that comes with them.
CycloneDX is led by long-time security community leader Open Web Application Security Project (OWASP). CycloneDX is a “lightweight SBOM standard designed for use in application security contexts and supply chain component analysis“. Its core team includes Patrick Dwyer, Jeffry Hesse and Steve Springett, software supply chain manager and creator of Dependency Track., who chairs the group. Besides OWASP, CycloneDX supporters include Lockheed Martin, Contrast Security, and Sonatype.
What makes CycloneDX unique is that it was designed from the ground up to be a BOM format and to serve a variety of use cases, including Software as a Service (SaaSBOM) BOM. CycloneDX supports a myriad of use cases beyond software.
CycloneDX also supports referencing components, services, and vulnerabilities in other systems and BOMs, in a nested, hierarchical approach that aligns with the complexity of the modern software ecosystem across hardware, cloud, and of SaaS. CycloneDX refers to this capability as a “BOM-Link.“It also supports this feature in JSON and XML formats. Users can reference the external BOM URL or even a BOM-Link URI that uses serial numbers and versions for external BOMs.
In addition to the above, CycloneDX allows for a complete and accurate inventory of all proprietary and third-party components for risk identification. It does this through a robust list of component types and classes, which extend beyond software and apps and into devices and even services. It allows the identification of vulnerabilities through three fields, which are Common Platform Enumeration (CPE), SWID and Package-URL (PURL). The CPE specification can be used for vulnerabilities in operating systems, applications, and hardware devices. SWID is used for installed software and PURL can be used for software package metadata.
CycloneDX supports checking the integrity of components associated with the BOMs it is used for through hash values and cryptography. Software signing is increasingly becoming a best practice in the push to mature software supply chain security through projects such as Sigstore and its accompanying Cosign. CycloneDX also supports provenance, which is the ability to represent the component authors and vendors the component is obtained from.
Building on the concept of provenance, CycloneDX can support component pedigree by communicating component ancestors, descendants, and variants to describe a component’s lineage. For high assurance software supply chain requirements, implementing provenance, pedigree, and digital signatures represent robust supply chain capabilities and is recommended by guidelines such as NIST’s Cybersecurity Supply Chain (C-SCRM).
CycloneDX also provides support for the Vulnerability Exploitability Exchange (VEX), which provides insight into the exploitability of known vulnerabilities in software products and components and can be communicated by software producers.
Several SBOM format standards to continue
As industry adoption and usage shows, these two major SBOM formats are likely to stay here for some time and both software producers and consumers would be better off if they could support both formats. . Major SBOM generation tools such as Anchore’s Syft also support both formats.
The SBOM format ecosystem will evolve as SBOM adoption and maturity continue to grow. We will see innovations from these projects as well as potential new SBOM formats come into the fold. While there is room for debate as to which format may be superior, the need for transparency and security in the software supply chain becomes non-negotiable as malicious actors rapidly increase their use of this attack vector.
Copyright © 2022 IDG Communications, Inc.