The Digital Operational Resilience Act (DORA), or Regulation (EU) 2022/2554, came into effect on 17 January 2025. Unlike a directive, it required no national transposition: it applies directly, uniformly, and is already being enforced. Financial entities across the EU have structured their compliance programmes around DORA's five well-known pillars. What's received less attention is how DORA compliance applies to containerised infrastructure.
Container images are Information and Communications Technology (ICT) assets under DORA. The open-source libraries inside them are third-party software components that the regulation explicitly requires you to track. Your CVE posture is auditable evidence of whether your ICT risk management obligations are being met. Most container estates aren't ready for that level of scrutiny.
This guide is written for two audiences that both have skin in this game. First, platform and DevSecOps engineers at financial entities who need to understand what DORA requires of their container infrastructure. Second, engineers at ICT vendors who are building and shipping software into the financial sector, where DORA compliance is increasingly a contractual precondition for doing business.
DORA and NIS2 are often mentioned in the same breath; both are EU regulations addressing cybersecurity resilience, and many organisations fall under the scope of both. The key difference is scope and depth.
NIS2 is a broad directive covering critical sectors including energy, transport, and financial infrastructure, setting baseline requirements for incident reporting and supply chain security. DORA applies directly and uniformly across all EU member states without national transposition and, while narrower in sector scope (financial entities only) is significantly more prescriptive in its technical requirements.
For container infrastructure, DORA sets the higher bar. Where NIS2 establishes general cybersecurity obligations, DORA specifies exactly how financial entities must manage ICT risk, test operational resilience, and govern third-party technology providers. If your organisation is subject to both, meeting DORA's requirements will generally satisfy the overlapping NIS2 obligations as well.
DORA organises its requirements into five areas. Three of them have direct implications for container security:
The other two pillars, DORA incident reporting and information sharing, are less directly shaped by container image hygiene; though a well-maintained container estate makes incident scoping and response significantly faster.
DORA defines an ICT asset as any "software or hardware asset in the network and information systems" used by a financial entity. Container images are software assets by that definition. Every image running in your production environment is an ICT asset that falls inside DORA's compliance scope.
This has practical consequences that most container security conversations don't address:
Article 8 mandates that financial entities "identify, classify and adequately document all ICT assets" and maintain inventories that are "updated periodically and every time any major change occurs." That's not an annual spreadsheet exercise. For container workloads, it means knowing exactly what images are running, what packages they contain, and when that inventory last changed.
The Regulatory Technical Standards published under DORA go further than the regulation text itself. They explicitly require financial entities to "track the usage of third-party libraries, including open source, used by ICT services supporting critical or important functions" and to monitor version changes and available updates.
The packages inside your base images are open-source third-party libraries. Every Python package, every C library, every utility bundled into that image is a component the RTS expects you to know about and track over time. Without a package-level inventory of your images, meeting this requirement is not possible.
Article 8(2) uses the phrase "on a continuous basis" when describing the obligation to identify cyber threats and ICT vulnerabilities. This is deliberate. A quarterly vulnerability scan doesn't satisfy DORA. New CVEs are disclosed daily; a container image that was clean on Monday may have a known exploited vulnerability by Thursday. Continuous risk identification means the gap between a CVE disclosure and your awareness of its impact on your image estate needs to be measured in minutes, not weeks.
The table below maps the DORA articles most relevant to container workloads to specific security controls required for DORA compliance. This is the framework auditors will implicitly apply when reviewing your ICT risk management posture.
The sections below expand on each requirement and what meeting it actually looks like in a containerised environment:
A container image is not a single ICT asset; it's a collection of ICT assets. The image itself, every OS package it contains, every runtime dependency, every third-party library: all of these are software components that exist inside your production infrastructure. DORA's asset management requirement reaches all the way down.
A Software Bill of Materials (SBOM) is the mechanism for meeting this requirement. An SBOM is a machine-readable inventory of every component inside an image, including package names, versions, provenance, and dependency relationships.
Under DORA, SBOMs are not a best practice borrowed from software supply chain guidance; they are the artefact that makes Article 8 compliance demonstrable. Without them, you cannot prove to an auditor that you know what's in your ICT asset inventory.
Identifying vulnerabilities is one requirement; staying current with new disclosures is another. A CVE published today against a library in one of your images represents an ICT risk that Article 8(2) expects you to know about, continuously. The challenge with containers is that a single base image change can affect dozens of downstream services simultaneously.
The practical requirement here is a CVE intelligence feed that maps new disclosures against your actual image inventory in real time, and that prioritises by exploitability rather than raw severity score. A CVSS 9.8 vulnerability with no known exploit and no reachable attack path in your environment is less urgent than a CVSS 7.2 with active exploitation in the wild. DORA's risk-based framing supports exactly this kind of prioritisation.
Article 9 requires documented patch and update policies as part of the ICT protection framework. For container workloads, this translates to two complementary controls:
DORA's resilience testing framework requires vulnerability assessments, open-source analysis, and software security reviews at a minimum. For financial entities running containerised workloads, the CVE profile of your images is a direct input to that testing programme.
An image estate with hundreds of known CVEs across hundreds of images creates a testing programme that is expensive to scope, slow to remediate, and difficult to report on clearly. An image estate built on hardened, minimal images with near-zero CVEs and benchmark attestations already in place substantially reduces that burden and produces cleaner, more defensible test results. Benchmark alignment against recognised standards like CIS Controls and NIST also provides the security review documentation the testing programme requires and strengthens your overall DORA compliance posture.
This is the article with the most direct commercial implication for ICT vendors building software that runs in financial sector environments. Article 28 states that financial entities "shall manage ICT third-party risk as an integral component of ICT risk" and may only engage ICT service providers that meet appropriate security standards.
In practice, this means financial sector procurement teams are asking ICT vendors for evidence of security posture as a condition of contract, and increasingly, that evidence needs to be specific and auditable. Generic security questionnaires and SOC 2 reports are a starting point; what financial sector clients are increasingly asking for are:
ICT vendors who can produce this evidence quickly (because it's generated automatically rather than assembled under audit pressure) have a meaningful competitive advantage in regulated markets.
The DORA RTS requirement to track open-source library usage is worth its own attention because it's specific, underappreciated, and directly actionable. The exact language requires tracking "the version and possible updates" of third-party libraries in ICT services supporting critical or important functions; this means not just knowing they exist, but monitoring them over time.
For containerised services, this means:
A signed SBOM per image, continuously regenerated as images are rebuilt, is what this requirement looks like in practice. The SBOM is the inventory; continuous rebuilds keep it current; a CVE intelligence feed completes the loop by connecting new disclosures back to the SBOM data. Together, these three capabilities cover the open-source tracking requirement in a way that's audit-ready by default, not assembled retrospectively when an auditor asks.
DORA enforcement sits with the European Supervisory Authorities: the EBA, ESMA, and EIOPA, as well as national competent authorities for each member state. Critical ICT Third-Party Providers face direct oversight from the ESAs. For container workloads, here is what that DORA compliance oversight looks like in practice.
Minimus is purpose-built to solve the container security compliance problem and support DORA compliance by default. Whether you're a financial entity managing internal infrastructure or an ICT vendor demonstrating security posture to financial sector clients, Minimus's capabilities map directly to DORA's container-relevant requirements and produce the compliance artefacts auditors ask for as a matter of course, not as a manual effort.
Minimus provides hundreds of hardened, minimal container images built from source with the latest security patches. By removing everything not required by the workload (shells, package managers, build tools, unused OS packages) Minimus images address DORA's Article 9 protection requirements at the foundation.
The result is a dramatically reduced attack surface and a CVE profile that makes both continuous risk monitoring and resilience testing substantially simpler. Customers achieve over 97% reduction in container CVEs compared to standard public registry images.
Every Minimus image comes with an automatically generated, cryptographically signed SBOM. The package-level inventory demanded by DORA's Article 8 asset management requirement and the RTS open-source tracking obligation is present by default for every image, without additional pipeline configuration. For financial entities, this is the audit artefact that proves ICT asset inventory depth. For ICT vendors, it's the document financial sector procurement teams are increasingly requesting as standard.
Minimus images are built and validated against CIS Controls and NIST standards. Compliance posture is visible directly in the Minimus web console, with native reporting that makes benchmark alignment demonstrable in seconds. For DORA's Article 25 resilience testing requirements, this is the difference between having to assemble security review documentation under audit pressure and having it available on demand. The reporting is built in, no manual evidence collection required.
Minimus images are rebuilt from source automatically whenever an upstream package changes. This is not a scheduled process; it's continuous. When a package receives a security update, the image is rebuilt, the SBOM is regenerated, and the updated image is available. For DORA's Article 9 patch and update policy requirements, this is patch currency implemented at the infrastructure level rather than as an operational process that depends on someone remembering to trigger a rebuild. The CVE debt that accumulates in manually maintained image estates simply doesn't build up.
Minimus maintains a real-time feed of CVEs and automatically alerts you when a new vulnerability affects one of your images. CVEs are prioritised by exploitability, not just CVSS score, so the remediation queue reflects actual risk rather than raw severity counts. For DORA's Article 8(2) continuous risk identification requirement, this closes the loop between CVE disclosure and operator awareness. The documented response timeline that auditors ask for is a natural output of a system that tracks which CVEs affected which images and when.
For ICT vendors building software that runs inside financial institutions, Minimus's compliance artefacts, including signed SBOMs, CIS/NIST benchmark reports, exploitability-prioritised CVE dashboards, are precisely what financial sector security assessments require. Being able to produce this evidence at the start of a procurement conversation, rather than scrambling to assemble it during vendor due diligence, is a meaningful differentiator in markets where DORA cybersecurity standards apply.
Whether you're working through internal compliance or preparing for financial sector client scrutiny, meeting DORA regulation requirements for container infrastructure requires following the same steps:
For financial entities, the DORA’s requirements for continuous ICT asset inventory, open-source library tracking, patch currency, and vulnerability management all reach directly into the container layer. For ICT vendors, the same requirements shape what financial sector clients need to see before they’ll sign contracts and what auditors will ask for once they have.
The container security gap is one of the most addressable parts of a DORA compliance programme. Hardened images, automated SBOMs, continuous rebuilds, and real-time CVE intelligence are the specific controls that close it, and they produce the audit artefacts that make compliance demonstrable, not merely asserted.
Minimus reduces container CVEs by over 97% and delivers the signed SBOMs, benchmark attestations, and real-time CVE intelligence your DORA compliance programme requires, making compliance easier to achieve, demonstrate, and maintain for financial entities and the ICT vendors who serve them. Explore how this approach works in practice by scheduling a demo.
.svg)
.svg)
.svg)
.svg)
