DORA Compliance for Container Images: A Guide

Q: Which authorities supervise this, and who do I produce evidence for?

From the built image. A Dockerfile declares intent; the image is what actually shipped. Build-stage generation captures resolved versions, transitive dependencies, and the operating-system package layer that manifest parsing never sees. Generating from source is useful for early license checks, but it is not the artifact to put in front of an assessor or a customer.

Udi Doron

Oct 20, 2026 | 8 Minutes

Container hardeneing

Automated patching

Market Research

DORA compliance for container images

DORA does not name container images, Kubernetes, or base layers anywhere in its text. What it asks for is evidence: that you know which ICT assets you run, that you protect and patch them, and that you can describe and document the third parties whose software ends up inside your production stack. Container images sit squarely inside all three obligations, and for most engineering teams they are the weakest part of the evidence file.

Key takeaways

DORA never mentions containers, but lands on them. Asset identification, protection and prevention, and third-party risk all converge on the base image.
The examiner's questions are narrow. What is inside, where it came from, what is unfixed, and how fast it gets fixed.
Your base image needs a counterparty. A public image leaves a blank in your third-party documentation that no amount of scanning fills.
Four hours is a lookup, not an investigation. Signed SBOMs bound to digests are what make the incident clock survivable.
The same evidence serves CRA, NIS2, FedRAMP and ISO 27001:2022. Build it once for the hardest regime and reuse it.

Why a regulation that never mentions containers lands on your images

DORA - the Digital Operational Resilience Act - applies across the EU financial sector and is supervised by national competent authorities including BaFin in Germany, ACPR in France, Banca d'Italia in Italy, and the Central Bank of Ireland, with oversight of critical ICT third-party providers run by the ESAs: EBA, EIOPA and ESMA (Echo DORA overview).

The regulation is deliberately outcome-based. It talks about ICT risk management, protection and prevention measures, incident reporting, and third-party risk. It leaves the implementation to you. That is why this work tends to stall in the same place: a supervisor asks what is inside a production workload and who maintains it, and the honest answer is a public base image pulled from a registry, maintained by volunteers, with no SLA and no inventory.

Three obligations turn into container work:

Know what you run. ICT asset identification means an accurate, current inventory of components - which for a containerised estate means artifact-level visibility, not a list of services.
Protect and prevent. Minimising the ICT risk carried into production covers configuration hardening, attack-surface reduction, and patch cadence.
Account for your third parties. Every vendor whose code executes in your environment is in scope, and that includes whoever maintains the operating-system packages in your base layer.

What a supervisor actually asks for

In practice the questions are narrower than the regulation's language suggests. The four that come up most:

What is in this image? - an artifact-level component inventory.
Where did it come from and who built it? - provenance, signed.
What is still unfixed, and why? - a current, honest vulnerability position rather than a clean-looking scan.
How fast do you fix things, and who is contractually on the hook? - a documented remediation commitment.

Echo's DORA material maps the same four to concrete outputs: SBOMs in SPDX and CycloneDX, with every tag carrying its corresponding SBOM; clear reporting on all unfixed vulnerabilities; provenance and attestations signed via cosign and sigstore; and images pre-hardened with secure configurations and stripped to a minimal footprint (Echo DORA overview).

The incident clock is why vulnerability evidence matters

DORA's incident-reporting regime runs on a short timetable - Echo's DORA page describes the practical burden as supporting the root-cause analysis behind the 4-hour initial notification and 72-hour intermediate report (Echo DORA overview).

Four hours is not enough time to reconstruct what was in a container. It is enough time to look it up. The difference between those two situations is whether the artifact-level inventory already exists, signed and attached to the digest you deployed, before anything went wrong.

Three ways to source base images, compared

Dimension	Public upstream images	Build and harden in-house	Vendor-maintained hardened images
Component inventory	Generate it yourself, per image	Generate it yourself, per image	Shipped per tag (SPDX + CycloneDX)
Provenance and signing	Usually absent	Yours to build and operate	Signed and attestable (cosign, sigstore)
Patch commitment	None — best effort upstream	Whatever your team can sustain	Contractual SLA
Third-party accountability	No identifiable counterparty	You are the counterparty	Named vendor, in your documentation
Hardening baseline	Undefined	Defined, re-verified every update	Pre-hardened, maintained
Ongoing engineering cost	Low at first, grows with CVE load	High and permanent	Shifted to the vendor

The middle column is where most regulated teams start and where most of them get stuck. Building a compliant image once is achievable; re-verifying hardening and re-documenting it on every upstream update, across a catalogue, is the part that does not scale.

The third-party column is the one examiners read

This is the detail engineering teams underestimate. Under DORA you have to be able to describe your ICT third-party arrangements - who they are, what they provide, and what they are contractually committed to.

A public base image has no counterparty. There is nobody to name, nothing to point at for a remediation commitment, and no contractual recourse. Swapping to a maintained source changes the shape of that entry entirely, because there is now a named supplier with a documented obligation.

That obligation needs to be specific. Echo's published SLA commits to applying eligible patches to critical and high-severity CVEs within 7 business days, and medium and low within 10 business days (Echo Images and Libraries SLA, last updated 10 May 2026). For artifacts containing FIPS-validated components, remediation follows the validated module's update stream, because applying a fix outside it would invalidate the certification. We wrote about why a contractual clock changes risk posture in how automated patch SLAs reduce enterprise risk.

One set of artifacts, several regulations

The useful property of this evidence is that it is not DORA-specific. The same SBOMs, provenance attestations, and remediation records feed CRA readiness, NIS2, FedRAMP, ISO 27001:2022, FIPS and STIG work (Echo DORA overview).

If the EU Cyber Resilience Act is also on your roadmap - and for most financial entities shipping software to customers it is - the overlap is substantial. Our EU Cyber Resilience Act requirements guide covers where the two regimes ask for the same artifact under different names.

A practical sequence

Most teams can move their position materially in a quarter by working through these in order:

Inventory your base layers, not just your services. Most estates have far fewer distinct base images than they expect, and a handful account for most of the risk.
Decide the sourcing model per layer using the table above. Not every workload needs the same answer.
Make SBOM and provenance generation a build gate, bound to the image digest rather than the tag.
Write the remediation commitment down - either your own internal SLA, or the vendor's published one, referenced in your third-party documentation.
Rehearse the four-hour question. Pick a production image at random and time how long it takes to answer "what is in this, who built it, and what is unfixed."

FAQ

Does DORA require container-specific controls?

No. DORA is outcome-based and never mentions containers, Kubernetes, or base images. It requires ICT asset identification, protection and prevention measures, incident reporting, and third-party risk management. Containers simply happen to be where those obligations concentrate for modern financial-sector workloads, because the image is both the asset and the third-party dependency.

Which authorities supervise this, and who do I produce evidence for?

DORA is supervised by national competent authorities across the EU - BaFin in Germany, ACPR in France, Banca d'Italia in Italy, and the Central Bank of Ireland among them - while the European Supervisory Authorities, EBA, EIOPA and ESMA, run oversight of critical ICT third-party providers. Your evidence file is produced for your own national authority in the first instance.

Do public base images disqualify us?

Not automatically. DORA does not prohibit any sourcing model. The difficulty is evidentiary: a public image gives you no named counterparty for your third-party documentation, no contractual remediation commitment, and usually no signed provenance. You can compensate by generating and maintaining that evidence yourself, but the cost recurs with every upstream update.

What is the fastest thing we can change?

Make artifact-level inventory automatic. If every image you deploy already carries a signed SBOM bound to its digest, the hardest DORA questions become lookups rather than investigations. That single change also shortens incident reporting, feeds your third-party documentation, and carries straight over to CRA and NIS2 work.