What DORA Means for the Use of Open Source Software

Open Source Software (OSS) is an integral part of the IT landscape of financial institutions—from frameworks and libraries used in in-house software development all the way to core banking systems and specialized applications sourced from third-party providers. With the Digital Operational Resilience Act (DORA), this technical reality becomes a regulated ICT risk factor.

The Digital Operational Resilience Act (DORA) tightens the requirements for ICT risk management in companies. The regulation requires resilient ICT risk management, effective vulnerability and change management, regular testing of digital resilience, and robust oversight of third-party ICT providers. Open Source Software is part of this regulated world and must—like any other software—be deployed strategically and managed professionally.

Those who use Open Source in critical or important functions will no longer be able to rely on informal practices in the future. Professional Open Source management with guidelines, processes, clear roles, systematic vulnerability management, active version verification, and transparency in inventorying through Software Bill of Materials (SBOM) will become a prerequisite for meeting DORA requirements.

DORA Makes OSS an ICT Risk Factor

DORA establishes a uniform, binding framework for ICT risk management for financial entities, including the handling of Open Source Software. OSS components embedded in applications, platforms, and infrastructures thus become a regulated ICT risk factor that must be actively managed. Financial institutions must be able to demonstrate that they specifically control and inventory the use of Open Source Software, systematically manage vulnerabilities, and verify that it is up to date to ensure DORA compliance.

This results in specific requirements for organisations:

• Governance, policies, and processes: The use of OSS must be embedded in a clearly defined ICT risk management framework, supported by dedicated strategies, policies, and procedures that explicitly address Open Source and are integrated into existing guidelines (e.g., application development, ICT security, vulnerability management).
• Vulnerability Management for OSS: For OSS libraries—especially in critical or important functions—procedures are required for the continuous  automated and regular vulnerability scans, risk-based assessment of findings, and documented, traceable decisions regarding updates, compensating controls, or risk acceptance.
• Currency and Patch Management: DORA expects the currency of OSS components to be continuously monitored. Companies must track releases and security patches, assess their relevance, and promptly roll out security-critical updates in particular, or maintain documented and monitored justified exceptions.
• Inventory of Third-Party Libraries: Financial entities must continuously identify and inventory third-party libraries, including Open Source Software libraries.
• Training and Awareness: Appropriate measures ensure that personnel involved in software development, architecture, operations, and procurement are aware of and understand the specific requirements for OSS under DORA and can apply them in practice.

Dimensions of the Open Source DORA Management

^{Source: PwC “What DORA Means for the Use of Open Source Software”}

The Software Bill of Materials as a Key Element for Security

The Software Bill of Materials (SBOM) serves as the critical link between transparency, vulnerability management, and the monitoring of software currency. It describes which software components—including all OSS components—are contained within an application, which versions are in use, and how the dependencies are interconnected, including transitive dependencies.

In the context of DORA, an SBOM enables newly discovered vulnerabilities to be rapidly mapped to an organization's own system landscape: Is a vulnerable dependency deployed? in which applications? and with what business relevance and criticality? Those who systematically and centrally use and inventory SBOMs gain a consolidated overview of all OSS components in use and can prioritize measures.

The SBOM is evolving from a technical best practice component into a regulatory necessity, enabling organizations to demonstrate compliance with DORA requirements for vulnerability management, asset inventory, and timely updates of software to supervisory authorities.

Get the support you need to achieve DORA compliant OSS management. We can help you establish governance, SBOM (SPDX), vulnerability and patch management, contractual requirements, and training.