G-gravity

Simply "applying patches faster" isn't enough. What's needed is smarter patch management.

The approach of applying patches every 30 days is no longer viable. Most security teams already know that much. But they don't understand why it's no longer viable, or what needs to be replaced.SC Media recently brought together security leaders from various positions to discuss this very transition.The situation described there was dire.

AI has not only increased the already vast number of vulnerabilities, but it has also reduced the time from disclosure to exploitation from weeks to hours. A patch released by Microsoft in July fixed more than 600 bugs in a single Patch Tuesday, just the previous month when it had fixed a record 206 flaws. In the same week, CISA ordered emergency patching of Oracle E-Business and Microsoft SharePoint, and investigators recorded a series of ransomware attacks that were carried out in less than 24 hours from start to finish.
 Recent research by the Cloud Security AllianceThe numbers illustrate this predicament: Only 91 TP3T organizations fix critical vulnerabilities within 24 hours. Of the teams that take 4 to 7 days to fix vulnerabilities, 971 TP3T report incidents linked to known vulnerabilities during that time. The time between vulnerability disclosure and exploitation is not getting shorter; it's already gone.
Faced with these numbers, it's clear that increasing the number of analysts or extending working hours were never going to be a solution from the start. The answer is to decide what's truly important before patching anything else.

Most of the things that have been patched were not a threat to begin with.

Every scanner will display a large number of detection results classified as "critical." However, only a small fraction of these are actually accessible within a company's environment. Security researchers believe that, considering the actual network topology and code path, only about 1% detection results are truly exploitable.
 Mend Reachability AnalysisThis assessment is based on the following: The question is not whether the vulnerability is serious or not. What really determines the risk is whether an attacker's path can reach this code at runtime. A critical CVE in a function that is never called is not a serious problem. Conversely, a moderate CVE at an entry point exposed on the internet is a more serious problem.
This is where triage relying solely on CVSS falls apart. The National Vulnerability Database has stopped providing detailed information for most CVEs. As a result, severity scores alone now miss approximately one-third of the vulnerabilities that are actually being exploited. On the other hand, combining reachability with exploit intelligence such as CISA's Known Exploited Vulnerabilities (KEV) catalog and EPSS scoring allows us to provide a concise list of risks rather than a long list. Rushing to patch code that attackers cannot access is nothing more than wasting our most scarce resources and time on the wrong targets.

The countermeasures must be aligned with the speed at which vulnerabilities are disclosed, not with the pace of internal ticket processing.

A recent survey on vulnerability response workflows revealed that 74% organizations still perform more than half of their remediation manually. Only 7% reported being fully automated. What teams have automated is the alerting process, not the response. This is the real bottleneck. Unless the approach to remediation changes, the detections generated by AI will only increase, rather than reduce, the backlog.
The solution isn't calendar-based patching with shorter calendars. What's needed is a closed loop that constantly repeats the process of detecting, prioritizing, addressing, and verifying. This loop is designed to run through this process.Mend Remediateis.
Prioritizing should combine the exploit, the state of vulnerability, and the business context. CVSS scores should not be used in isolation. Low-risk, repeatable fixes should be pre-approved so they don't require manual clicks for each one. If no patch is available, the team needs readily available alternatives—virtual patching, configuration changes, or segmentation rules to close attack vectors without waiting for vendors. Processing a ticket is not the same as resolving vulnerability. Every fix should be verified with automated rescans to ensure the risk in the environment has actually been eliminated.
These systems are designed to support human judgment, not replace it. Policy formulation, risk tolerance assessment, and exception handling will continue to require human intervention. AI will handle routine tasks that can be self-verified, allowing humans to focus on the decision-making that truly matters to them.

Dependency updates should not be a quarterly project.

A significant portion of what the security team patches isn't even the application's code itself; it's the open-source software dependencies hidden behind the application. These are constantly being updated at their own pace, whether the team is aware of them or not.
 MendRenovateThis keeps the update pipeline continuous, not intermittent. In projects where dependencies are upgraded in batches quarterly, the updates are already outdated by the time of shipment. Instead, updates are constantly proposed, tested, and merged. The scope is limited to what is actually safe to change. Combined with reachability data, Renovate can prioritize updates that close exploitable paths rather than processing the dependency tree alphabetically.
This transforms patch management from a frantic, periodic task to a continuously evolving system. The update pipeline will keep running regardless of whether the number of CVEs this week reaches a record high.

Increasing speed without making a judgment only shifts the risk to another location.

The teams that are best coping with this shift aren't the ones patching the fastest. They are the teams that can answer two questions in minutes, not days: Is this achievable? And is it important now? Everything else, including the actual fixes, depends on correctly answering these two questions.
That's why reachability, automated dependency management, and continuous remediation need to be treated as one connected system, not three separate tools pieced together after the fact. AI has increased the cost of relying on guesswork, but it hasn't eliminated the need for judgment. AI has simply accelerated the timing of judgment. Now, decisions are made as soon as detection results are available, rather than when personnel are finally about to take action.
The grace period given to apply the patch is gone forever. Successful teams have built their systems assuming there is no such grace period.