Firmware Sboms Spdx Cyclonedx 2026

title: "Firmware SBOMs in 2026: SPDX vs CycloneDX, What to Publish, and What to Automate" description: "Practical comparison of SPDX and CycloneDX for firmware SBOMs, covering what to include, automation approaches, tooling, and publication strategies for embedded Linux products." date: 2026-04-19T08:00:00Z lastmod: 2026-04-19T08:00:00Z draft: false hero: "/images/hero/firmware-sboms-spdx-cyclonedx-2026-1600x900.jpg" tags:

• Embedded Linux
• ProteanOS
• SBOMs category: dev-pkg

Firmware SBOMs (Software Bills of Materials) have moved from "nice to have" to "required by regulation" in 2026. The EU Cyber Resilience Act mandates them. US Executive Order 14028 expects them. Customer procurement teams ask for them. The practical question is no longer "should we produce SBOMs?" but "which format, what content, and how do we automate it?"

SPDX vs CycloneDX: format comparison

Both are valid, widely adopted SBOM formats. The choice depends on your ecosystem and use case.

SPDX

SPDX (Software Package Data Exchange) is an ISO/IEC standard (ISO/IEC 5962:2021). It originated in the Linux Foundation and is deeply integrated with the open-source licensing ecosystem.

Strengths:

• ISO standard status provides regulatory acceptance
• Rich license expression support (SPDX license identifiers are the industry standard)
• SPDX 3.0 includes security (VEX), build, and AI profiles
• Yocto generates SPDX natively
• Deep integration with Linux kernel and open-source compliance workflows

Format options: Tag-value, JSON, JSON-LD (SPDX 3.0), RDF/XML

CycloneDX

CycloneDX is an OWASP standard focused on security use cases. It originated in the application security community and has strong integration with vulnerability scanning tools.

Strengths:

• Designed for security workflows (VEX, vulnerability references, services)
• Simpler schema for common use cases
• Strong tooling ecosystem (Grype, Syft, Trivy)
• XML and JSON formats with clear schemas
• Good support for hardware component inventory (BOM for devices)

Format options: XML, JSON, Protocol Buffers

Comparison matrix

Both formats satisfy regulatory requirements. Choose based on your toolchain and downstream consumers.

What to include in a firmware SBOM

Minimum (regulatory compliance)

• All open-source packages with versions
• License information per package
• Supplier (upstream project) for each package
• The firmware image as the top-level component
• Dependency relationships

Recommended (useful for security)

Everything above, plus:

• File-level checksums for key binaries
• Build tool versions (GCC, binutils, kernel version)
• Known vulnerability status (or reference to VEX document)
• Source repository URLs for each package

Advanced (full supply chain transparency)

Everything above, plus:

• Build configuration (compiler flags, enabled features)
• Link to SLSA provenance document
• Transitive dependency tree (not just direct dependencies)
• Patch metadata (which upstream patches were applied)

Automation approaches

From Yocto

Yocto generates SPDX documents as part of the build process. Enable it in local.conf:

INHERIT += "create-spdx"

This produces per-package and per-image SPDX documents in the build output directory. Yocto 5.2 generates SPDX 3.0 by default. See the Yocto 5.2 highlights for details.

From Buildroot

Buildroot's make legal-info generates a package list with versions, licenses, and source URIs. Convert this to SPDX or CycloneDX with a post-processing script:

make legal-info
python3 scripts/br2spdx.py output/legal-info/ > sbom.spdx.json

From container/image scanning

Tools like Syft can scan a filesystem or container image and generate an SBOM:

syft dir:output/rootfs -o spdx-json > sbom.spdx.json
syft dir:output/rootfs -o cyclonedx-json > sbom.cdx.json

This works for any build system but misses build-time-only dependencies and configuration details.

From ProteanOS

ProteanOS package metadata includes the information needed for SBOM generation. The packaging system records component names, versions, licenses, and upstream sources in control files. The ProKit build tools can aggregate this into SPDX or CycloneDX documents.

Publication strategies

Embed in firmware

Include the SBOM in the firmware image itself, accessible via a well-known path (e.g., /usr/share/sbom/). This ensures the SBOM always accompanies the firmware.

Publish alongside releases

Host SBOMs on your release infrastructure, named to match the firmware version:

firmware-v2.1.0.bin
firmware-v2.1.0.spdx.json
firmware-v2.1.0.vex.json

API access

For fleet-managed devices, provide SBOM access through a device management API. This allows automated compliance scanning across your deployed fleet.

Validation

Before publishing, validate your SBOM:

SPDX validation

# Using SPDX tools
pyspdxtools -i sbom.spdx.json

Check for:

• Valid SPDX license expressions
• All required fields present
• Consistent package identifiers
• Correct relationship types

CycloneDX validation

# Using CycloneDX CLI
cyclonedx validate --input-file sbom.cdx.json

Content validation

Automated validation catches format errors but not content errors. Manual checks:

• Are all packages in the firmware represented in the SBOM?
• Are versions accurate (not just "latest")?
• Are licenses correct (not just "unknown")?
• Does the dependency tree match the actual build?

Maintaining SBOMs over time

An SBOM is a snapshot. Maintain them by:

1. Generating fresh SBOMs with every release: Automated in CI.
2. Storing historical SBOMs: Keep them for the product's support lifetime (5+ years for CRA).
3. Monitoring for new vulnerabilities: Run vulnerability scans against published SBOMs periodically.
4. Updating VEX statements: When new CVEs are published, update VEX documents. The VEX guide covers this workflow.

Integration with the broader compliance stack

SBOMs are one piece of the compliance puzzle:

• SBOM → What is in the firmware?
• VEX → Which vulnerabilities apply?
• Provenance → How was it built? (SLSA guide)
• Evidence pack → Complete compliance documentation (CRA guide)

Together, these artifacts provide full supply chain transparency for your firmware.

The SPDX 3.0 specification covers the specifics of SPDX 3.0's package and relationship model for embedded Linux images.

Summary

Produce SBOMs for every firmware release. Choose SPDX if your ecosystem is Yocto-centric and license-focused. Choose CycloneDX if your ecosystem is security-tool-centric. Automate generation in CI, validate before publication, and maintain historical SBOMs for the product's lifetime. The tooling is mature enough that SBOM generation should be a five-minute addition to your CI pipeline, not a multi-week project.