CRA SBOM Requirements 2026: What Art.13 and Annex VII Demand from SaaS Developers

Post #1 in the sota.io EU CRA SBOM Developer Guide Series (2026)

The Cyber Resilience Act (EU 2024/2847) introduces the most comprehensive software supply chain documentation obligation in EU regulatory history. At its core sits a mandate that most SaaS developers have never encountered before: a Software Bill of Materials (SBOM) is now a legal compliance artifact, not an optional engineering practice.

This post is the first in a five-part developer guide series on CRA SBOM compliance. We cover the regulatory foundation — what Art.13, Art.31, and Annex VII actually require — before subsequent posts address format selection, pipeline automation, vulnerability mapping, and long-term retention strategy.

The Regulatory Foundation: Where SBOMs Live in the CRA

The CRA's SBOM obligation flows from three interconnected provisions:

Art.13 — Obligations of Manufacturers establishes the general obligation for manufacturers of products with digital elements to draw up technical documentation before placing a product on the market. Manufacturers must keep this documentation updated throughout the product's supported lifecycle and make it available to market surveillance authorities upon request. The SBOM is part of this mandatory technical documentation.

Art.31 — Technical Documentation specifies that technical documentation must be drawn up in accordance with Annex VII. It must contain all information necessary to assess the conformity of the product and be maintained for at least ten years after the product is placed on the market or after the end of the supported lifecycle, whichever is later.

Annex VII — Technical Documentation Contents enumerates what must be included. Category 4 explicitly requires a Software Bill of Materials listing every software component including open-source libraries, third-party packages, and their respective versions. The Annex does not prescribe a specific SBOM format but requires the list to be sufficient for identifying and assessing known vulnerabilities.

What This Means in Practice

Most enterprise software teams already know their direct dependencies. The CRA requirement extends significantly further:

• Transitive dependencies must be captured — not just the libraries you explicitly import, but every library those libraries import
• Open-source components must be individually listed with version and license information
• Known vulnerability status at time of release must be documentable from the SBOM
• Updates are required — when you patch a dependency, the SBOM must reflect the change with appropriate version tracking

The practical threshold is: if a market surveillance authority asks "what software components are in your product and which CVEs did you know about at release," your SBOM must provide the answer. An incomplete or unmaintained SBOM is a compliance failure.

SBOM Format Selection: CycloneDX vs SPDX

The CRA does not mandate a specific SBOM format, but market guidance from ENISA and the Commission's technical working groups converges on two formats as the expected interchange standards. Understanding their differences determines which toolchain you should adopt.

CycloneDX (OWASP)

CycloneDX is an OWASP-maintained standard designed specifically for security use cases. Current version: 1.6 (backwards-compatible from 1.4+).

Strengths for CRA compliance:

• Native support for VEX (Vulnerability Exploitability eXchange) documents — you can document which CVEs affect your product, which don't, and why, all within the same SBOM ecosystem
• Services inventory component — tracks external APIs and services your product calls, relevant for CRA's scope of "products with digital elements" that depend on cloud services
• Built-in SBOM attestation and signing support for supply chain integrity
• Excellent tooling support: cdxgen, Dependency-Track, OWASP's own reference implementation

Format: Available as JSON, XML, and Protocol Buffers. JSON is preferred for most pipeline integrations.

Best for: Security-first teams, products with significant open-source dependency trees, teams that also need VEX capability for vulnerability disclosure workflows under CRA Art.14.

SPDX (Linux Foundation)

SPDX (Software Package Data Exchange) is an ISO standard (ISO/IEC 5962:2021) primarily designed for license compliance, now extended to cover security use cases. Current version: 2.3 (SPDX 3.0 in development).

Strengths for CRA compliance:

• ISO standard status — directly referenced in public procurement contexts and some national transposition guidance
• Richer license expression syntax — critical for organizations that also need licence compliance tracking alongside security compliance
• Broad tooling support: syft, fossology, spdx-sbom-generator, Tern
• Existing integration in many build tools and registries

Format: Available as tag-value, JSON, YAML, RDF, and spreadsheet. JSON is preferred for pipeline integration.

Best for: Teams with existing SPDX tooling, organizations in procurement chains that require ISO-standard SBOMs, products where license compliance is as important as security compliance.

Which to Choose

For new CRA compliance projects starting in 2026, CycloneDX is the better default for most SaaS developers. The VEX capability aligns directly with Art.14 vulnerability disclosure workflows, and the security-first design philosophy matches the CRA's regulatory intent more closely than SPDX's licence-first origin.

If your organization already has SPDX tooling deployed or operates in procurement contexts requiring ISO standards, SPDX 2.3 is fully sufficient for CRA Annex VII compliance.

Both formats support purl (Package URL) identifiers — the cross-referencing mechanism that links SBOM components to ENISA's EUVDB and the NVD. Purl support is a practical requirement regardless of format choice.

SBOM Generation Tools: Your Pipeline Starting Point

Syft (Anchore) — Best for Container Images

Syft generates SBOMs from container images, filesystems, and source repositories. It supports both CycloneDX and SPDX output.

# Install
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generate CycloneDX SBOM from container image
syft your-app:latest -o cyclonedx-json=sbom.cyclonedx.json

# Generate SPDX SBOM from source directory
syft dir:./src -o spdx-json=sbom.spdx.json

Syft excels at container image analysis because it reads layer-by-layer and can detect OS packages (apt, rpm, apk) alongside language-level packages (npm, pip, go modules, Maven). This matters for CRA compliance because your container's base image dependencies are also your dependencies under Annex VII.

cdxgen (AppThreat) — Best for Application Code

cdxgen is purpose-built for application-level SBOM generation and has native support for most language ecosystems: Node.js, Python, Java/Maven, Go, Rust, .NET, Ruby, PHP, and more.

# Install
npm install -g @cyclonedx/cdxgen

# Generate SBOM for a Node.js project
cdxgen -t nodejs -o sbom.json .

# Generate SBOM for a multi-language monorepo
cdxgen -t python,nodejs -o sbom.json .

cdxgen produces CycloneDX output by default and handles transitive dependencies better than most alternatives for application-level packages. It integrates directly with package managers (npm, pip, Maven, Cargo) to enumerate the full dependency tree, including development dependencies that you may need to exclude explicitly.

FOSSology — Best for License Analysis + SBOM

FOSSology is an open-source licence compliance and SBOM tool from the Linux Foundation. It's the right choice when licence compliance and security compliance must be tracked together.

# Docker deployment (recommended)
docker run -p 8081:80 fossology/fossology

# Then upload your source and generate SPDX report via web UI
# or use the REST API for CI/CD integration

FOSSology performs deep source code scanning for copyright notices and licence identifiers, which is valuable for open-source-heavy products where the licence compliance obligation is as significant as the CRA obligation.

CI/CD Integration: Making SBOM Generation Automatic

The ten-year retention obligation under Art.31 is unenforceable without automated SBOM generation. Manually-created SBOMs drift from the actual deployed software within days of the first dependency update. The only compliant approach is treating SBOM generation as a mandatory build step.

GitHub Actions Example

name: Build and Generate SBOM
on:
  push:
    branches: [main]
  release:
    types: [created]

jobs:
  build-and-sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build container image
        run: docker build -t myapp:${{ github.sha }} .
      
      - name: Install Syft
        run: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
      
      - name: Generate CycloneDX SBOM
        run: |
          syft myapp:${{ github.sha }} \
            -o cyclonedx-json=sbom-${{ github.sha }}.cyclonedx.json
      
      - name: Verify SBOM completeness
        run: |
          COMPONENT_COUNT=$(jq '.components | length' sbom-${{ github.sha }}.cyclonedx.json)
          echo "SBOM contains ${COMPONENT_COUNT} components"
          [ "$COMPONENT_COUNT" -gt 10 ] || (echo "SBOM too small — check generation" && exit 1)
      
      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.sha }}
          path: sbom-${{ github.sha }}.cyclonedx.json
          retention-days: 3650  # ~10 years — matches CRA Art.31 retention

The retention-days: 3650 in the GitHub Actions artifact upload directly addresses the Art.31 ten-year retention requirement for the SBOM generated at each release. In practice, you also need external archival for releases older than GitHub's artifact retention limits, but this provides the immediate compliance signal.

GitLab CI Example

sbom:
  stage: build
  image: anchore/syft:latest
  script:
    - syft ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA} -o cyclonedx-json=sbom.json
    - jq '.components | length' sbom.json
  artifacts:
    paths:
      - sbom.json
    expire_in: never  # CRA Art.31 — retain for product lifetime
  only:
    - main
    - tags

The SBOM Availability Obligation

Beyond generation and retention, Art.13 includes an obligation for manufacturers to make the SBOM available to users and competent authorities. The practical implementation of this obligation requires decisions most teams have not yet made:

Who can request an SBOM? Market surveillance authorities (MSAs) have a statutory right to request technical documentation including the SBOM. Large enterprise customers frequently request SBOMs as part of procurement due diligence. Security researchers may request SBOMs to assess vulnerability exposure. Your SBOM availability workflow must handle all three categories.

How quickly must you respond? The CRA does not specify a statutory SBOM response time, but MSA requests come with their own procedural timelines. A practical target is 72 hours for a current-version SBOM and two weeks for historical versions from the retention archive.

What format? For MSA requests, machine-readable CycloneDX or SPDX is appropriate. For enterprise customer requests, a machine-readable format plus a human-readable summary (PDF or spreadsheet) reduces friction.

What if you use EU hosting? This is where cloud provider jurisdiction matters directly. If your SBOM references third-party components hosted on US infrastructure, a National Security Letter to your cloud provider could theoretically silently modify those components without your knowledge. EU-hosted infrastructure — where no such extra-territorial instrument applies — provides a structural advantage for maintaining SBOM integrity that no process control can replicate from US-hosted infrastructure.

What Comes Next in This Series

This post established the regulatory foundation. The next four posts in the EU CRA SBOM Developer Guide series address:

• Post #2 — CycloneDX vs SPDX deep dive: field-by-field format comparison with CRA compliance requirements mapped to each field
• Post #3 — CI/CD SBOM automation: production-grade pipeline patterns for GitHub Actions, GitLab CI, and Jenkins with vulnerability scanning integration
• Post #4 — Vulnerability mapping: cross-referencing your CRA SBOM against ENISA EUVDB, NVD, and OSV with automated alerting
• Post #5 — 10-year SBOM retention: immutable archival strategy, version history management, and MSA request response playbook

The December 2027 enforcement deadline creates a false sense of urgency absence. Building SBOM generation into your pipeline takes three to six months to stabilize in a production environment. Starting now is not early — it is on-time for a December 2027 deadline that requires operational readiness, not just tooling installation.

sota.io runs on EU infrastructure exclusively. Our platform provides the jurisdictional separation that makes CRA SBOM integrity guarantees meaningful — your build pipeline and SBOM archive cannot be silently modified by extra-territorial legal instruments targeting US cloud providers. Explore EU-native hosting for CRA compliance →