The Digital Operational Resilience Act (DORA) came into force across the EU on January 17, 2025, fundamentally changing how financial institutions must approach infrastructure and technology assets resilience. Its requirements around ICT risk management, operational resilience, and third-party oversight signal a broader shift that will ripple across regulated industries worldwide.

At its core, DORA demands something deceptively simple: organizations must know exactly what they’re running, where it came from, and how to fix it when something breaks. For technical teams managing complex stacks spanning bare metal, the OS, kernel, and applications, this translates into a hard requirement for provenance: transparent, verifiable lineage from source code all the way up.

The provenance problem: you can’t verify what you can’t see

Traditional vendor stacks create a fundamental compliance problem: they’re opaque by design. When you deploy a proprietary solution, you’re accepting someone else’s assurances about what’s inside. You can’t inspect the source code. You can’t verify the build process. You can’t independently validate that a security patch actually addresses the vulnerability it claims to fix.

While Software Bills of Materials (SBOMs) have emerged as an important transparency tool and represent progress, they fail to solve this fundamental inspection problem. An SBOM tells you what components are present in proprietary software, but you still can’t examine the source code itself or verify the build process yourself. For regulated organizations facing requirements like DORA, this creates a compliance gap, where you can document dependencies but cannot truly verify their integrity.

DORA explicitly requires financial entities to maintain oversight of their ICT infrastructure, including third-party dependencies. So, how do you maintain oversight of something you can’t inspect?

Open source becomes essential here. With open source software:

• You get reproducible inspectability all the way down the supply chain
• You can trace every component back to the developer who wrote it
• You can verify builds
• You can audit changes
• You can understand exactly what’s running in your environment

The single developer problem (and why Ubuntu Pro matters)

Here’s the uncomfortable truth about modern infrastructure: critical components in your stack likely trace back to a single developer somewhere on the internet, maintaining a library in their spare time. An estimate, based on analysis of ecosyste.ms data, shows that a relatively small group, on the order of ten thousand people, supports the majority of the world’s open source software users. In the Tidelift 2024 State of the Open Source Maintainer survey, 61% of unpaid maintainers reported working alone on their projects. When the Heartbleed vulnerability was discovered in 2014, OpenSSL—used by 66% of web servers at the time—was maintained by just a handful of volunteers, only one working full time, with the project receiving about $2,000 in annual donations.

These individual maintainers are doing heroic work. But from a resilience perspective, it’s a risk. What happens when that developer moves on? Gets burned out? Simply stops maintaining the package?

The problem is worsening: in 2024, almost 60% of maintainers reported having quit or considered quitting their maintenance work, with many citing burnout, insufficient compensation, and overwhelming demands on their time.

Investing in open source is a form of infrastructure security: it reduces your dependence on unpaid, solo maintainers and builds sustainable maintenance pipelines with professional support, timely security patching, and long-term viability. When enterprises pay for Ubuntu Pro, part of that funding flows back into the open source ecosystem through Canonical’s upstream engineering work and direct financial support for the projects Ubuntu depends on.​

Canonical does not just repackage open source; our engineers contribute features and fixes upstream across the projects shipped in Ubuntu, and we commit security maintenance for components long after their upstream end of life, such as continuing to backport OpenSSL 1.1.1 fixes for supported Ubuntu releases. Ubuntu Pro packages this ecosystem investment into a single subscription: up to 15 years of security maintenance for thousands of open source packages, plus the assurance that Canonical is actively collaborating with and funding the communities behind them. Instead of betting your resilience on a single unpaid maintainer, you get a vendor whose business model is aligned with keeping that open source infrastructure secure and sustainable over the long term.

From responsibility to assurance: system-level, not vendor-level

There’s a fundamental difference between a vendor taking responsibility for their products and a platform providing assurance for your entire system.

When an Ubuntu Pro customer from the financial industry asked, “How do we get all machines FIPS-enabled and CIS-compliant?”, that’s not a question about a single application. It’s a question about system-level security compliance across thousands of machines, down to the operating system and the metal beneath it.

Ubuntu Pro answers this by providing a single, verifiable stack with end-to-end provenance. The focus shifts from trusting individual vendors to establishing a unified security posture where every layer is supported, patched, and verifiable.

For finance organizations, this changes the conversation from “Do we trust this vendor?” to “Can we verify and validate our entire infrastructure up to the application layer?” The answer needs to be yes, and you need documentation to prove it.

The DORA advantage: knowing what you don’t know

Discovering what you don’t know proves more challenging than fixing known compliance issues. What packages are actually running in production? Which versions? What’s their patch status? What potential exposures might an auditor find during their next review?

With Ubuntu Pro, you get continuous visibility, security maintenance and support:

• Complete inventory: Enumerate exactly what’s running across your infrastructure
• Provenance tracking: Every package has verifiable lineage back to source
• Continuous patching: Both main and universe repository packages receive security updates
• Compliance tooling: Built-in capabilities for CIS hardening, FIPS certification, and compliance reporting

Beyond compliance: building for what comes next

Think of compliance as the baseline, not the goal. While DORA is a regulatory requirement for financial services in the EU, smart organizations across industries are using it as a model for their own resilience programs. The principles it codifies, operational resilience, supply chain transparency, systematic risk management, are universal concerns.

The trajectory is clear: more regulation, more scrutiny, more demands for transparency and provenance. When your industry’s equivalent of DORA arrives (and it will), you need infrastructure that can already demonstrate:

• Verifiable provenance for every component in your stack
• Long-term support commitments backed by professional teams
• System-level security compliance down to the OS and infrastructure layer
• Complete source code transparency and documented patching processes

Ubuntu Pro applies these principles to open source infrastructure, combining transparent components with long-term security maintenance and support so your stack is ready for whatever comes next.

Learn more about other security standards we support: ubuntu.com/security/security-standards.

References

• Digital Operational Resilience Act (DORA) – EIOPA
• Regulation (EU) 2022/2554 – EUR-Lex
• Tidelift 2024 State of the Open Source Maintainer Report
• The Unpaid Backbone of Open Source – Socket
• Critical infrastructure for the Web – Forbes
• Canonical + thanks.dev