Know Your Systems: DORA forces you to!

Open source in focus: Dora, vulnerabilities and the security of the software supply chain

In a world where open source is ubiquitous, experienced developers no longer rely on reinventing the wheel. Their secret weapon? Open source. The reasons for using it are to improve productivity, shorten development time and reduce development costs. But now the Digital Operational Resilience Act (DORA), applicable for the Financial Sector, is shedding new light on the use of open source. Hidden behind the scenes are requirements that many are not yet aware of.

DORA is the European response to the digital transformation of financial services and the increasing risk of cyber threats in the financial sector. And DORA therefore also has a wealth of requirements for the use of open source that most people are not yet aware of.

It starts with an in-depth identification and listing of all systems and components – a “know your systems” approach that includes not only commercial and self-developed components, but also all open source components and their mutual interdependencies. The focus of DORA is on vulnerabilities: Requirement are automatic vulnerability scans and remediation of security gaps. Weekly scans will be mandatory from Jan 2025 onwards!

DORA requires continuous monitoring of all product components, including open source components. Because security is the top priority here – and that means that newly discovered security vulnerabilities must be fixed immediately. There is a greater focus on the risk in the software supply chain, with the elimination of vulnerabilities through patches taking priority. Welcome to the age of digital resilience, where open source plays a crucial role!

The technical basis to be able to fulfill these requirements is a software bill of materials (SBOM). This SBOM contains all the components used and their dependencies. This includes all components from suppliers, whether open source or commercial. The security requirements for the supply chain exceeds the traditional requirements for application security. DORA aims to minimize potential risks in all components. The BSI (German Federal Office for information Security) has already issued a technical guideline on the components of the SBOM.

The management of open source is now standardized, with important standards such as ISO/IEC 5230 for license compliance and ISO/IEC 18974 for dealing with security vulnerabilities. Standards such as ISO/IEC 5962, the Software Package Data Exchange format (SPDX) and CycloneDX can be used for data exchange between the parties. Regular checks of the SBOM can quickly identify security vulnerabilities or updates for open source components, and suitable tool chains enable largely automated creation of the SBOM after an initial setup phase.

In order to meet the requirements of DORA, companies are increasingly relying on an Open Source Office (OSPO), a specialized organizational unit that takes care of free and open software as well as open hardware and standards. Some companies offer OSPO functions as a service in order to meet the increasing requirements.

Summary

The DORA challenges in relation to open source are solvable if you are well prepared:

1. Identification of all open source components and their dependencies, including software supplied by suppliers, by creating the SBOM.
2. Regular checks for new security vulnerabilities and updates.
3. regular updating of the SBOM with software updates.

Bitsea has many years of experience in this area and is happy to help you understand and solve the challenges of DORA in the open source area.