Patchmageddon Is Not Just a Patching Problem. It Is an Attack-Surface Problem.

J.P. Morgan's Patchmageddon report opens with an effective analogy: vulnerability disclosures are becoming the cybersecurity equivalent of tornado warnings. The warning may arrive only moments before impact, but organizations still need to act on it.

The problem is that those moments are disappearing.

The report says the average time between vulnerability disclosure and first exploitation has fallen to roughly one day, while organizational remediation times are moving in the opposite direction. It also notes that, in approximately 60% of breaches, a patch was already available when the organization was compromised.

This is not simply a warning about faster attackers. It is evidence that the traditional vulnerability-management model has reached its practical limit.

For years, the industry has focused on finding, scoring, prioritizing and assigning vulnerabilities. That approach made sense when discoveries arrived at a manageable pace and defenders had weeks or months to respond. It makes far less sense when AI systems can uncover previously unknown vulnerabilities at scale, attackers can quickly weaponize newly released patches, and security teams remain responsible for enormous, poorly understood dependency trees.

In that environment, generating a better list is not the same as reducing risk.

The Vulnerability Backlog Is Becoming a Structural Deficit

Two charts in the report tell the story. One shows attacker time-to-exploit falling below zero, meaning exploitation can begin before a patch exists, while organizational mean time to remediate approaches 100 days. The other compares 48,185 vulnerabilities disclosed during 2025 with only about 7,500 patched.

That is not a temporary backlog that can be cleared by hiring a few more analysts. It is a structural imbalance between the rate at which vulnerabilities are created or discovered and the rate at which organizations can understand, test and remediate them.

AI will widen that imbalance. The report describes frontier models that can identify previously unknown vulnerabilities across large codebases and connect low- and medium-severity weaknesses into entirely new exploit paths. Once a vendor releases a patch, AI can help reverse-engineer the change, identify the underlying flaw and produce a working exploit in minutes. Meanwhile, threat actors share tools and techniques through a decentralized ecosystem that often moves faster than enterprise change-control processes.

This is an important shift in the economics of cyber risk. Vulnerability discovery is becoming faster, cheaper and more automated. Remediation inside most enterprises is still constrained by:

• Maintenance windows
• Manual review
• Regression testing
• Incomplete inventories
• Understandable concerns about disrupting production

The attacker is operating at machine speed. The defender is too often operating through tickets, spreadsheets and scheduled meetings.

AI Is Not the Villain, It Is an Accelerant

The report is right to emphasize AI's dual-use nature. The same capabilities that allow a model to discover or exploit a weakness can also help validate the finding, propose a fix and test the remediation.

J.P. Morgan points to defensive tools from Anthropic and OpenAI that scan code, generate proposed fixes and work with maintainers to repair vulnerable open-source projects. It cites thousands of vulnerabilities patched or marked as repaired through these emerging workflows.

That is encouraging, but it does not eliminate the operational bottleneck. Producing a possible code fix is only one step. Organizations must still determine whether the vulnerable component is present, where it is deployed, whether the affected code path is reachable, whether the patch is compatible with the application, and whether the remediation reached every running instance.

AI can accelerate both discovery and remediation, but it cannot compensate for an organization that does not know what software it owns, what dependencies it has inherited or what is actually executing in production.

The competitive advantage will therefore come not from having the most findings, but from having the shortest reliable path from finding to protection.

Open Source Is Essential, but Unmanaged Software Sprawl Is Dangerous

The report's discussion of open source is particularly important. It estimates that 96% to 99% of commercial codebases contain open-source components and that approximately 77% of the underlying code in modern applications consists of prebuilt open-source libraries and frameworks.

This is not an argument against open source. Open source is one of the foundations of modern innovation. The issue is that organizations frequently consume it without fully understanding the resulting dependency graph.

According to the report:

• The average commercial application contains approximately 1,180 open-source components
• A typical JavaScript project may have only ten direct dependencies but 683 indirect dependencies
• An estimated 95% of open-source vulnerabilities reside in those transitive dependencies
• The median dependency is 278 days behind its latest major version
• Roughly 90% of codebases rely on obsolete code in some form

That is the real attack surface: not just the application developers intended to build, but everything that arrived inside the packages, frameworks, utilities, binaries and base images used to assemble it.

Organizations often treat all of that inherited software as unavoidable. Much of it, however, is never used by the application. It remains installed, detectable and potentially exploitable even though it provides no business value.

At the same time, maintainers are being asked to carry an impossible burden. The report says more than 23,000 potential open-source vulnerabilities were identified through one AI-driven initiative, including 3,900 classified as high or critical. It cites research indicating that vulnerability discovery was outpacing patching by 16.5 times, despite maintainers acknowledging most of the reported issues.

Faster Patching Is Necessary, Yet It Is Not Sufficient

The report recommends continuously updated asset inventories, robust vulnerability-management programs, faster change management, current software versions, better knowledge of third-party dependencies and shorter patch-testing and deployment timelines. Those are all sound priorities.

An equally important objective is to reduce the amount of software that needs to be patched in the first place.

Organizations should know not only what is installed, but what actually runs. An SBOM is an essential starting point because it establishes the complete inventory. Runtime evidence then helps distinguish components that participate in real application behavior from packages, binaries and libraries that are simply present.

That context should lead to action:

This does not make patching irrelevant. Anything required by the application still needs to be monitored, updated and protected. But reducing the software estate changes the economics of the problem.

Security Leaders Need to Measure Outcomes, Not Activity

In the Patchmageddon era, the number of scans performed, findings generated or tickets opened tells us very little about whether an organization is becoming safer.

The more meaningful questions are operational:

• How much unnecessary software has been removed?
• How many inherited vulnerabilities were eliminated rather than merely documented?
• How quickly can the organization determine whether a newly disclosed issue is actually present and reachable?
• What percentage of production workloads is built on actively maintained, hardened foundations?
• Can security teams prove that a remediation reached every deployed instance?
• Is the exploitable attack surface shrinking over time?

These measurements connect security work to risk reduction. They also give leaders a way to differentiate between vulnerability-management programs that produce more information and programs that produce measurably safer software.

Speed now matters as much as accuracy. But speed cannot come from asking already overloaded security and engineering teams to work an ever-growing queue faster. It must come from automation, runtime context, secure software foundations and the systematic elimination of unnecessary attack surface.

RapidFort is built around that operating model. RapidFort protects organizations at intake, build and runtime: Curated Near-Zero CVE Images and malware-scanned Curated Libraries reduce inherited risk before it enters the pipeline; RapidFort Analyzer produces an SBOM and validates vulnerability applicability; RapidFort Profiler creates an RBOM® showing what actually executes; and RapidFort Optimizer removes unused packages and dependencies without requiring application-code changes.

RapidFort reports that this approach can eliminate up to 99.9% of CVEs and reduce container attack surface by up to 90%, while its runtime and compliance capabilities provide continuous visibility and audit-ready evidence.

In practical terms, RapidFort turns Patchmageddon from an unbounded patch queue into a smaller, runtime-validated and continuously hardened software estate, protecting organizations by removing attack vectors before adversaries have the opportunity to exploit them.