Cyber Resilience Act and Container Images

What the CRA actually is

The Cyber Resilience Act is an EU regulation covering “products with digital elements” — a broad category spanning connected hardware and standalone software sold in the EU. It sets essential cybersecurity requirements that apply across a product's lifecycle: secure-by-design development, a documented approach to handling vulnerabilities, and truthful disclosure to users and regulators when things go wrong. It entered into force in December 2024, with obligations phasing in through 2027. This article covers the general framework only; consult counsel to determine how it applies to your specific product and market.

Where container images fit in

The CRA does not regulate “a container image” as its own category — it regulates the product being placed on the market. But if that product is delivered, deployed, or operated as one or more container images, then every component inside those images — the base OS layer, language runtimes, and application dependencies — is part of what the manufacturer must document and monitor. A microservice shipped as a container is not exempt from the Act just because its packaging format is a tarball rather than an installer.

In practice, this means the base image you choose is not purely a technical decision. An image built on a minimal, actively maintained base carries fewer components to document and monitor than one built on a large, general-purpose distribution. Our comparison of Alpine, Debian, and distroless base images covers that tradeoff directly.

The core obligations, in container terms

Base images, third-party images, and who is responsible

A question that comes up quickly in container contexts: if a vulnerability lives in a public base image you did not author, is that your problem under the CRA? In practice, the manufacturer placing the finished product on the market carries the documentation and vulnerability-handling duty for everything shipped inside it, including a base image pulled from a public registry. The CRA does not distinguish between code you wrote and code you incorporated — it looks at the product as delivered. That is precisely why component-level visibility, not just visibility into your own application code, is the operational requirement here.

This pushes base-image choice from a purely technical decision toward a compliance-relevant one. Fewer components mean less to document, less to monitor, and a smaller number of things that can go out of support upstream without your team noticing. A minimal or distroless base with a small, well-maintained package set is easier to keep in continuous compliance than a large, general-purpose image with hundreds of packages you never directly use.

Why “we patched it once” is not enough

A container image that passed a scan at build time is not necessarily safe six months later. New CVEs are disclosed continuously against packages that have not changed at all, and the CRA's vulnerability-handling duty is framed around the product's supported lifetime, not a single point-in-time check. This is the same reason container images need rescanning on a schedule, independent of whether the application code has changed — the underlying OS packages accumulate newly disclosed vulnerabilities even when nothing in your own repository does.

A practical checklist

• Determine which of your products are “placed on the market” in the EU and therefore in CRA scope — and confirm this determination with counsel.
• Generate an SBOM for every container image build and store it alongside the image.
• Scan every deployed image on a recurring schedule, not only at build time, to catch CVEs disclosed after release.
• Track fix availability for base-image and dependency updates, and have a rebuild cadence rather than an ad-hoc one.
• Be able to answer “are we affected” for a newly disclosed CVE within hours, not days — that speed depends on having current SBOM and scan data on hand already.
• Document the process itself, not just the outputs — the CRA asks for an ongoing vulnerability-handling practice, not a one-time audit.

How ScanRook supports this

ScanRook generates an enriched SBOM with every scan of a container image, and can be run on a recurring schedule against the same image so newly disclosed CVEs surface without waiting for the next code change. Because it queries OSV, NVD, and Red Hat OVAL in parallel, a “are we affected” question can be answered against current data rather than a database snapshot from the last build. Our SBOM guide covers the generation and enrichment pipeline in full, and our container security checklist covers hardening beyond vulnerability scanning alone.

Frequently asked questions