SBOM Requirements Under the EU Cyber Resilience Act: A Practical Guide

The Software Bill of Materials (SBOM) has become a cornerstone of modern software supply chain security. Under the EU Cyber Resilience Act (CRA), SBOMs are not just a best practice; they're a regulatory requirement. This guide explains what manufacturers need to know about SBOM compliance under the CRA.

What the CRA Says About SBOMs

The CRA references SBOMs in several key areas:

Annex I: Essential Requirements

"Manufacturers shall identify and document vulnerabilities and components contained in products, including by drawing up a software bill of materials in a commonly used and machine-readable format."

This means:

• SBOMs are mandatory, not optional
• They must be in machine-readable format (not PDFs or spreadsheets)
• They must cover all components, including transitive dependencies

Annex VII: Technical Documentation

The technical file must include SBOM information that enables:

• Component-level vulnerability tracking
• Supplier identification
• License compliance verification
• End-of-life planning

Accepted SBOM Formats

The CRA requires "commonly used and machine-readable" formats. In practice, this means:

Both formats are accepted, but CycloneDX is increasingly preferred for security use cases due to its native support for:

• Vulnerability Exploitability eXchange (VEX)
• Security advisories
• Dependency graphs

BSI TR-03183: The German Standard

Germany's Federal Office for Information Security (BSI) has published TR-03183, which provides detailed SBOM quality requirements that go beyond the CRA minimum. Key requirements include:

Mandatory Fields

• Component name and version
• Supplier/manufacturer information
• Unique identifiers (PURL, CPE)
• Dependency relationships
• License information

Quality Indicators

TR-03183 defines quality levels:

While TR-03183 is a German standard, it's becoming the de facto quality benchmark for CRA compliance across the EU.

Common SBOM Mistakes to Avoid

1. Incomplete Dependency Trees

Many tools only capture direct dependencies. The CRA requires transitive dependencies, meaning components that your dependencies depend on.

Your Product
├── Library A (direct) ✓
│   ├── Library B (transitive) ← Often missing!
│   └── Library C (transitive) ← Often missing!
└── Library D (direct) ✓

2. Missing Version Information

An SBOM without accurate version information is nearly useless for vulnerability matching. Ensure every component has:

• Exact version numbers (not ranges)
• Hash values for binary components
• PURL identifiers where possible

3. Stale SBOMs

An SBOM generated at build time but never updated creates a false sense of security. Implement:

• CI/CD integration for automatic SBOM generation
• Version control for SBOM artifacts
• Regular drift detection between builds

4. Ignoring Firmware and Hardware

For products with embedded components, remember to include:

• Firmware versions and components
• Hardware Bill of Materials (HBOM) where applicable
• Bootloader and kernel components

SBOM Lifecycle Management

A compliant SBOM practice requires ongoing management:

Generation

Source Code → Build System → SBOM Generation → Validation

Integrate SBOM generation into your CI/CD pipeline using tools like:

• Syft (CycloneDX/SPDX)
• Trivy (CycloneDX)
• cdxgen (CycloneDX)

Validation

Before publishing, validate your SBOM:

• Schema compliance (valid CycloneDX/SPDX)
• Completeness (all components included)
• Accuracy (versions match reality)

Storage and Access

SBOMs should be:

• Stored securely with access controls
• Retained for the product support period (minimum 5 years under CRA)
• Accessible for conformity assessment
• Available to downstream customers (for B2B products)

Continuous Monitoring

Link your SBOM to vulnerability databases:

• NVD (National Vulnerability Database)
• OSV (Open Source Vulnerabilities)
• GitHub Advisory Database
• CISA KEV (Known Exploited Vulnerabilities)

Practical Steps to Get Started

1. Audit your current state: Do you generate SBOMs today? What format? What coverage?

2. Choose your format: CycloneDX for security focus, SPDX for license compliance (or both)

3. Automate generation: Integrate into CI/CD, not manual processes

4. Validate quality: Check against TR-03183 requirements

5. Implement monitoring: Link SBOMs to vulnerability scanning

6. Plan for updates: Establish processes for SBOM maintenance

How CRA Evidence Helps

CRA Evidence provides comprehensive SBOM management:

• Upload & Validation: Support for CycloneDX and SPDX with TR-03183 quality scoring
• Vulnerability Scanning: Automatic matching against NVD, OSV, and other databases
• Version Tracking: SBOM history and drift detection across product versions
• Export: Include validated SBOMs in your Annex VII technical file

Getting your SBOM practice right is foundational to CRA compliance. Start building these capabilities now to be ready for the 2027 deadline.

Related Guides

Generation: Learn how to automate SBOM creation in our SBOM generation guide.

Quality: Understand SBOM quality requirements in our BSI TR-03183 guide.

VEX: Pair your SBOM with vulnerability data using VEX documents.

Technical File: See how SBOMs fit into the CRA technical file (Annex VII).

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.