When teams are interested in SBOMs for their asset and dependency tracking, they’ll look for formats that integrate smoothly with existing CI/CD pipelines, are easy to automate, and offer minimal disruption to workflows. However, multiple teams, all with different needs, are likely to put their own stamps on SBOMs, making consistency and sharing across organizations (and beyond) an ongoing issue. Here’s what security teams need to know about adopting a single format.
What are SBOM Format Types?
Organizations understand the benefits of accounting for all the software components they deploy to the cloud, such as the power to quickly identify vulnerabilities and their impacted dependencies. We’ve already looked at what SBOMs are and what benefits and challenges they present.
However, there is also the question of how teams account for those components. Multiple formats have emerged, each with its own specific attributes and strengths (e.g., security vs. compliance vs. asset management). Those formats evolve as the need for more granular and interoperable security data grows.
The most popular formats are:
- CycloneDX, created by OWASP Foundation
- Software Package Data Exchange (SPDX), created by the Linux Foundation
- Software Identification (SWID) Tags, created by the International Organization for Standardization (ISO/IEC 19770-2)
All are open standards, available for anyone to use and contribute to, and to integrate with their software ecosystems and CI/CD pipelines. And all are created to enhance software transparency. But beyond those basic similarities, distinct advantages and challenges for each format make each better suited to a different use case.
Understand Dependencies with Upwind
Upwind integrates SBOM capabilities that streamline component tracking, combining SBOM insights with real-time monitoring.
Benefits and Drawbacks of SBOM Formats
Selecting the right SBOM format is a strategic decision, especially for security teams looking to harmonize software supply chain visibility, compliance, and cross-functional alignment. It’s also a question for teams looking to streamline security and increase cohesion among teams and tools.
Teams are looking for comprehensive cloud security strategies to help move them up the maturity curve, but with interoperable tools that integrate into existing workflows and systems.
— Joshua Burgin I CPO, Upwind
To make an informed choice, consider how each format’s strengths and integrations support your organization’s security, legal compliance, and operational tracking requirements.
CycloneDX/CDX
Cyclone DX is tailored for security and vulnerability management, with a well-defined structure to track component risks across the software lifecycle. It offers detailed component insights, including vulnerability data that aids security teams in assessing risk. It’s also a flexible format that supports XML and JSON, so it easily integrates into many security tools and platforms.
However, CycloneDX isn’t for all teams. It has a limited focus on compliance and is less comprehensive for tracking licensing details, which could be a disadvantage for teams heavily focused on open-source compliance. And while it’s popular with security teams, CycloneDX has less penetration in industries outside security circles, making sharing more difficult.
CycloneDX works best for organizations that prioritize security over license compliance, particularly in software that deals with critical infrastructure or sensitive data. It’s also ideal for companies seeking deep integration with vulnerability databases and dependency scanning tools.
SPDX
SPDX is widely adopted in open-source communities for extensive licensing support and across industries where it enjoys broad use. Its popularity may be due to its flexibility: SPDX can support teams across YAML, XLM, JSON, or RDF formats.
With greater emphasis on licensing, SPDX doesn’t have the in-depth vulnerability management features of CycloneDX. Its license-heavy focus can also create complexity for teams focused on security alone.
Organizations focused on open-source compliance find a lot to celebrate with SPDX. They can track open-source usage for legal and compliance teams. For enterprises with mature open-source policies, the format provides a unified way to track license data and dependencies.
SWID Tags
CycloneDX and SPDX are the two most popular formats, while SWID has a more niche role. Because it was created as an ISO/IEC standard, SWID is ideal for industries looking for strict compliance and asset tracking, especially in government and large enterprises. SWID tags were designed for software asset management, so they’re best for tracking installed software and component lifecycles. SWID is supported by multiple enterprise software vendors, so it appeals to organizations with complex software inventories.
SWID lacks the granular security and licensing information of either CycloneDX or SPDX, which can limit its appeal for security-focused teams. It’s also primarily focused on installed software. Teams interested in securing the development pipeline can find that emphasis limiting.
SWID serves government and enterprise asset management needs well. For industries that plan to align with ISO standards, SWID provides a standardized approach to asset tracking.
Other Formats
For companies with less complex requirements, limited budgets, or those in industries that don’t mandate comprehensive software transparency, simpler tracking tools or custom methods may suffice. Others may use a hybrid approach, combining one of the three standard SBOM formats with additional in-house tools or reporting systems to capture details unique to their operations.
As SBOMs become more central to software security standards, many government and industry regulations guide organizations toward one of the “big three” formats. But there are multiple reasons to look elsewhere, utilizing:
- Custom SBOM Formats: Custom formats can capture details not covered in the standard formats, including the developer, jurisdiction, compiler version, component age, health metrics, exploitability ratings, etc.
- Simple manifest files: Smaller companies or organizations with simpler software stacks can rely on package.json for node.js, requirements.txt for Python, or other dependency manifests. They won’t help with dependency management.
- OpenChain Specification: While not an SBOM format, OpenChain is a Linux Foundation framework for managing open-source compliance through processes and best practices, not through tracking individual components (which may not be necessary for their risk profile).
- SBOM-like Components in Container Registries and CI/CD Tools: Registries and CI/CD tools can often generate dependency and vulnerability reports that are enough for some transparency needs. They’re not SBOMs in the strictest sense.
Comparing CDX and SPDX for Use Cases
The choice between SBOM formats often involves a closer look at nuanced capabilities, especially for organizations with specific regulatory and operational priorities. Let’s look at specific features and consider use cases, examining CycloneDX and SPDX separately:
| Feature | CycloneDX/CDX | CycloneDX Use Case |
| Data Granularity and Depth | Includes detailed metadata on vulnerabilities, exploit potential, and remediation options. Can pinpoint which dependencies have known vulnerabilities and what patches or mitigations are available. API support to define each interaction and identify endpoint vulnerabilities more easily | A financial services firm using third-party libraries in its software stack would use CycloneDX data to continuously assess vulnerabilities, receive early alerts on critical flaws, and prioritize patches, reducing risks in real-time applications. |
| Interoperability with Security Tools | Integrates seamlessly with various CI/CD pipeline tools.Supported by vulnerability databases | A SaaS provider that frequently updates its applications can use CycloneDX data within its CI/CD pipeline to automatically scan each new release for vulnerabilities. |
| Extensibility and Customization | Allows custom metadata fields for tracking proprietary metrics like component criticality | A healthcare technology firm handling patient data could include internal security ratings for dependencies so teams can prioritize remediating vulnerabilities in libraries that handle sensitive data |
| Community and Ecosystem Support | Extensive support within security-focused communities and DevSecOps circlesUpdates frequently address emerging threats | A cybersecurity firm specializing in threat detection could employ CycloneDX as its default SBOM format because it benefits from rapid updates that respond to new vulnerabilities |
| Component Hierarchy and Relationships | Multi-level dependency mapping, capturing direct and transitive dependencies in complex applications | A cloud services provider could map dependencies within its microservices architecture, speeding targeted patching during critical updates |
| Versioning and Update Frequency | An agile update cycle aligns with rapid changes in the security landscape | A software consultancy working on DevSecOps projects might employ a CycloneDX format for clients who need continuous SBOM updates |
| Adoption in Highly Regulated Industries | Strong adoption in highly regulated industries | A healthcare provider using digital health applications may use CycloneDX data to monitor dependencies for vulnerabilities actively, ensuring regulatory compliance |
Even when a comprehensive solution like a CNAPP does not generate SBOMs, it can use SBOM data in either format to monitor dependencies in complex dependency trees. The SBOM format matters less for security solutions than the actual data you’ll see stored in these different formats and how useful that data is for an organization’s overall security strategy.
In the case of CycloneDX, that data is more focused on security use cases. Let’s compare to SPDX:
| Feature | SPDX | SPDX Use Case |
| Data Granularity and Depth | Includes origin tracking, legal obligations, terms, restrictions, and provenance data. Allows different licenses for multiple code snippets | A telecommunications company integrating open-source software into proprietary products could use SPDX data to ensure licensing compliance across its portfolio, avoiding IP conflicts |
| Interoperability with Security Tools | Compatible with tools focused on license compliance. Security tool-compatible for core component data | A software company could use SPDX data to perform regular license audits on its open-source components, ensuring compliance before a software release |
| Extensibility and Customization | Somewhat extensible but more rigid in terms of custom security data fields, focusing instead on open-source license specifics | A company with strict compliance standards could use SPDX data to track detailed licensing obligations but might find its limited extensibility a constraint if teams need to add proprietary security metrics |
| Community and Ecosystem Support | Managed by the Linux Foundation, SPDX has extensive support from open-source contributors and large tech companies focused on compliance. Recognized by the ISO | A government contractor developing software with strict compliance requirements could employ SPDX format data to ensure all open-source components meet ISO standards |
| Component Hierarchy and Relationships | Represents basic dependency relationships but doesn’t support multi-layered, in-depth mapping | An enterprise software vendor integrating a few open-source components into its closed-source application could use SPDX for high-level dependency tracking on software with a simple architecture |
| Versioning and Update Frequency | Slower update cycle than CDX for more continuity | A defense contractor that requires stable, well-documented standards for compliance verification uses SPDX, as its slower updates provide a consistent compliance framework suited to long project timelines |
| Adoption in Highly Regulated Industries | Popular in industries that prioritize license and IP management, like telecommunications, automotive, and government sectors. ISO certification adds credibility | A multinational automotive company with a significant open-source footprint in its in-car software uses SPDX-formatted data to ensure all components meet IP requirements |
SPDX format is focused on licensing and compliance. While its data can be read by security software, the type of data this format collects may not be as useful for security goals as the data contained in CDX format. Nevertheless, SPDX is increasingly used in security contexts due to its standardized structure and ISO certification.
Emerging Considerations in SBOM Adoption and Usage
As the adoption of SBOMs expands across industries, new considerations are shaping how organizations select, implement, and utilize these formats. Beyond basic functionality, factors like real-time updates and deeper integration with security and compliance ecosystems are driving innovations in SBOM practices, making them a foundational part of software supply chains.
What else do you need to consider to future-proof your choice of format?
- Real-time SBOMs and Continuously Updated SBOMs
Traditional SBOMs capture a static snapshot of software components, but real-time or continuously updated SBOMs allow organizations to always have an up-to-date view of their software. Both CDX and SPDX support real-time SBOMs, but CDX generally has a smoother path to integration with continuous security monitoring, as its data already aligns with security goals.
- Compatibility with Emerging Security Regulations
Regulations like the Executive Order on Improving the Nation’s Cybersecurity and new EU rules requiring SBOMs for critical software have evolved standards. Both CDX and SPDX are adapting to meet these standards. However, organizations must assess their industry and location to know which regulations they must meet.
- Machine-Readable vs. Human-Readable SBOMs
SPDX famously provides plain-text formats that are easier for humans to parse, but both allow for machine reading (e.g., JSON or XML). Human teams will find SPDX’s YAML option more readable and easier to use.
- Component Provenance
SBOMs are evolving to include provenance and integrity verification. That’s a capability organizations will want if they prioritize supply chain transparency or plan to. Look for formats that support signed components and origin tracking. You’ll need to check how each format approaches provenance (i.e., CDX’s fields to specify author and suppliers vs. SPDX’s digital signatures and cryptographic hash functions) and the depth of features offered.
- SBOM Completeness and Depth of Detail
The level of detail in SBOMs varies, with CDX offering transitive dependencies (dependencies of dependencies). Your needed level of granularity should dictate the complexity of your format. Those with complex applications, third-party software components, and layered dependencies will want more granularity.
As SBOMs become more ubiquitous, they have also become better integrated, with updated security compliance, more automation, and the inclusion of machine learning. Ultimately, they evolve to offer more transparency, efficiency, and security in the software supply chain.
Why Adopt an Organization-Wide Format?
Because, logically, different formats support different goals, it’s natural to ask whether (and why) an organization should adopt a single format. Benefits of a single format include:
- Unified security practices applied organization-wide
- Efficient compliance auditing
- Cross-tool compatibility
- Simplified collaboration
- Scalability
Despite the benefits, there’s no requirement to adopt a single format, and it’s not uncommon to find multi-format organizations. Enterprises with complex needs and multiple teams may require the flexibility that multiple formats afford. They may depend on robust license tracking alongside strong security needs and embrace the benefits of each format independently. They may find it perfectly reasonable to adopt tools that simplify the conversion of one format into another, taking advantage of cross-team collaboration without the need for a uniform format.
Upwind Generates SBOMs at Runtime
Upwind generates SBOMs at runtime, discovering which packets are in use, their dependencies, and any associated vulnerabilities so they can streamline remediation and enhance their security posture. To learn more about how Upwind’s comprehensive CNAPP leverages SBOMs to streamline cloud security incidents like zero-day vulnerability investigations, schedule a demo.
