Dora Open Source Risk

Under DORA, the open source libraries inside your production services are an audit item with specific rules. Commission Delegated Regulation (EU) 2024/1774 requires EU financial entities to track the open source libraries used by services that support critical or important functions, scan the assets behind those functions at least weekly, and verify that the vulnerabilities they find get fixed. That last requirement is where most DORA open source risk programs come up short: a scan report shows that your team looked, and reviewers now want proof that exposure went down.

This article covers four questions that come up when supervisors, internal auditors, and banking customers review software supply chain risk under DORA, why the common answers fall short, and the evidence that holds up. It's written for security and risk leaders at EU financial entities and for the information and communications technology (ICT) providers whose software runs inside them. For the strategic case behind the shift, read why DORA is about resilience more than compliance.

Why DORA puts the code you didn't write in scope

DORA has applied since January 17, 2025, to an estimated 22,000 EU financial entities, from banks and insurers to payment institutions and crypto-asset service providers . It also reaches the information and communication technology (ICT) third-party service providers those entities depend on. Article 10 of the ICT risk management standard requires each financial entity to verify that its ICT providers handle vulnerabilities in the services they supply and report at least the critical ones in a timely manner. If you sell software into an EU bank, your vulnerability handling is part of your customer's audit file.

The third-party oversight framework is also running. Financial entities filed their first registers of information on ICT contracts in 2025, and on November 18, 2025, the European Supervisory Authorities (ESAs) designated 19 critical ICT third-party providers for direct oversight.

For open source, the standard is specific. Article 10 requires you to track third-party libraries, including open source libraries, used by ICT services that support critical or important functions, and to scan the ICT assets behind those functions at least weekly. Article 16 adds that open source code is to be analyzed and tested before it reaches production, where feasible. Article 10 also requires you to monitor and verify fixes and to record each detected vulnerability until it's resolved. The standard doesn't define what that proof looks like, and that gap drives the four questions below.

Four questions that expose a software supply chain gap

Kamran Shirazi, VP of Business Development at RapidFort, hears the same four questions in DORA conversations with EU financial institutions and their suppliers . Each has a common answer that sounds reasonable and an answer that holds up under review.

The second question catches most teams. Application security programs are built around the code your organization writes. Inherited vulnerabilities sit in the base image, the language runtime, and transitive dependencies, and you can't patch them at the application layer because they ship with the environment the application runs on.

Why a scan report is weak evidence of control

Weekly scanning is required, and it's necessary. A scan report proves that your team looked; it doesn't show that exposure went down.

Most signature-based scanners report every CVE tied to every installed package, based on upstream data, whether or not that package ever runs. Each finding becomes a ticket, and each ticket competes with feature work. The backlog grows faster than teams can close it, and the evidence pack ends up documenting the backlog.

Timing makes this worse. Mandiant's M-Trends 2026 report estimates the mean time to exploit at -7 days, which means exploitation on average starts before a patch is available. A ticket queue records that gap without closing it.

A stronger answer to the first question measures elimination: the components you removed, the CVEs that went with them, and the date each change reached production.

How to build DORA audit evidence from intake to runtime

Evidence that holds up follows the software through its lifecycle, and each stage answers a different part of the reviewer's questions.

At intake: show where each component came from

Article 16 expects open source code to be analyzed and tested before it reaches production. Teams that pull base images and libraries from a curated, validated source can show provenance for each component and the advisory or justification behind any open finding. Curated libraries that go through malware analysis also cover a risk CVE scanners miss: malicious packages published through compromised maintainer accounts or typosquatting.

At build: show what the software contains and what it uses

An SBOM records what's installed. A Runtime Bill of Materials (RBOM®) records what actually executes when the workload runs. The difference between the two is code you ship and never use, and that code still shows up in your scan results. See how an RBOM® and an SBOM differ.

Removing unused components gives you a measurable before-and-after: fewer packages, CVEs eliminated, and smaller images. Checking the result against CIS Benchmarks, DISA STIGs, or checklists from the NIST National Checklist Program (SP 800-70) adds a verifiable statement about configuration.

One caution: profiling records only the code paths a workload exercises while it's observed. Profile across the full range of behavior, including month-end batch jobs, failover, and rarely used API routes, before you remove anything.

At runtime: show that the state holds

New CVEs are disclosed every day, so an optimized image stays current only as long as someone monitors it. Continuous correlation of new disclosures against deployed workloads, plus detection of unexpected package or binary changes against an approved baseline, turns a point-in-time result into an ongoing control. Together, the three stages give a reviewer a before-and-after picture of production that a findings list can't provide.

Incident reporting raises the cost of not knowing what runs

DORA's incident reporting rules put a clock on all of this. Under Delegated Regulation (EU) 2025/301, once you classify an ICT-related incident as major, the initial notification is due within 4 hours of classification and no later than 24 hours after you became aware of the incident. The intermediate report is due within 72 hours of the initial notification, and the final report within 1 month of the latest intermediate report.

Software supply chain events test that clock. In September 2025, CISA warned that a self-replicating worm known as Shai-Hulud had compromised more than 500 npm packages. For any team running JavaScript services, the first question was exposure: which services include an affected package, which versions, and whether that code executes in production.

If an event like that becomes a major incident for you, a current SBOM and a runtime record let you answer in minutes. Periodic scan reports can consume much of the 4-hour window before you've established exposure. The same records support the root cause analysis DORA expects in the final report, because knowing what ran and what changed is where that explanation starts.

Where RapidFort fits in a DORA evidence trail

RapidFort maps to each stage above. At intake, RapidFort Images and RapidFort Libraries give you a validated source: tens of thousands of curated near-zero CVE images and a library catalog validated through binary malware analysis by ReversingLabs . At build, RapidFort Analyzer generates the SBOM for each image, Profiler generates the RBOM®, and Optimizer removes the components your workload never uses. That process eliminates up to 99.9% of CVEs and reduces attack surface by up to 90%.

In production, RapidFort Runtime monitors deployed workloads, correlates newly disclosed CVEs with the software that's running, and flags changes to packages, binaries, and processes against an approved baseline. RapidFort Continuous Compliance packages the results as compliance documentation for reviewers .

If you're an ICT provider, the same SBOM, RBOM®, and vulnerability records answer the Article 10 checks your financial services customers run on you.

What to do before your next DORA review

You can test your evidence trail against the four questions with five steps:

1. List the services that support critical or important functions and confirm each one has a current SBOM.
2. Compare what's installed with what executes for your highest-risk services, and record what you remove.
3. Set patch deadlines and escalation steps by component class, and track performance against them.
4. Run a tabletop exercise on a malicious package scenario and time how long it takes to confirm exposure.
5. If you're an ICT provider, prepare the SBOMs, RBOM® records, and vulnerability reports your customers will request.

Reviewers don't expect a CVE count of zero, and DORA places no limit on open source use. They expect evidence that risk in your software supply chain goes down, stays down, and can be verified. Starting from clean components, removing what your application never uses, and monitoring what runs produces that evidence as part of normal engineering work.

Watch the full webinar, From Vulnerability Management to Vulnerability Elimination: How DORA Is Redefining Operational Resilience, to hear Kamran Shirazi and Michael Wood walk through each question in detail.