Vulnerability discovery is accelerating, but finding flaws is no longer the only bottleneck. Organizations still have to decide which findings matter, test fixes, and deploy them without disrupting production. VulnOps proposes reshaping that work around continuous, AI-assisted operations. Its promise is faster response; its harder question is how much remediation can safely run without human approval.
The concept was introduced just over a year ago by Heather Adkins, Gadi Evron, and Bruce Schneier, before advanced AI models began uncovering vulnerabilities at a scale some have called the “vulnpocalypse.” Since then, the Cloud Security Alliance (CSA) has published a VulnOps operating model, and SANS has released implementation guidance and plans to introduce training. Practitioners are also testing the technologies that could support the approach.
For Gadi Evron, CEO and founder of AI security and data access governance company Knostic, the urgent issue is what happens after a flaw is found. “A lot of people are spending a ton of money finding vulnerabilities,” he says. “But the challenge is: What do we do once we find them? And that’s where it gets really complex.”
A change in operating model
VulnOps takes inspiration from DevOps, which brought software development and IT operations into closer coordination and replaced slower handoffs with continuous delivery and feedback. The analogy goes beyond adding AI to an existing vulnerability program. Advocates describe a shift in how organizations discover, rank, and remediate flaws, with automated systems handling more of the analysis and routine work.
Rich Mogull, chief analyst at the CSA, frames the change as a move from periodic processes to continuous ones. DevOps showed teams how shorter cycles and faster feedback could change software delivery; VulnOps applies a similar operating principle to vulnerability response. That could help organizations keep pace with a growing volume of findings, provided their systems can turn analysis into safe action.
Ed Skoudis, president of the SANS Technology Institute, expects AI to take the lead on much of the analytical work, with people overseeing the process. Chris Elgee, a SANS principal instructor and senior security analyst at Counter Hack Challenges, is less convinced that the concept defines a new discipline. “It feels like a rebranding to me,” he says. Organizations have managed vulnerabilities for years, he argues, even as the speed of discovery puts more pressure on existing programs.
That disagreement points to a practical test for VulnOps: whether it changes what teams can accomplish, not just how they describe their work. A system that produces more findings without improving prioritization or remediation would leave the core bottleneck in place.
Where automation meets operational risk
Automated remediation is the point where the model gets difficult. Patches can break compatibility, interrupt services, or disrupt systems that have been in maintenance mode for years. Ali Khan, CISO of device security company Iru, says security fixes can require changes to source code or third-party packages, and those changes may cause breaking changes. A patch that stops a business process can cost more than the vulnerability it was meant to address.
Mogull says current tools are not ready to automate remediation end to end. Under the CSA model, AI can act within policies set by the organization, while changes with a meaningful chance of disruption still need human intervention. Accountability remains with people, even when software makes routine decisions.
Skoudis describes this arrangement as “governance in the loop.” Organizations define a threshold for actions an AI system can take on its own. A critical patch for Windows workstations, for example, could be deployed in stages, with 25% of machines updated each hour or two over half a day. A higher-risk change would be held for human review. The right dividing line depends on each organization’s systems and tolerance for disruption.
Evron doubts that human review can remain part of most operations if discovery and attacks continue to accelerate. “One of the main understandings of the last couple of months is that human in the loop is dead,” he says, arguing that people cannot keep pace with the vast majority of actions. He also questions whether faster patching will be enough. “Patching is just not going to be fast enough,” he says. The longer-term challenge, in his view, is preparing for a security program that cannot depend on fixing every flaw after it appears.
Reduce dependence on the patch cycle
Evron sees autonomous patching as a step organizations should begin preparing for now, while treating it as a possible bridge to other defenses. He argues for reducing the number of vulnerabilities introduced in the first place, containing attacks while systems are running, and making individual flaws less dangerous through layered controls.
The first opportunity is in AI coding agents. Evron wants organizations to build security checks into those tools, so they can constrain how code is generated and scan it as it is produced, rather than waiting until it enters a traditional continuous integration pipeline. The goal is to catch problems closer to where they originate and reduce the volume that reaches later stages.
A second approach is runtime detection and response. Evron calls the idea “patch in place during runtime”: identify an attack through system logs and apply a change while the software is operating. He demonstrated approaches to this at the [un]prompted conference. The model could shorten the time between detection and containment, though it still depends on reliable detection and on changes that can be safely applied during execution.
Defense in depth is the third part of his argument. If multiple safeguards limit an exploit’s reach, a critical vulnerability may not require an immediate patch to prevent serious consequences. That doesn’t remove the need to fix flaws, but it could give teams more room to test changes and avoid rushed deployments.
What security leaders can do now
CISOs face two linked priorities: establish enough operational visibility to make automation safe, and give security and engineering teams a workable way to act together. Elgee points to a basic gap in many organizations: they may not have a complete inventory of their assets. Without knowing what systems exist and who depends on them, teams can struggle to judge the impact of an automated change.
Khan sees a coordination problem as well. Security teams can’t simply hand developers a queue of remediation tickets and expect the work to move faster. The teams need closer working relationships and a shared understanding of how security changes affect production systems.
Skoudis recommends starting with bounded automation rather than attempting an enterprise-wide transformation. Leaders can define which actions an AI agent may take independently, then reserve review for changes that exceed a business-risk threshold. That creates a concrete starting point: automate lower-risk, repeatable work and expand authority only where teams can support it with clear policies and operational evidence.
Evron argues that existing security teams can make the shift, but that tools focused on producing vulnerability reports won’t resolve the response bottleneck. His position is that organizations should build trust in autonomous patching in the near term while planning for defenses that reduce reliance on patching over time. The immediate measure of progress will be whether teams can safely turn findings into action at a faster pace—and whether their systems can limit damage when a fix can’t arrive in time.
