Skip to main content
CybersecurityVulnerability Management

AI-Driven Patching Pressures Redefine Vulnerability Response

Cybersecurity team works in office setting with laptop and blurred screen.

"It took threat actors down to six hours and 40 minutes between the time a patch was being released with no known exploit in the wild and when somebody started exploiting the vulnerability." — Kevin Jones, Group CISO at Bayer

Six hours and 40 minutes: shrinking windows as LLMs scale discovery

Speakers at Infosecurity Europe opened with a stark metric reported by Kevin Jones, Group CISO at Bayer: vendors he spoke to estimated the mean time from a patch release to first public exploitation has fallen from days to hours, in one cited case to six hours and 40 minutes. That compression tracks with a broader technological change: OpenAI and Anthropic are expanding access to advanced LLMs — GPT5.5 and Claude Mythos — that show capability to autonomously find and even fix vulnerabilities at scale. The effect is to accelerate both discovery and weaponization, forcing defenders to reconsider routine assumptions about how long they have to test and roll out patches.

India’s CERT‑In sets a 12‑hour expectation; industry calls it decisive and difficult

India’s Computer Emergency Response Team, CERT‑In, has set aggressive expectations for remediation: patch actively exploited, internet‑facing vulnerabilities within 12 hours; exposed critical flaws within a day; and high‑severity bugs within five days. Andrey Lukashekov, head of revenue at Vulners, told Infosecurity that the mandate “sounds decisive.” He also warned that in large, global organizations such tight deadlines collide with time zones, approval chains and change controls, and can become “a logistical nightmare” that may impede safe remediation or encourage rushed fixes.

EU producer‑centric rules versus a US market model — Lukashekov and Price

Speakers contrasted policy paths. Lukashekov described the EU’s Cyber Resilience Act (CRA) as explicitly producer‑centric, forcing software makers to “own product security” through obligations for secure development, disclosure and user notification — an approach he called sensible because it aligns legal responsibility with code producers. Michael Price, VP of product engineering at VulnCheck, contrasted that posture with what he sees in the US: a more market‑driven, user‑focused model that often places the burden on customers and operators to defend themselves. Price said Europe is “trying to force responsibility upstream,” while the US approach combines market pressure, liability and voluntary standards rather than a single cadence.

Operational shift: exploit‑intelligence driven patching (Michael Price)

Price argued the old, linear model — scan, find, ticket, fix — is no longer adequate. He urged security teams to shift to exploit intelligence and operations: ask which vulnerabilities are being exploited in the wild, not merely which exist. “Typically, a small number of vulnerabilities are exploited in under 24 hours from publication,” he said, and organizations that want to remain secure “need to be able to respond to them in less than 24 hours.” Price warned that manual triage is breaking under volume and called for automation and vendor‑side tooling, and for relying on multiple, intelligence‑rich sources rather than a single catalog like NIST’s feeds.

Hardening, supply‑chain controls and practical takeaways (Lukashekov, Price)

Speakers urged defenders not to treat faster patching as a silver bullet. Lukashekov recommended assuming undisclosed CVEs exist and changing defensive posture accordingly: “Treat your perimeter like it’s already compromised.” That means stronger hardening, segmentation, runtime protections and improved detection and containment alongside patching. Price listed concrete supply‑chain mitigations: lock down developer environments, avoid local storage of secrets, route dependencies through vetted package registries, enforce cooldown periods, and use version pinning and package signing.

  • Assume unreported CVEs and design compensating controls (segmentation, runtime defense, detection)
  • Automate updates for commodity endpoints; treat CI/CD and bespoke apps with stricter release discipline
  • Build prioritized patch rubrics focused on exploitability and business impact, not just CVE age
  • Demand clearer SLAs and communication from producers while investing in internal mitigations
  • Strengthen coordinated disclosure workflows so discovery does not translate into unmanaged exposure

What this means for security teams, policymakers, and enterprise boards

Security teams: shift toward exploit intelligence, automation, and layered defenses; treat CI/CD and bespoke systems with special release discipline while automating commodity endpoint updates.

Policymakers and regulators: India’s urgency raises operational questions about feasibility; the EU’s CRA clarifies legal lines for producers but, as Lukashekov noted, “regulation can move the needle on accountability, but it won’t replace sound architecture and resilient operations.”

Enterprise boards and investors: industry sentiment reportedly shifted after Anthropic released Mythos as part of the Glasswing project, prompting boards to unlock budget and investors to favor cybersecurity firms — but Lukashekov cautioned that money alone will not resolve the debate over who is responsible.

Conclusion: the technical landscape — accelerated by LLMs that can locate and generate exploit code — is compressing the time available to respond. The policy tools chosen by India, the EU and the US move responsibility in different directions, but speakers agreed that faster patching must be paired with architectural change, better coordination with producers, and operational investments. As Lukashekov put it, “Patching isn’t dead, but it can’t be the only answer. Who pays to fix it is still very much up for grabs.”

Original story