The CRA SBOM Mandate: How to Build Software Bill of Materials Compliance Into Your CI/CD Pipeline

The EU Cyber Resilience Act (CRA) entered into force on December 10, 2024. Its main obligations apply from December 11, 2027, with vulnerability reporting obligations starting September 11, 2026. At the centre of the CRA's supply chain security requirements sits a deceptively simple mandate: every product with digital elements placed on the EU market must include a Software Bill of Materials (SBOM).

An SBOM is an inventory of every component, library, and dependency in your software — a machine-readable list that answers the question: "What's actually inside this product?" It sounds straightforward. In practice, generating accurate, complete, and continuously updated SBOMs across a complex software supply chain is one of the hardest infrastructure challenges your engineering team will face before 2027.

This article covers exactly what the CRA requires, which SBOM format to use, how to automate generation in your CI/CD pipeline, and how to connect SBOMs to the vulnerability management process that the CRA also mandates.

What the CRA Actually Requires

The CRA's SBOM requirements are found primarily in Annex I, Part II (vulnerability handling requirements) and the supporting recitals. Here's what matters:

• Machine-readable format: The SBOM must be in a structured, machine-readable format — not a PDF, not a spreadsheet. The regulation references established standards without mandating a specific one, but the two viable options are SPDX and CycloneDX
• Component identification: Every component must be identifiable — package name, version, supplier, and unique identifier (typically a Package URL / purl)
• Dependency relationships: Direct and transitive dependencies must be documented. If your application uses library A, which depends on library B, which depends on library C — all three must appear in the SBOM with their relationships mapped
• Continuous updates: The SBOM is not a one-time deliverable. It must be updated with every release that changes the software composition. This implicitly requires automation — manual SBOM maintenance doesn't scale
• Available to market surveillance authorities: SBOMs must be available upon request by national market surveillance authorities and, depending on the product category, may need to accompany the product documentation

SPDX vs. CycloneDX: Which Format?

Two standards dominate the SBOM landscape. Both are machine-readable, both are actively maintained, and both satisfy the CRA's format requirement. The choice matters for tooling compatibility:

SPDX (Software Package Data Exchange)

• Maintainer: Linux Foundation (ISO/IEC 5962:2021)
• Format: JSON, XML, RDF, YAML, tag-value
• Strength: ISO standard, strong licensing metadata, broad ecosystem recognition
• Tooling: Syft, Tern, FOSSology, SPDX tools
• Best for: Organizations that need ISO certification alignment or detailed licensing compliance alongside security

CycloneDX

• Maintainer: OWASP Foundation
• Format: JSON, XML, Protocol Buffers
• Strength: Security-first design, VEX (Vulnerability Exploitability eXchange) integration, lightweight
• Tooling: Syft, Trivy, cdxgen, CycloneDX CLI
• Best for: Organizations prioritizing vulnerability management and security automation

Our recommendation: For CRA compliance, CycloneDX is the more practical choice. Its native VEX support directly maps to the CRA's vulnerability handling requirements, and the OWASP ecosystem provides the most mature security-focused tooling. If you already have SPDX in production, don't switch — both formats satisfy the regulation.

Automating SBOM Generation in CI/CD

The only viable approach for CRA compliance is generating SBOMs automatically as part of your build pipeline. Manual SBOM creation is error-prone at best and fiction at worst. Here's a reference architecture:

Step 1: Generate at Build Time

Use syft (Anchore) or trivy (Aqua Security) to generate an SBOM from your container image or source code during the build stage:

# Generate CycloneDX SBOM from container image
syft packages registry.example.com/myapp:v1.2.3 -o cyclonedx-json > sbom.cdx.json

# Or from source directory
syft dir:. -o cyclonedx-json > sbom.cdx.json

# Or using Trivy
trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/myapp:v1.2.3

Step 2: Validate the SBOM

An invalid SBOM is worse than no SBOM — it creates a false sense of compliance. Validate the generated SBOM against the schema:

# Validate CycloneDX schema
cyclonedx validate --input-file sbom.cdx.json --input-format json

# Check for minimum required fields
# (name, version, supplier for every component)

Step 3: Scan for Vulnerabilities

The CRA requires vulnerability handling throughout the product lifecycle. Use the SBOM to scan for known vulnerabilities:

# Scan SBOM against vulnerability databases
grype sbom:sbom.cdx.json -o json > vulns.json

# Or using Trivy with SBOM input
trivy sbom sbom.cdx.json --format json > vulns.json

Step 4: Generate VEX (Vulnerability Exploitability eXchange)

Not every vulnerability in your dependency tree is actually exploitable in your product. VEX documents let you state which vulnerabilities are applicable, which are mitigated, and which don't affect your product. Under the CRA, you need to demonstrate that known vulnerabilities are assessed and handled — VEX is how you document that assessment:

# Generate VEX document
# Status options: not_affected, affected, fixed, under_investigation
{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "vulnerabilities": [
    {
      "id": "CVE-2026-XXXXX",
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "Vulnerable function is not called in our implementation"
      }
    }
  ]
}

Step 5: Store, Sign, and Distribute

SBOMs must be stored alongside their corresponding releases, digitally signed for integrity, and available to authorities on request:

# Sign SBOM with cosign (Sigstore)
cosign sign-blob --key cosign.key sbom.cdx.json --output-signature sbom.cdx.json.sig

# Store in OCI registry alongside container image
oras attach registry.example.com/myapp:v1.2.3 sbom.cdx.json --artifact-type application/vnd.cyclonedx+json

GitHub Actions Reference Pipeline

Here's a complete SBOM generation and validation pipeline for GitHub Actions:

name: SBOM Generation
on:
  push:
    tags: ['v*']

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build container image
        run: docker build -t myapp:${{ github.ref_name }} .

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: myapp:${{ github.ref_name }}
          format: cyclonedx-json
          output-file: sbom.cdx.json

      - name: Scan for vulnerabilities
        uses: anchore/scan-action@v4
        with:
          sbom: sbom.cdx.json
          fail-build: true
          severity-cutoff: high

      - name: Upload SBOM as release artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json

Kubernetes and Container-Native SBOM

If your products run on Kubernetes (and if you're reading this blog, they probably do), there are additional SBOM considerations:

• Base image components: Your SBOM must include the OS packages in your container base image, not just your application dependencies. syft and trivy handle this automatically when scanning container images
• Helm chart dependencies: If you distribute software as Helm charts, the chart's dependencies (sub-charts, CRDs) should be documented
• Runtime dependencies: Sidecar containers, init containers, and operator-deployed resources are all part of your product's software composition
• Multi-architecture images: If you publish multi-arch images (amd64/arm64), generate SBOMs for each architecture — they may have different OS package versions

For a comprehensive guide to Kubernetes deployment patterns, including the container lifecycle management that feeds into SBOM accuracy, see Kubernetes Recipes — practical patterns for container orchestration that directly apply to CRA-compliant deployments.

SBOM for AI/ML Workloads

AI products face additional SBOM complexity that most guidance overlooks:

• Model dependencies: Python ML environments (PyTorch, TensorFlow, transformers, CUDA libraries) create deep dependency trees with hundreds of transitive packages. Your SBOM tool must resolve these completely
• Model artifacts: While not yet explicitly required by the CRA, best practice is to document model provenance alongside your SBOM: training framework version, dataset lineage, and model card
• GPU driver stack: NVIDIA drivers, CUDA toolkit, cuDNN — these are runtime dependencies that affect your product's security posture and should be documented
• Inference serving frameworks: TensorFlow Serving, Triton, vLLM, Ollama — each brings its own dependency tree into your product

The Timeline: What to Do When

The CRA's phased implementation gives you a clear timeline:

• Now (2026): Implement automated SBOM generation in your CI/CD pipeline. Start with your most critical products. Choose your format (CycloneDX recommended). Deploy vulnerability scanning against SBOMs
• September 11, 2026: Vulnerability reporting obligations begin. You must report actively exploited vulnerabilities to ENISA within 24 hours. Having SBOMs in place is a prerequisite for meeting this timeline — you can't report what you can't identify
• December 11, 2027: Full CRA obligations apply. All products with digital elements on the EU market must have complete, machine-readable SBOMs with vulnerability handling processes in place

Common Mistakes to Avoid

• Generating SBOMs from lockfiles only: Lockfiles capture declared dependencies but miss runtime dependencies, OS packages, and native libraries. Always generate SBOMs from the final container image or built artifact
• Ignoring transitive dependencies: The CRA requires documenting the complete dependency tree. A log4j-style vulnerability in a transitive dependency is just as reportable as one in a direct dependency
• One-time SBOM generation: SBOMs must be updated with every release. If SBOM generation isn't automated in your CI/CD pipeline, it will fall out of date
• No vulnerability correlation: An SBOM without vulnerability scanning is an inventory without a security purpose. The CRA requires both — the SBOM tells you what you have, vulnerability scanning tells you what's at risk
• Treating SBOM as a compliance checkbox: The real value of SBOMs is operational: faster incident response (which components are affected?), better upgrade planning (what depends on this library?), and supply chain risk visibility. Build for value, not just compliance

How Open Empower Helps

As an AI infrastructure partner for regulated enterprises, we integrate SBOM generation and vulnerability management into the platform engineering layer:

• CI/CD pipeline integration: Automated SBOM generation, validation, signing, and storage for every build
• Vulnerability management: Continuous scanning of SBOMs against CVE databases, with VEX documentation workflows
• Kubernetes-native SBOM: Container image, Helm chart, and runtime dependency coverage
• AI/ML-specific coverage: Model dependency trees, GPU driver stacks, and inference framework composition
• CRA compliance mapping: SBOM practices mapped to specific CRA Annex I requirements, ready for market surveillance review

The September 2026 reporting deadline is five months away. The December 2027 full compliance deadline is twenty months away. SBOM automation is not a 2027 project — it's a 2026 project. Start now.