Alex - stock.adobe.com
SBOM formats compared: CycloneDX vs. SPDX vs. SWID Tags
Organizations can choose between three SBOM formats: CycloneDX, SPDX and SWID Tags. Learn more about them to determine which fits your organization best.
Software bills of materials, or SBOMs, inventory every application in use at an organization. This standard catalog of application components and dependencies boosts software supply chain security by enabling security teams to find and mitigate application security vulnerabilities, as well as ensure compliance with internal and government regulations.
The three standard SBOM formats are CycloneDX, Software Package Data Exchange (SPDX) and Software Identification (SWID) Tags. Let's take a deeper look at each option.
CycloneDX
OWASP's open source CycloneDX SBOM format aims to reduce cyber-risk and improve the security of source code development. OWASP designed CycloneDX to be more lightweight than other formats, which can be ideal for agile organizations.
CycloneDX breaks out the software's components, services, dependencies and compositions into a readable list. Security teams can add important data and details about the software, including vulnerabilities, manufacturing and deployment info, and other contextual information.
CycloneDX works with XML, JSON and protocol buffer data formats. This SBOM format suits organizations focused on identifying and tracking vulnerabilities.
CycloneDX supports the ability to create the following:
- SaaSBOMs. SaaSBOMs document the different components and services of SaaS applications. CycloneDX covers HTTP/HTTPS, REST, GraphQL and MQTT protocols.
- Hardware BOMs. HBOMs inventory IoT devices and industrial control systems.
- Machine learning BOMs. ML-BOMs inventory the models and data sets used for machine learning and AI integrated into software.
- Operations BOMs. OBOMs break down runtime environments and their hardware, systems, firmware, libraries and more.
- Vulnerability disclosure reports. CycloneDX documents and publishes reports on known vulnerabilities and how to remediate them for components within an SBOM.
- Vulnerability Exploitability eXchange (VEX). Security teams can create a VEX, which documents the details, context and remediation efforts of any component vulnerabilities found.
SPDX
Created by the Linux Foundation, the open source SPDX became the only internationally recognized SBOM standard in 2021, known as ISO/IEC 5962:2021. Large organizations often select SPDX when they need to manage the licenses of the software components in use, as well as mitigate vulnerabilities.
SPDX inventories application components, license and copyright info, and security references. To improve security, teams can use common global reference systems, such as Common Platform Enumeration, Software Heritage persistent ID or Package URL, to connect software artifacts. SPDX also supports a variety of file formats, including SPDX, JSON, YAML, RDF and XLS.
SPDX comprises the following three parts:
- SPDX specification.
- SPDX licensing scheme.
- SPDX tools and libraries.
The latter are built by the community alongside commercial vendor tools. Some open source SPDX tools include the following:
- Build creates plugins or extensions that provide build file metadata and source files.
- Audit Tool analyzes modules of the source code using various auditing techniques.
- License Diff enables security teams to document the differences between source code modules.
- Merge brings all source code modules into one cohesive format during software development.
SWID Tags
NIST's SWID Tagging differs from CycloneDX and SPDX because it technically isn't a full-fledged SBOM format. SWID Tags -- which contain standardized information about software -- help organizations track installed software to remain compliant with licensing agreements and up to date with patches. They do not aggregate information of all software, as CycloneDX and SPDX do. Rather, SWID Tag producers -- software and platform developers -- create tags to help SWID Tag consumers -- organizations using that software -- gain transparency into the components of the products.
Security teams can integrate SWID Tags into automated scanning tools for security use cases, including vulnerability scanning. NIST is also currently adding SWID Tag data to the National Vulnerability Database. SWID Tag data has already been added to the Security Content Automation Protocol (SCAP) version 1.3.
Alongside tracking installed software on managed devices, SWID Tags help teams do the following:
- Determine if software components used in the application development process are compliant with organizational security policies.
- Ensure all software patches and updates are applied.
- Confirm a valid configuration process is in place.
- Find, deprecate and replace outdated legacy software with newer versions.
- Detect changes made to software installation media.
- Halt unauthorized software installation.
Ravi Das is a cybersecurity consultant and business specialist who specializes in penetration testing and vulnerability management content.
