Software-related incidents, supply-chain attacks, breaches, and vulnerability backlogs continue to grow. The problem is not an inability to find vulnerabilities. Organizations have become effective at discovering them, often finding too many to handle. The bigger problem is that traditional security tooling was built primarily to identify and track vulnerabilities, not eliminate them from the software supply chain.
The European Union’s Digital Operational Resilience Act (DORA) turns vulnerability management from a best practice into a regulatory statute, requiring covered financial entities to establish formal, documented programs for managing ICT risk and demonstrating operational resilience.
DORA applies across the EU financial sector and extends to critical Information and Communication Technology (ICT) third-party service providers. Its purpose is straightforward: Financial organizations must be able to withstand, respond to and recover from disruptions, not simply demonstrate compliance through policies and documentation.
DORA rests on four core areas: ICT risk management, resilience testing, third-party risk management, and incident reporting. With more than 22,000 financial entities directly subject to the regulation, and ICT providers also within its scope, software supply-chain security has effectively become a shared compliance responsibility.
The critical question is whether the controls described in those documents are effective in production. Questions that need answered are:
- Are critical software risk controls effective and operational?
- How are vulnerabilities originating outside an organization’s own code managed?
- What is the mean time to remediate critical production vulnerabilities?
- How are third-party and open-source risks addressed across the software supply chain?
The implication is clear: Regulators are interested in the hardened state of production environments, not simply the existence of vulnerability-management policies.
The Growing Problem of Inherited Vulnerabilities from Open Source
One of the biggest challenges is that much of the risk in modern applications comes from software that organizations did not write themselves.
Open-source packages, container images, libraries, frameworks, cloud SDKs, AI frameworks and third-party software components can introduce vulnerabilities into applications. Container images can contain hundreds of operating system packages, runtimes and libraries, including components that are never actually used.
If every newly discovered CVE becomes another ticket for developers to investigate, organizations can end up spending increasing amounts of time managing vulnerabilities while delaying production and not materially reducing their exposure.
The urgency is compounded by the shrinking window between vulnerability disclosure and exploitation. Attackers have dramatically accelerated the exploitation of publicly disclosed vulnerabilities, with same-day exploitation becoming an increasingly serious concern. There were more than 35,000 CVEs reported during the first half of 2026, representing an increase of almost 50% compared with 2025.
At the same time, AI is accelerating reconnaissance and helping attackers identify vulnerable public-facing applications. The result is a security environment in which simply planning to patch vulnerabilities later is increasingly inadequate.
The alternative is to move from vulnerability discovery toward vulnerability elimination. A three-step approach can help.
Profile. First, organizations should generate a Software Bill of Materials (SBOM) and Runtime Bill of Materials (RBOM); scan for malware, tampering and secrets; identify relevant CVEs; and incorporate appropriate security benchmarks.
Replace. Next, vulnerable or untrusted components can be replaced with curated, hardened images and libraries from validated sources. Organizations should also maintain the documentation and justifications necessary to demonstrate how security requirements are being addressed.
Optimize and harden. Finally, organizations should identify unused components within applications and remove or isolate them. Continuous monitoring, alerting, and automated remediation can then help maintain the hardened environment.
An SBOM provides visibility into what software components are present. An RBOM goes a step further by helping organizations understand what is actually being exercised in production.
That distinction matters because an application may contain libraries, drivers, and utilities that are never used in its execution path. Components such as command-line utilities and other packages can add vulnerabilities without contributing to the application’s functionality.
By understanding the runtime environment, security and development teams can isolate or remove unnecessary code and substantially reduce the number of vulnerabilities that require remediation.
DORA ultimately reinforces a broader shift in cybersecurity. The goal is not to discover more vulnerabilities; it is to reduce actual risk.
Organizations will continue to face new CVEs every day. Vulnerability management therefore cannot be a one-time project. It must become a continuous process spanning software development, deployment, runtime monitoring, and remediation.
For financial institutions operating under DORA, the strategic question is no longer simply, “How many vulnerabilities did we find?” It is: “How many vulnerabilities did we eliminate before they could become a threat?”
That shift from vulnerability management to vulnerability elimination puts security closer to the development process, reduces attack surfaces before applications reach production, and provides tangible evidence of operational resilience. In an environment where attackers move faster and software supply chains grow more complex, building resilience directly into the software lifecycle is ultimately more valuable than simply documenting the vulnerabilities that remain.
The author, Kamran Shirazi, is Vice President of Business Development at Rapidfort.