What the EU Cyber Resilience Act's SBOM Requirement Actually Means If You Ship Containers to the Cloud

Key points:

• The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Article 14 reporting of actively exploited vulnerabilities applies from 11 September 2026, and everything else, including the SBOM, applies from 11 December 2027 (Article 71).
• The legal minimum is narrower than most teams assume. Annex I Part II requires an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products". You do not have to publish it. It sits in your technical documentation and goes to market surveillance authorities on request.
• Pure multi-tenant SaaS is largely out of scope and falls under NIS2. If you ship container images, Helm charts, agents, CLIs, firmware, or a self-hosted edition, you are a manufacturer and the SBOM applies.
• The container answer: pin the base image by digest, generate an SPDX or CycloneDX SBOM in the build, sign it and attach it to the image digest as an attestation, then keep it retrievable for 10 years or the support period, whichever is longer.
• Your hyperscaler covers none of it. AWS, GCP, Azure, and Scaleway secure the infrastructure and the managed control plane. Your image, its SBOM, its VEX statements, and the 24-hour ENISA early warning stay with you. Breaching Annex I, Article 13, or Article 14 can cost up to EUR 15 million or 2.5% of worldwide annual turnover.

Most container teams I talk to have heard "the CRA needs an SBOM" and guessed the rest. Some think they must publish their full dependency tree. Others think AWS or GCP covers them. Both are wrong, and every claim below is anchored to an article of the regulation. This is engineering guidance, not legal advice.

What exactly does the EU Cyber Resilience Act require in terms of SBOM?

The CRA requires manufacturers to draw up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies of the product, keep it in the technical documentation, and hand it to market surveillance authorities on request. That obligation applies from 11 December 2027 (Regulation (EU) 2024/2847).

The operative text is Annex I, Part II, point (1). Manufacturers shall:

You do not have to publish the SBOM. Recital 77 says it outright: "Manufacturers should not be obliged to make the SBOM public." Annex VII point 2(b) puts the SBOM in your technical documentation, and Annex VII point 8 makes it available "further to a reasoned request from a market surveillance authority". If you choose to share it with users, Annex II point 9 asks you to say where they can find it. Enterprise buyers will still ask for it in procurement, and you will probably say yes, but that is a contract, not the law.

"Top-level dependencies" is the floor, not the ceiling. The law only demands your direct dependencies. Every serious generator gives you the full transitive tree for free, and the full tree is what lets you answer "are we affected?" in minutes. Treat the floor as academic.

The format is open. The text never defines "commonly used". In practice that means SPDX (ISO/IEC 5962:2021) or CycloneDX (ECMA-424). Article 13(24) lets the Commission specify the SBOM's format and elements through an implementing act. Until one is adopted, nobody can tell you the mandatory fields, so pick one of those two and don't overthink it.

Three more numbers to know:

• Retention: technical documentation stays available for "at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer" (Article 13(13)).
• Support period: at least five years, unless you expect the product to be in use for less (Article 13(8)).
• Fines: up to EUR 15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher, for breaching Annex I or Articles 13 and 14 (Article 64(2)).

Does the CRA apply to me if I only ship containers and run a SaaS?

If customers only consume your software as a hosted multi-tenant service, the CRA mostly does not apply and NIS2 does instead. The CRA applies the moment you hand a customer something they run themselves: a container image, a Helm chart, a self-hosted edition, an agent, a CLI, or an appliance.

Recital 12 is explicit that Directive (EU) 2022/2555 (NIS2) covers "Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS)". The exception is remote data processing (Article 3(2)): a backend you build for your product, without which the product can't do its job. If your installed agent can't work without your cloud API, that API is part of the product.

A manufacturer (Article 3(13)) is anyone who develops a product and "markets them under its name or trademark, whether for payment, monetisation or free of charge". Company size and headquarters don't matter. Placing the product on the EU market is what triggers it.

For open source, watch the monetisation line: Recital 15 treats paid support beyond cost recovery or donations above costs as commercial activity. And even out of scope, the SBOM reaches you, because in-scope buyers must document their components and will ask you for one well before December 2027.

What does a CRA-compliant SBOM for a container image actually look like?

A container SBOM is a machine-readable SPDX or CycloneDX inventory of every package in the image layers, generated at build time and bound to the image digest. That covers OS packages, language dependencies, and your own artifact. A spreadsheet maintained by hand does not count.

It must list base image OS packages (apk, deb, rpm), language dependencies (npm, pip, Maven, Go modules, Cargo), and your own artifact, each with a package URL (purl) and licence.

The detection gap is real. A binary fetched with curl in a RUN line, a static Go binary copied from a builder stage, or a vendored tarball often carries no package metadata, so scanners miss it. That is the main reason generated SBOMs come out incomplete.

Generate at build time. That is the only moment you see the resolved dependency graph, the build inputs, and the base image digest together.

Bind it to the digest. Attach the SBOM as an in-toto attestation through the OCI referrers API and sign it with Cosign. A tag moves. A digest does not.

Pair it with VEX. OpenVEX or CycloneDX VEX statements say which listed CVEs actually affect your product. Without VEX, a thorough SBOM mostly hands your customers false positives.

This connects straight to Article 14. For an actively exploited vulnerability, you owe the coordinating CSIRT and ENISA an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report no later than 14 days after a fix or mitigation is available (Article 14(2)). Log4Shell made the case years ago: teams with an SBOM index queried a purl across every deployed digest and had an answer the same day, while everyone else grepped Dockerfiles for a week.

The scale makes this necessary. Black Duck's 2026 OSSRA report found open source in 98% of the 947 commercial codebases it audited, and at least one open-source vulnerability in 87%.

Which tools generate and store container SBOMs, and how do they compare?

Generating a container SBOM is solved: Syft, Trivy, and docker buildx build --sbom=true each do it in one command. The hard parts are signing it, binding it to the digest, and finding it again for an image you shipped three years ago.

Close the loop at admission: Kyverno verifyImages, or OPA Gatekeeper with a verifier such as Ratify, rejects pods without a valid signed attestation. Shrink what you document with Chainguard Images, Google distroless, or Alpine. And index SBOMs by digest in storage you will still own in ten years. A registry you might migrate off is not an archive.

Does running on AWS, GCP, Azure, or Scaleway cover any of the CRA SBOM obligation?

No. The cloud provider secures the infrastructure and the managed control plane, but the CRA obligation attaches to the product you place on the market. Your image, your dependencies, your SBOM, your VEX, and your ENISA reporting stay with you.

The providers say so themselves. AWS states it manages the EKS control plane while the customer is "largely responsible" for workloads, pod security, and image security (EKS best practices). Google says customers must "maintain your workloads, including your application code, build files, container images, data" (GKE shared responsibility). AKS and Scaleway Kapsule draw the same line.

In CRA terms the provider supplies a component and you are the manufacturer. If a managed database, queue, or model endpoint is part of your product's remote data processing, list it as a dependency and keep the provider's attestations on file. Market surveillance authorities ask the manufacturer, not the host.

The obligation is identical on AWS, GCP, Azure, Scaleway, or your own Kubernetes cluster, so standardise the SBOM step in CI rather than per cloud. Running in your own account in an EU region also keeps artifacts and audit trail under your own contracts.

How do I build SBOM generation into a CI/CD pipeline without slowing teams down?

Treat the SBOM as a build artifact: generate it in the same job that builds the image, sign it and attach it to the digest, and gate only on policy engineering has agreed to. Done this way it adds seconds to a build, not weeks to a roadmap.

The order: pin the base image by digest, build, generate the SBOM, sign and attach it to the digest, push. CVE scanning and VEX triage run downstream of the build.

• Agree the gate up front. Block on critical and high CVEs with a fix available, warn on the rest. Gates that block on unfixable CVEs teach engineers to bypass them.
• Shrink before you scan. A few golden base images remove more packages than any tool finds.
• One build path for every environment. If preview and staging build differently from production, your SBOM describes an artifact nobody ran.
• One owner. In a 20-50 person org with no security or platform engineer, the team that owns the build pipeline owns this, with one shared pipeline rather than one per squad.

That is where Qovery fits. Qovery runs Kubernetes for you inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, and every service goes through the same build-and-deploy path and the same registry in your account. Git-push deployments, per-pull-request preview environments, and environment auto-stop all use that one path, so the artifact inventory stays consistent across environments. Qovery does not replace your SBOM generator. It removes the drift that makes a per-digest SBOM trail best-effort, without a dedicated DevOps engineer.

What is a realistic CRA readiness checklist and timeline for an engineering team?

Work backwards from two dates: by 11 September 2026 you must answer "are we affected and who do we notify?" within 24 hours, and by 11 December 2027 every release artifact needs an SBOM plus full technical documentation and a conformity path. In practice the SBOM inventory has to exist before the first date, because it is what makes the 24-hour window possible.

• By September 2026: deployed-artifact inventory, named reporting contact, tested Article 14 runbook, coordinated vulnerability disclosure policy with a public security contact
• Base image policy and digest pinning
• Build-time SBOM, signed and attached to the digest, verified at admission
• CVE triage with VEX
• 10-year retention plan, indexed by digest
• SBOM requests sent to your own suppliers (procurement moves slower than CI)
• By December 2027: Annex VII technical documentation, conformity route, CE marking, declared support period

On the conformity route (Article 32): default products can self-assess. Annex III's 19 class I categories self-assess only if they apply harmonised standards, its 4 class II categories (container runtimes and hypervisors among them) need third-party assessment, and Annex IV's 3 critical categories need certification or a notified body.

The pitfalls I see most: the SBOM as a one-off PDF, SBOMs keyed by tag, assuming the host covers you, assuming open source means exempt, and ignoring the rest of Annex I Part II. Vulnerability handling and secure updates are the harder half.

On proportionality: microenterprises and small enterprises can't be fined for missing the 24-hour early warning deadline (Article 64(10)(a)), and Article 33(5) lets them file the technical documentation in a simplified format the Commission will define by implementing act. The Annex I essential requirements still apply in full.

How do I set this up from Claude Code or Cursor with Qovery?

Install the Qovery Agent Skills once, add the Qovery MCP Server, and ask your agent in plain language to give each service one standardised build-and-deploy path in your own cloud account.

curl -fsSL https://skill.qovery.com/install.sh | bash
# ...or scoped to the current project
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Qovery MCP Server for Claude Code: OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
# Write access, only when you want it (also enable it in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) set up and deploy. The MCP Server operates what already exists. Every write action asks for your approval first. Then ask: "Deploy this service to my AWS account with Qovery and give every pull request a preview environment."

Docs: AI agent quickstart and Claude Code integration.