COMMENTARY: This past May,
Drupal pre-announced a critical security release and asked operators to prepare patching during its scheduled release window. We used
Claude Code to monitor the relevant branches and found that the patch itself revealed clues about what Drupal had fixed.
AI rapidly isolated those changes, recreated the vulnerable environment, and helped turn those clues into a working attack.
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
The time from patch publication to functional exploit was 51 minutes. The process wasn't fully autonomous, as at one point, Claude got stuck, and a human researcher had to intervene.
But without AI? I estimate that an expert researcher highly familiar with CMS platforms, PHP, and advanced SQL injection would have needed at least a couple of days to do the same.
Now, most organizations can't necessarily safely change production in a 51-minute window. A production change may still require dependency checks, staging, backups, rollback preparation, approvals, and a maintenance window. CIOs and
CISOs therefore need to treat the period between credible exposure and permanent remediation as a distinct operating state, rather than simply unfinished patching.
Unpatched and exposed vs. unpatched and mitigated
Traditional vulnerability management tends to have a fairly binary endpoint: a vulnerability remains open until the permanent remediation gets completed. I believe we need a meaningful distinction between “unpatched and exposed” and “unpatched and mitigated.” The goal: first reduce exploitability quickly, then remediate permanently and safely.
In the Drupal case, we didn't wait for a fully-developed public exploit. Their pre-announcement offered enough credible information for the team to prepare its research before the patch appeared. It let us “set a trap,” so to speak.
So the trigger for an organization's response procedure shouldn't necessarily be “a proof of concept appeared on GitHub.” Depending on the situation, we’d require a vendor advisory, CVE disclosure, security release notice, or other sufficiently reliable evidence indicating that an exploitable vulnerability may affect the environment.
Give the pre-patch state an owner and a procedure
Once we identify credible exposure, somebody needs authority to answer the most immediate question: What’s the fastest way to reduce exploitability? That work should begin before the organization finishes determining the full scope of impact or we can deploy the the permanent fix safely.
This cannot live solely with the security team. Security, application owners, and IT need predetermined authority and responsibilities before the emergency arrives.
Think of mitigation as a bridge, not a substitute for patching. When attackers can act autonomously and production changes still require human review, many organizations cannot deploy a permanent fix as quickly as exploitation can begin.
Interim mitigation isn’t optional: it’s how organizations reduce risk while the permanent fix gets tested and safely deployed. Options include restricting access to the vulnerable endpoint or functionality, a narrowly scoped WAF rule, or temporarily disabling an affected feature.
Deploying the control isn't enough. A team should validate it against the known exploit where possible, test relevant variants, ensure the vulnerable path was actually blocked, and confirm that legitimate application behavior still works.
Measure time-to-risk-reduction, not only time to patch
CISA’s Binding Operational Directive 26-04 requires federal agencies to use more context when prioritizing vulnerabilities, including reachability, exploitability, and potential impact. That same risk-based approach should apply to response metrics. Mean-time-to-patch matters. It tells us how long it took to eliminate the underlying vulnerability. But it doesn’t answer an equally important question: How long were we meaningfully exploitable?
A company might need four days to test and deploy a permanent patch. However, within four hours, it could implement and validate a temporary control, such as restricting access to the vulnerable endpoint, that blocks the relevant attack path. Another company could take the same four days to patch while leaving that path exposed the entire time. Traditional patch metrics would make those outcomes look identical even though the level of risk was very different.
The time-to-risk-reduction clock should begin when credible information becomes available, such as atypical behavior and movements at runtime, rather than only when a full public exploit appears. The clock can stop when the permanent patch gets safely deployed or when the organization validates an interim control that removes or blocks the relevant attack path.
Organizations also need to track both time-to-risk-reduction and time-to-permanent-remediation.
AI isn't eliminating the need for human expertise, nor does faster exploit development eliminate the need to test production changes carefully. AI makes it increasingly dangerous to assume those two processes will operate on compatible timelines.
CIOs and CISOs shouldn't respond by abandoning patch discipline or demanding impossible patch SLAs. But organizations do need a clear plan for what happens between learning the company’s at risk and safely deploying the fix.
The objective isn't to make every production change happen at machine speed: it's to ensure that when permanent remediation can't, risk mitigation can.
Itai Goldman, co-founder and CTO, Miggo SecuritySC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
