Patches Can't Keep Up with Vulnerabilities? Cisco Executive on Security Defense in the AI Era

Title

Patches Can't Keep Up with Vulnerabilities? Cisco Executive on Security Defense in the AI Era

Meta Description

Cisco VP of Product Management Anton Chuvakin explains why traditional patch cycles fail as vulnerability exploitation accelerates in the AI era, presenting core ideas including the patch sound barrier, the one-year log retention rule, the CVE work-unit crisis, and agent governance, along with 30-day security action recommendations.

Article Content

When the window from vulnerability disclosure to exploitation compresses from months to days or even less, traditional patch cycles are failing. In an interview on the Simply Cyber podcast, Cisco VP of Product Management Anton Chuvakin (with 25 years of security research experience, formerly a Gartner research VP and a member of the Google Cloud CISO office) delved into how AI is reshaping the pace of attack and defense, and what defenders should truly focus on.

Exploitation Acceleration: But "Seconds" Is a False Premise

The interview opened with a sharp question: after a new vulnerability appears, how much time do you have? Cisco's guidance documents have hinted it could soon be minutes or even seconds. Chuvakin is skeptical: "I don't think seconds is realistic, because even if a model runs in seconds, no one can find a vulnerability in a few seconds."

But he confirmed an industry consensus—attack acceleration began long ago, and predates the emergence of large language models. Cisco's own reports, Mandiant's M-Trends, and Verizon DBIR data all corroborate this trend. The real problem isn't the speed of vulnerability discovery, but a bottleneck he calls the "patch sound barrier."

The Patch Sound Barrier: Why Enterprise Patch Cycles Are Stuck at Months

The "patch sound barrier" concept Chuvakin proposed during his Gartner years is key to understanding the enterprise security dilemma. He uses the analogy of a propeller plane breaking the sound barrier: no matter how much horsepower you add, patching in a traditional architecture simply cannot exceed a certain speed threshold. "For a typical bank or manufacturing company, the patch deployment timeline is often measured in months, and for complex systems even in quarters."

What is the "jet engine" that breaks the sound barrier? Chuvakin's answer is unexpected—not AI, but modernization. Containers, microservices, and cloud deployment allow systems to be rebuilt from a pipeline in minutes, and this speedup was achieved before AI appeared. For enterprises heavily using third-party software such as Oracle, SAP, or Windows, modernization helps only marginally; in such cases they should turn to "mitigation" rather than fixating on patches.

He designed a thought experiment: the "15-minute patch experiment"—assume all patches can be deployed within 15 minutes, and work backward to determine what conditions must hold. This experiment won't actually let you achieve 15-minute patching, but it can expose where the real bottlenecks in your organization lie.

Patch sound barrier is a metaphor Chuvakin proposed during his Gartner years, borrowed from the sudden increase in drag encountered by propeller planes approaching the speed of sound in aviation history. In the context of security operations, it refers to a speed ceiling in enterprise patch deployment processes that is difficult to overcome: no matter how much manpower or how many tools are invested, the typical time from patch release to full deployment in production is still measured in months or even quarters. The causes of this bottleneck are not singular but the result of multiple layered processes—change management approval, compatibility testing, rollback plans, downtime window coordination, and more. The key to breaking the sound barrier is not to "add horsepower" to existing processes, but to change system architecture—containerization, immutable infrastructure, and infrastructure as code enable environments to be rapidly rebuilt from a pipeline, thereby bypassing the traditional path of patching machine by machine. Understanding this concept helps explain why simply purchasing vulnerability management tools often yields limited results.

Does AI Lower the Attack Barrier? Industry Divisions Are Clear

The Cisco team has said that AI lowers the skill barrier for attackers. Chuvakin shows cautious skepticism. He describes a spectrum of attacker capability: from top attackers equipped with top AI, to fully automated agentic attacks, to pure automation scenarios with "no attacker at all."

"I lean toward thinking that a mid-level attacker, even with top-tier AI, would still struggle to carry out truly sophisticated intrusions, because friction in enterprise environments hinders defenders and attackers alike." He admits this is a divisive topic and that he is closer to the "increased risk but no apocalypse" camp.

Regarding the "vulnerability apocalypse," Chuvakin offers his own definition: not just an increase in the number of vulnerabilities, but an increase in vulnerabilities, an increase in exploitation, and an increase in incident damage all occurring at the same time. "If the number of vulnerabilities explodes but they aren't exploited, that's just more patching work, not an apocalypse." He notes that hype currently outpaces reality, but whether that means the hype is wrong remains an open question—because defenders must prepare for two different futures.

Why Basic Controls Matter More in the AI Era

When asked why, even after attackers gain AI superpowers, phishing-resistant MFA and patching remain the top recommendations, Chuvakin acknowledges the opposing view: some argue that in the age of agentic attacks, basic controls are meaningless because "agents will always find a way." But he believes this defeatist view lacks data support.

His core argument is not "do basic controls" but "comprehensively verify that basic controls are truly everywhere." Using AI or agents to continuously assess whether configuration management and MFA truly cover every corner is more critical than simply deploying those controls. He specifically mentions a detail: physical security keys require pressing a button, which machines cannot do, giving phishing-resistant MFA unique value against autonomous agents.

Phishing-resistant MFA refers to authentication methods based on the FIDO2/WebAuthn standard, typically in the form of physical security keys or platform-built-in passkeys. Its fundamental difference from SMS codes and push confirmations is that authentication credentials are bound to a specific origin, so even if an attacker impersonates a login page, they cannot trick the user into using the credential on a malicious site, thereby eliminating the possibility of man-in-the-middle phishing at the protocol level. Chuvakin specifically notes that physical security keys require the user to press a button to complete authentication, an action that depends on human presence and intent and cannot be forged by an autonomously running AI agent. Amid growing concern about agentic attacks, this physical constraint makes phishing-resistant MFA one of the few basic controls with structural defensive power against automated attacks.

Logs: Everyone Has Them, Very Few Do Them Well

As "the person who wrote the book on logging," Chuvakin considers logs the most overestimated coverage item. Nearly every enterprise will say "we have logs," pointing to a SIEM or MDR service. But when incident response consultants come in to investigate, they often find that critical DHCP logs, outbound traffic logs, or east-west traffic logs are precisely what's missing.

"The gap between doing it and doing it well is enormous." On retention periods, he gives his famous "3 a.m. test" answer: one year. "Can you cite cases that need more than a year of data? Yes. But for most data, one year remains a good rule of thumb. If you can't even do one year, I'd suspect there are problems elsewhere too."

CVE Is No Longer a Unit of Work

Cisco proposes that the "one bug, one CVE" model is collapsing. Chuvakin explains that when vendors use LLMs to scan code and fix vulnerabilities in bulk, it's impossible to assign a CVE to every internally fixed vulnerability. There are also scenarios such as exploitation without a CVE, CVEs lagging behind exploitation, and one CVE corresponding to multiple patches.

"If the calendar said 2006, one bug one CVE would be a good idea. If not, you'll run into trouble." He believes that treating CVE as a unit of work rather than an identifier string is the root cause of many failing vulnerability management programs.

CVE (Common Vulnerabilities and Exposures) is a public vulnerability identification system maintained by MITRE that assigns a unique number to each disclosed vulnerability for cross-vendor, cross-tool tracking. Its original design intent was to provide unified naming and indexing, not to measure an enterprise's actual risk or drive remediation scheduling. When vendors use LLMs to scan and fix code in bulk, a large number of internally discovered and fixed defects never enter the CVE process; meanwhile, there are cases where exploitation has occurred but no CVE number exists, where CVE publication lags behind actual exploitation, and where a single CVE corresponds to multiple patches. Treating CVE as the unit of work in vulnerability management causes teams to chase numbers rather than real exposure, to overlook unnumbered but exploited risks, and to disconnect remediation scheduling from vendors' actual patch cadence.

Agent Governance: Only Lean Agents Can Talk About Least Privilege

On AI agent governance, Chuvakin borrows a framework from a former employer to draw a key distinction: workforce agents (employee assistants, with permissions analogous to employees) versus workload agents (business process agents, analogous to non-human identities). The former should be sub-identities of employee identities, while the latter should be governed as NHIs.

He emphasizes "no fat agents": if an agent's mission is broad enough to cover HR, IT, and finance, least privilege becomes impossible because you cannot describe what it can do and what should be restricted. Narrowing an agent's mission is the only way to achieve tool-level and data-level least privilege.

Non-Human Identity (NHI) refers to identity credentials held by software systems rather than natural persons, including service accounts, API keys, workload certificates, CI/CD pipeline tokens, and the runtime identities of AI agents. Unlike employee identities, NHIs typically have no interactive login, weak lifecycle management, and permissions that are easily over-granted and rarely rotated, making them a common springboard for attackers' lateral movement. Governing workload agents as NHIs means establishing a separate identity inventory for them, clarifying accountable owners, implementing credential rotation and permission reduction, and incorporating them into audits as rigorous as those for employee identities. This framework provides an actionable governance lever for implementing least privilege for agents.

Future Skills for Security Practitioners

For the future of the SOC, Chuvakin points to the "detection and response engineering" model—humans build machines, and machines build more machines. Alert triage is currently the most visible area of automation; he believes 99% automation is achievable, but 100% automation is unrealistic.

His advice for newcomers has two layers: in the short to medium term, AI security skills "pay the bills"; in the long term, critical thinking and understanding the underlying principles of technology are the enduring capabilities. "Many people discuss whether LLMs are conscious, which shows they don't understand computers."

Action Recommendations: What to Do Within 30 Days

Chuvakin gives three priorities: first, focus on mitigation rather than fixating on patches, layering multiple mitigation controls over legacy systems that cannot be patched quickly; second, understand how agents are operating in your environment—including shadow agents, the topic of his RSA 2026 talk; third, edge devices must be patched, there is no magic, "you can't mitigate a firewall with a firewall."

One-line Summary

Chuvakin on the pace of attack and defense in the AI era: break the patch sound barrier through modernization, and comprehensively verify basic controls.

Paragraph Summary

Based on an interview with Cisco VP of Product Management Anton Chuvakin, this article explores how AI is reshaping the pace of attack and defense. Chuvakin argues that "second-level vulnerability exploitation" is a false premise, but attack acceleration began long ago; the real bottleneck is the "patch sound barrier" in enterprise patch deployment—breaking it depends on system modernization rather than AI, and legacy systems should shift to layered mitigation. He is cautiously skeptical that AI significantly lowers the attack barrier, believing a "vulnerability apocalypse" requires vulnerabilities, exploitation, and damage to surge simultaneously. On the defense side, he emphasizes that the key to basic controls lies in comprehensive verification rather than superficial deployment; phishing-resistant MFA has unique value against agent attacks due to its physical button constraint; logs are a universally covered yet rarely well-executed area, and one-year retention remains a rule of thumb; CVE should not be treated as a unit of work. Agent governance requires distinguishing workforce from workload categories and narrowing missions.