-3-2.webp)
OSS Vulnerabilities and the Digital Operational Resilience Act (DORA)
Learn how your organization can achieve DORA compliance for managing open source software vulnerabilities with reachability-based SCA, SBOMs, and more.
Learn how your organization can achieve DORA compliance for managing open source software vulnerabilities with reachability-based SCA, SBOMs, and more.
Learn how your organization can achieve DORA compliance for managing open source software vulnerabilities with reachability-based SCA, SBOMs, and more.
Learn how your organization can achieve DORA compliance for managing open source software vulnerabilities with reachability-based SCA, SBOMs, and more.
Learn how your organization can achieve DORA compliance for managing open source software vulnerabilities with reachability-based SCA, SBOMs, and more.
Software applications are critical infrastructure in the financial sector and disruptions can have significant societal and economic impacts. When organizations lack digital resilience, the business interruption for one organization crosses geographic boundaries, creating a sense of instability that can have a cascade effect. Of particular concern are digital payment systems and online insurance services, which is why the European Parliament approved the Digital Operational Resilience Act (DORA) that entered into force on January 16, 2023 and will apply beginning January 17, 2025. For organizations that fall under DORA, understanding the key components related to application development and security is critical for achieving compliance.
If you’re already familiar with DORA, skip to What Key DORA Provisions Apply to OSS Vulnerabilities? Otherwise read on for a quick primer on the regulation.
What is DORA?
DORA seeks to standardize information and communication technology (ICT) operational risk management by providing a framework for financial services organizations across the European Union. DORA’s main objective is for everyone to take the principle-based approach to address ICT risk and hopefully reduce the economic impact of targeted attacks against these critical services.
At a high level, DORA sets forth requirements for:
- Implementing and maintaining ICT risk management strategies, policies, and procedures
- Using and maintaining ICT systems
- Identifying, classifying, documenting, and exchanging ICT risk information
- Developing, documenting, implementing, and maintaining security policies and continuously monitoring technical controls’ effectiveness
- Implementing monitoring and detection mechanisms
- Establishing and testing business continuity and incident response policies and processes
- Developing, documenting, implementing, and testing backup, restoration, and recovery policies, procedures, and methods
- Implementing capabilities and staff to gather vulnerability and cyber threat information, ICT-security awareness programs, and review incident detection and response plans
- Implementing crisis communications plans and policies related to ICT incident or vulnerabilities
What are ICTs?
DORA defines an “ICT asset” as follows: Software or hardware asset in the network and information systems used by the financial entity.
In simpler terms, it refers to all the technologies used to create, store, transmit, share or exchange information. Any application or device firmware connected to a covered entity’s environment falls within the regulation’s umbrella, such as:
- Software applications, including those that access the public internet
- Computers and tablets
- Telecommunication technologies (phones, mobile networks)
- Devices, such as workstations, tablets, and mobile phones
Basically, anything that’s used by a financial institution for the purpose of electronically communicating and managing information falls under the umbrella of ICT.
Who Needs to Comply with DORA?
DORA applies to organizations and third-parties across the financial services sector that generally break down into two categories:
- Financial institutions, such as banks, credit institutions, insurers, investment firms, crypto firms, data providers, and payments processing organisations.
- Third-party ICT service providers of technology services to financial institutions, particularly those identified as critical
What Key DORA Provisions Apply to OSS Vulnerabilities?
Two of DORA’s articles specifically touch on issues that software producers need to consider:
- Article 9 Protection and Prevention:
The design, procurement, and implementation of ICT security policies, procedures, protocols, and tools should include appropriate and comprehensive documented policies for patches and updates. - Article 25 Testing of ICT tools and systems:
Digital operational resilience testing shall provide for vulnerability assessments and scans, open source analysis, and source code reviews.
Which Regulatory Technical Standards (RTS) are Applicable?
While DORA defines the “what” of broad objectives at a regulatory level, it fails to address the “how” of complying with them. To support DORA compliance, a set of governing bodies are in the process of publishing technical standards that give more details around required activities to achieve compliance.
The RTS defines, published January 17, 2024, provide specific technical requirements so that organizations have a clear and coherent picture of effective implementation. There are two RTS articles that AppSec teams should understand: Articles 10 and 16.
RTS Article 10: Vulnerability and Patch Management
Whether built internally or purchased from a third-party vendor, covered entities must include third-party libraries and open source components (OSS) as part of their vulnerability and patch management programs.
As part of defining the vulnerability and patch management requirements for achieving compliance, Article 10 Subparagraph 2 notes that procedures shall:
(d) track the usage of third-party libraries, including open source, used by ICT services supporting critical or important function, of ICT services developed by the financial entity itself or specifically customised or developed for the financial entity by an ICT third-party service provider. The financial entity, in collaboration with the ICT third-party service provider as appropriate, shall monitor the version and possible updates of the third-party libraries. In case of ready to use (off-the-shelf) ICT assets or components of ICT assets acquired and used in the operation of ICT services not supporting critical or important functions, the financial entity shall track to the extent possible the usage of third-party libraries, including open source ones;
RTS Article 16: ICT Systems acquisition, development, and maintenance
Under DORA, organizations have a higher compliance threshold for managing third-party ICT risk. Whether using internally designed technologies or purchasing ICT assets, organizations need to meet the following requirements set out in Subparagraph 2:
(a) the requirements to test and approve all ICT systems prior to their use and after maintenance…shall be commensurate to the criticality of the concerned business functions and ICT assets. The testing shall be designed to verify that new ICT systems are adequate to perform as intended, including the quality of the software developed internally.
(b) the requirements to perform source code reviews covering both static and dynamic testing. The testing shall include security testing for internet-exposed systems and applications… Financial entities shall identify and analyse vulnerabilities and anomalies in the source code, adopt an action plan to address them and monitor their implementation.
(c) the requirements to perform security testing of software packages at no later than the integration phase…
(f) the requirement that proprietary software and, where feasible, the source code provided by ICT third-party service providers or coming from open source projects, shall be analysed and tested prior to their deployment in the production environment
What are AppSec Best Practices for OSS Compliance?
For organizations that need to achieve DORA compliance, the biggest challenge lies in the short timelines. As the governing bodies continue to publish additional technical requirements, companies should consider implementing technologies that support these detailed software security requirements.
Open source software (OSS) can present some of the greatest risks, and in particular OSS dependencies for software applications. As part of this evaluation, covered entities should consider whether the solutions they use enable them to achieve the following OSS best practices:
- Identify all components and dependencies
- Proactively assess OSS risk
- Scan for OSS vulnerabilities
- Prioritize OSS vulnerability remediation
Are DORA and PCI DSS Related?
If your organization has to comply with PCI DSS, you’ll notice that some DORA and RTS articles overlap with PCI DSS requirements 6.3 (Security vulnerabilities are identified and addressed) and 11.3 (External and internal vulnerabilities are regularly identified, prioritized, and addressed). Depending on your OSS vulnerability management program, it’s possible that some controls could apply to both standards. Much like with privacy regulations (such as the Privacy Act and GDPR), it’s best practice to identify the most stringent applicable regulation and design controls accordingly.
Identify All Components and Dependencies
To identify and track all components and dependencies, covered entities should incorporate tools that can discover components, including OSS dependencies which is typically accomplished with Software Composition Analysis (SCA).
Once the components are discovered, a detailed Software Bill of Materials (SBOM) is the industry standard for documenting the software inventory. For applications that are developed in-house, covered entities can create SBOMs to prove that they have identified and documented all third-party components and dependencies. When consuming software from a vendor, organizations will also need the ability to ingest 3rd party SBOMs so the program owner can see what kind of risk is being brought in by external tools, so if there's something problematic they can flag it immediately for the tool owner to deal with. Additionally, covered entities should consider a solution that enables them to collect, maintain, and manage all SBOMs from a single location.
Proactively Assess OSS Risk
Shifting security left means incorporating it as early in the development process as possible. By doing this, developers can improve security while reducing the time spent remediating vulnerabilities.
Organizations that need to achieve DORA compliance should look for solutions that enable their developers to research OSS package security prior to incorporating the component into their projects and automatically flag “bad” OSS. This can reduce future security debt by decreasing the probability of using packages with known security risks. With solutions that apply AI and natural language, AppSec teams can:
- Empower developers to research packages using simple questions
- Gain visibility into package security, popularity, activity, and quality
- Set guardrails for OSS selection
- Monitor OSS usage and security
Scan for OSS Vulnerabilities
RTS Article 16 specifically identifies static and dynamic application testing as part of achieving DORA compliance. Given that up to 97% of modern code is OSS, the lion’s share of vulnerabilities will be in OSS dependencies and as mentioned above, SCA is the industry standard for evaluating OSS dependencies for risk. When evaluating SCA tools to determine if they’ll support DORA compliance, it’s important to understand what the tool is using for a vulnerability database. Ask questions like:
- Where does the list of vulnerabilities come from?
- How confident are we in the data?
- Does it cover all ecosystems relevant for me, e.g. Python, Java and C#?
- How often is it updated?
Once the vulnerability database questions have been answered, the next consideration is whether the SCA tool can connect vulnerability information to SBOMs so that you can automate documentation. Vulnerability Exploitability eXchange (VEX) is another standard that is a companion document to the SBOM. The purpose of a VEX is to provide context and explanation about the vulnerabilities identified in an SBOM, including whether the third-party has fixed the component or not.
Prioritize OSS Vulnerability Remediation
For developers, remediating all vulnerabilities becomes time-consuming and overwhelming. Again, this is where a strong SCA tool can help, because teams ship software faster and more securely by focusing on what matters most. For each vulnerability discovered, the tool should help you determine:
- Is the function containing the vulnerability “reachable”?
- Is there a fix available?
- Is it in production code (not test code)?
- Is there a high probability of exploitation (high EPSS)?
- Is the risk of performing the upgrade lower than the security risk it repairs?
Reachability 101
When an OSS package is used in your application code, your developers are typically just using a subset of the package rather than the entire package. When the vulnerable code isn’t actually in use, there’s little point in waking people up to chase it down. But how do you know what’s actually in use? That’s where “reachability” is important.
An SCA tool that can perform “function-level” reachability is able to generate a call path from code to vulnerable function, indicating if the code can be exploited. If you can filter out vulnerabilities that aren’t reachable at the function level, you can deprioritize 80%+ of SCA alerts. This saves valuable time on investigation and triage, letting your teams jump straight to remediation.
As mentioned above, the best case scenario is an SCA tool that can generate SBOM and VEX documents. The VEX document can become even more valuable when it contains reachability information on the findings. This information provides SBOM consumers with the information they require to know which findings represent potential threats (i.e. those that are reachable) and which were justifiably deprioritized by your team (i.e. the unreachable findings).
How to Support DORA Compliance Readiness with Endor Labs
Endor Labs is SOC 2 Type II certified and can help you achieve DORA compliance, as well as FedRamp, PCI DSS, and more.
To get started with Endor Labs, start a free 30-day trial or contact us to discuss your use cases.
Select Better Open Source Software
Select better open source dependencies with 150+ checks and scoring based on security, legal, popularity, activity, and quality. Defend against OWASP OSS Top 10 Risks such as typosquatting, malicious and abandoned dependencies.
Prioritize Open Source Vulnerabilities (SCA)
Cut over 90% of vulnerability noise with function-level reachability analysis across both direct and transitive dependencies. Codify highly customizable policies to provide developers feedback in PR comments, break builds in CI, or simplify notify them via Jira tickets.
Prepare for mandates by exporting accurate SBOMs & VEX documents and ingesting 3rd party SBOMs. Automatically update risk profiles with new security advisories, with no need to recreate the SBOM.