Software bills of materials (SBOMs) are becoming a critical component of vulnerability management. Many organizations, however, are still wrestling with understanding fundamental topics in the SBOM discussion, such as the differences among the 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 software in a common format that other tools can understand.
The leading SBOM formats are Software Package Data Exchange (SPDX), Software Identification (SWID) Tagging, and CycloneDX. Only SPDX and CycloneDX are being adopted for security use cases. SWID is primarily focused on licensing and is therefore out of scope for this discussion. As the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and others have stated, we will have multiple SBOM formats for some time.
SPDX
SPDX, a Linux Foundation project, was formed with the intent of creating a common data exchange format for information related to software packages for sharing and collection. SPDX supports the largest collection of file formats among the leading 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 snippets.
SPDX is the only SBOM format that has achieved International Organization for Standardization (ISO) certification status, meaning it has met all the requirements for standardization and quality assurance as defined by ISO. This achievement, announced in September 2021 highlighted SPDX adoption by major corporations such as Intel, Microsoft, Siemens, and Sony that participate in the SPDX community.
The SPDX specification as of the time of this writing 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, licensing information, relationships, and annotations.
Document creation information is used for forward and backward compatibility when working with 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. Snippets are optional and are primarily used when data has been derived from a different original source or tied to another license. SPDX also supports relationships for documents, packages, and files. Annotations allow a reviewer to include information from their review activities in an SPDX document.
SPDX also offers an SPDX Lite profile, which is a subset of the SPDX specification, with the goal of aligning with specific industries workflows while balancing adherence to the overarching SPDX standard and specification. The Lite profile focuses on fields from document creation and package information sections as well as accompanying basic information.
CycloneDX
CycloneDX is being led by longtime security community leader Open Web Application Security Project (OWASP). CycloneDX is a self-defined “lightweight SBOM standard designed for use in application security contexts and supply chain component analysis.” Its core team includes Patrick Dwyer, Jeffry Hesse and software supply chain leader and Dependency Track creator Steve Springett, who serves as the group’s chair. Aside from OWASP, CycloneDX supporters include Lockheed Martin, Contrast Security and Sonatype.
What makes CycloneDX unique is that it was designed from the onset to be a BOM format and meet a variety of use cases, including software-as-a-service BOM (SaaSBOM). CycloneDX supports myriad use cases beyond software.
CycloneDX supports referencing components, services and vulnerabilities in other systems and BOMs as well, in a nesting and hierarchical approach that aligns with the complexity of the modern software ecosystem when it comes to hardware, cloud and SaaS. CycloneDX refers to this capability as a “BOM-Link.” It supports this capability in both JSON and XML formats as well. Users can reference the URL of the external BOM or even a BOM-Link URI that uses serial numbers and versions for the external BOMs.
Aside from the above, CycloneDX allows for a complete and accurate inventory of all first- and third-party components for risk identification. It allows this through a robust list of component types and classes, which extend beyond software and applications and get into devices and even services. It allows for 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 provides support for integrity verification of the 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 for maturing software supply chain security through projects such as Sigstore and its accompanying Cosign. CycloneDX also supports provenance, which is the ability to represent component authors and suppliers from which the component is obtained.
Building on the concept of provenance, CycloneDX can support component pedigree by communicating component ancestors, descendants and variants to describe the lineage of a component. For high-assurance software supply chain requirements, the implementation of provenance, pedigree and digital signatures represent robust supply chain capabilities and are recommended by guidance such as NIST’s Cybersecurity Supply Chain Risk Management (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.
Multiple SBOM format standards to continue
As evident from the industry adoption and use, these two leading SBOM formats are likely here to stay for some time and both software producers and consumers would be best positioned if they can support both formats. Leading SBOM generation tools such as Anchore’s Syft also support both formats.
The SBOM format ecosystem will evolve as SBOM adoption and maturity continues to grow. We will see innovations from these projects as well as potential new SBOM formats enter the fold. While there is room for debate between which format may be superior, the need for software supply chain transparency and security is becoming non-negotiable as malicious actors rapidly increase their use of this attack vector.
Copyright © 2022 IDG Communications, Inc.
