At a Glance

• The EU Cyber Resilience Act treats products with digital elements as regulated goods, shifting security duty to the manufacturer.
• Container images are in scope: a vulnerable image shipped to customers is a product with a defect.
• Core duties are secure-by-design, vulnerability handling, SBOM generation, and coordinated vulnerability disclosure.
• ENISA supports implementation, NIS 2 overlaps on critical-sector operators, and SBOM, VEX, and SLSA provide the evidence backbone.
• The timeline phases obligations in from 2026, with the fullest duties applying as transition periods end.
• RapidFort maps directly: RapidFort Analyzer produces the SBOM, RapidFort Optimizer drives near-zero CVE images, and RapidFort CART emits audit-ready conformity evidence in JSON, CSV, HTML, and XML.

The EU Cyber Resilience Act makes container images a regulated product. Under the CRA, unremediated vulnerabilities in shipped images are product defects, so software makers must generate SBOMs, handle flaws quickly, and keep conformity evidence. This guide explains the obligations and how to meet them with SBOM, VEX, and continuous validation.

What Is the EU Cyber Resilience Act and Who Must Comply?

The EU Cyber Resilience Act (CRA) is EU regulation that places cybersecurity obligations on the makers and distributors of products with digital elements. It closes a long-standing gap: most software reached the market with no binding duty to stay secure after sale. The CRA changes that by treating insecure software as a defective product under EU law.

Any economic operator that places a product with digital elements on the EU market is potentially in scope. That includes manufacturers of software products such as container images, importers and distributors, and authorized representatives for non-EU manufacturers. The threshold is simple: if a product has software or connects to a network, it is a product with digital elements. Container images used to run workloads clearly meet that test. Lower-risk products can follow self-assessment, while higher-risk products require third-party conformity assessment, but the security obligations apply to all in-scope products.

Why Do Container Images Fall Under the CRA?

Container images are the unit of software delivery for a large share of modern applications. Under the CRA, the image is the product. If it contains unremediated vulnerabilities, those flaws are product defects, not operational hygiene issues. This reframes how engineering and legal teams treat the image supply chain.

Consider a team that builds an application image from a Debian base, adds a language runtime, and ships it to EU customers. A scanner flags dozens of CVEs in the base and runtime layers. Under the old model, those CVEs sit in a backlog. Under the CRA, an unhandled critical or high vulnerability is a known defect in a product on the market, and the manufacturer owes a duty to address it within a defined timeframe.

The regulation also targets image composition. An image pulls in transitive dependencies, package managers, and shared libraries the vendor may not have written. The CRA does not excuse that inherited risk. It expects the manufacturer to know what is in the product (SBOM) and to manage the flaws that ship with it (vulnerability handling and VEX).

What Security Obligations Does the CRA Place on Software Makers?

The CRA organizes obligations into a few practical buckets that map cleanly onto engineering controls:

• Secure-by-design and secure-by-default: minimize installed content, remove unused packages, and ship the smallest workable runtime.
• Vulnerability handling: address flaws without delay, provide security updates, and document a coordinated vulnerability disclosure process. Critical and high severity flaws carry tight remediation windows.
• SBOM and transparency: accompany the product with a machine-readable inventory of every package, library, and dependency in the image.
• Coordinated vulnerability disclosure: publish a policy for receiving and handling vulnerability reports, including a contact point and a triage process.
• Conformity assessment and marking: perform conformity assessment, draw up a declaration, and affix the CE (Conformité Européenne) marking where required, retaining evidence of the controls applied.

These are process obligations as much as technical ones. A team that can show an SBOM, a remediation cadence, a disclosure policy, and retained evidence is in a far stronger position than one that scans occasionally.

When Does the CRA Take Effect?

The CRA follows a phased timeline. Reporting duties for manufacturers of products with digital elements begin first, creating a channel for vulnerability intake. The fuller product obligations - conformity assessment, SBOM, and vulnerability handling - phase in over the following months as transition periods expire. You can find the CRA timeline at the Cyber Resilience Act - Implementation site.

The time to act is now. Building an SBOM pipeline, a remediation workflow, and an evidence archive takes longer than the compliance window suggests. Because the regulation is EU law, its reach extends to non-EU vendors that sell into the EU market. A software company shipping container images to EU customers is still an economic operator under the CRA and owes the same duties.

How Does the CRA Relate to NIS 2, ENISA, and SBOM Standards?

The CRA interoperates with adjacent frameworks, and understanding the relationships reduces duplicate work. NIS 2 raises security obligations for essential and important entities in critical sectors; an SBOM and vulnerability-handling evidence produced for the CRA also supports NIS 2 supply-chain assurance. ENISA, the EU Agency for Cybersecurity, supports implementation and informs how the technical duties are interpreted.

SBOM is the connective tissue: formats like CycloneDX and SPDX make the image inventory machine-readable and portable. VEX, the Vulnerability Exploitability eXchange, explains whether a known vulnerability in the SBOM actually affects the product - it lets the manufacturer state which flaws are exploitable, which are not, and what mitigation applies. SLSA, the Supply-chain Levels for Software Artifacts framework, describes provenance and build integrity and strengthens the conformity evidence a manufacturer can show. Together these standards turn a vague "be secure" duty into an operational checklist: inventory, justify, prove provenance, disclose, and validate.

How Can You Produce CRA-Ready Conformity Evidence?

Conformity evidence is what an auditor or regulator will ask for. A mature evidence package contains a current SBOM for every shipped image, a VEX covering known CVEs and their status, records of remediation actions with dates and versions, a coordinated vulnerability disclosure policy, validation reports against secure configuration baselines, and an audit-ready export retained for the required period.

The mistake teams make is generating evidence once, by hand, at audit time. The CRA expects ongoing duty, so evidence should be produced continuously, attached to each build, and archived automatically. Export formats matter too: JSON suits pipelines, CSV suits spreadsheets, HTML suits human review, and XML suits legacy GRC systems. A tool that emits all four removes friction at the point of assessment.

What Does a CRA-Compliant Container Workflow Look Like?

A practical, CRA-aligned workflow has five stages, each tied to a duty:

1. Inventory at build. Every image build emits an SBOM automatically. No image ships without one. This satisfies the transparency and SBOM duty.
2. Analyze and prioritize. The SBOM is checked against vulnerability feeds with exploit-awareness, so the team fixes what is actually exploitable. This supports the vulnerability-handling duty.
3. Harden the image. Unused packages and unnecessary services are removed, driving the image toward near-zero CVE. This satisfies secure-by-design.
4. Document and justify. For each remaining CVE, a VEX statement records its status: fixed, mitigated, not affected, or under review.
5. Validate and retain. A continuous check confirms the image meets secure configuration baselines and produces audit-ready evidence in JSON, CSV, HTML, and XML, archived per build.

Mapped to RapidFort, this workflow runs as: RapidFort Analyzer generates the deep image SBOM and applicability analysis; RapidFort Optimizer rebuilds hardened, near-zero CVE drop-in images every 24 hours; and RapidFort CART performs continuous compliance validation against OpenSCAP baselines (STIG, CIS, NIST, custom) and emits the audit-ready evidence in JSON, CSV, HTML, and XML the CRA conformity file requires. RapidFort Curated near-zero CVE images - tens of thousands of hardened images across Alpine, Debian, UBI, and Ubuntu LTS, including STIG and FIPS variants - provide a ready starting point that already minimizes inherited risk. RapidFort Curated Libraries provide a catalog of malware-scanned open-source libraries to help organizations prevent supply chain malware before it reaches development pipelines or production environments.

FAQ

What products are in scope of the EU Cyber Resilience Act?

Any product with digital elements placed on the EU market is potentially in scope. Container images are products with digital elements because they contain software and often connect to networks. Both EU and non-EU vendors that sell into the EU owe the CRA's duties.

Does the CRA require an SBOM for every container image?

The CRA requires manufacturers to provide information about a product's components and to support vulnerability handling. In practice, a machine-readable SBOM (such as CycloneDX or SPDX) is the expected mechanism for container images, because it is the only scalable way to inventory components and track flaws.

What is a VEX and why does the CRA care about it?

VEX stands for Vulnerability Exploitability eXchange. It is a document that states whether a known vulnerability in your SBOM actually affects your product, and what mitigation applies. The CRA's vulnerability-handling duty expects you to address or justify every flaw, and a VEX is how you record that decision for auditors.

How does the CRA's vulnerability handling duty affect image CVEs?

Under the CRA, an unremediated critical or high CVE in a shipped image is a known product defect. Manufacturers must fix it within a tight window, provide updates, or formally justify why it is not exploitable via a VEX. Backlogs of untouched CVEs are no longer acceptable for in-scope products.

How can RapidFort help with CRA conformity evidence?

RapidFort produces the three artifacts the CRA centers on. RapidFort Analyzer generates the SBOM and applicability analysis, RapidFort Optimizer drives near-zero CVE drop-in images through runtime-aware hardening, and RapidFort CART emits continuous, audit-ready conformity evidence in JSON, CSV, HTML, and XML against OpenSCAP baselines. This directly supports CRA SBOM, vulnerability-handling, and conformity-assessment duties.