An Introduction to VulnOps
- 4 hours ago
- 14 min read
What is VulnOps? Vulnerability operations is emerging as a discipline in its own right — not because the practices are new, but because AI-driven discovery has broken the operating model that used to contain them. We look at where the term came from, what it does and does not mean, and why nobody has folded it into DevSecOps.
Author:
Matt Austin
Client Portfolio Lead
In October 2025, three of the most respected names in security - Google’s Heather Adkins, Gadi Evron and Bruce Schneier - published an essay arguing that AI agents were automating the cyber attack chain, and doing so with ever-increasing speed. Within this article was a prediction, and a name for a practice that had not previously been coined – between research breakthroughs and enterprise adoption, they wrote, a new discipline might emerge: VulnOps. [1]
As of August 2026, the term has gained in popularity and now appears in vendor marketing, industry research and field guides. What it means, however, depends on who you ask - and the definition has already shifted once since it was coined. [2]
That matters, because the underlying problem is not academic. As we set out in our analysis of patching in the age of frontier AI, the window between disclosure and exploitation has collapsed, and most enterprises are still running a response process designed for a slower adversary. VulnOps is the name the industry is settling on for what replaces it. This article explains where the term came from, what the discipline actually involves, what it is not, and why it hasn't been quietly folded it into DevSecOps.
Contents
What is VulnOps?
VulnOps, short for vulnerability operations, is the continuous operational discipline of turning vulnerability discovery into verified risk reduction.
It links discovery and asset context to a governed response - one with named owners, SLAs, controlled execution, and confirmation that the exposure has been addressed. It treats vulnerability response as a continuous flow rather than a periodic queue, and it sits deliberately between security and IT operations.
What is the objective of VulnOps?
VulnOps has a single objective: cut the time a vulnerability stays exploitable on the systems that matter most, without breaking those systems in the process.
Traditional approaches to vulnerability management typically rely on metrics such as the volume and frequency of scanning, the number of open tickets, and the number of patches applied – the problem being these numbers describe how busy a team has been, but say nothing about how long an attacker had an open door, or whether it is truly now closed.
Where did the term VulnOps come from?
VulnOps entered public use in “Autonomous AI Hacking and the Future of Cybersecurity”, published in CSO on 8 October 2025 by Heather Adkins, Vice President of Security Engineering at Google, security entrepreneur Gadi Evron, and cryptographer and author Bruce Schneier. [1]
In their article, they set out the case that “hackers proved the concept, industry institutionalised it, and criminals operationalised it.” AI company XBOW had taken the top spot on HackerOne’s US leaderboard after submitting more than a thousand vulnerabilities in a few months. DARPA’s AI Cyber Challenge teams had found 54 new vulnerabilities in four hours of compute. Ukraine’s CERT had found malware using a large language model to generate reconnaissance and data-theft commands in real time. [1]
The key quote that should concentrate the mind of any CIO or CISO is this one:
“We have long taken it for granted that we have time to patch systems after vulnerabilities become known, or that withholding vulnerability details prevents attackers from exploiting them. This is no longer the case.”
The practices are not new - but the name is
Almost nothing inside VulnOps is a new invention. Every component practice already exists, and most are mature, standardised and decades old. What has never existed is the loop that joins them together, under a single owner, producing a single evidence trail.
In most enterprises today, discovery sits with security, asset context sits with IT operations, execution sits with infrastructure or engineering teams, approval sits with a change board, and verification typically doesn’t have a home. VulnOps is the name for closing that gap.
Why has VulnOps become a discipline in its own right?
If the components are old, the obvious question is why the term VulnOps crystallised in 2026 rather than 2016. Four forces changed, each compounding the other:
Frontier AI has industrialised discovery
For two decades, finding a novel vulnerability in widely deployed software required expertise and an investment of time, limiting the rate of discovery across the industry for attackers and defenders alike. These constraints have now been removed, and as we covered in our analysis of Mythos, leveraging Frontier AI models drastically reduces both the time and the level of skill needed to identify a new vulnerability.
Adkins, Evron and Schneier summarise it well: AI agents “don’t have to be better at a human task in order to be useful. They just have to excel in one of four dimensions: speed, scale, scope, or sophistication.” [1]
Whilst AI has dramatically reduced the time to discover vulnerabilities, it has not reduced the time for enterprises to respond. That response is still gated by asset knowledge, analysis and prioritisation, change windows, testing, approvals, and human coordination.
Public vulnerability data is now incomplete by design
Enterprises have long treated the National Vulnerability Database (NVD) as a reliable downstream source: wait for the record to be enriched, then act. That assumption has formally expired. NIST enriched 41,925 CVEs in 2025 — a 45% year-on-year increase, and the largest output in the database’s history — and still finished the year with a backlog covering most of the inbound queue.
On 15 April 2026 it announced a risk-based triage policy limiting full enrichment to
vulnerabilities in CISA’s Known Exploited Vulnerabilities catalogue, cyber security software designated under Executive Order 14028, and software in active federal use. [2] [4]
The practical effect is significant and under-appreciated: The majority of new CVEs now reach enterprise tooling without the CVSS scores, CPE identifiers and CWE classifications that scanners and patch management systems were built to consume.
Time to exploit < time to patch
Historically, the disclosure of a new vulnerability came with a defensible window to plan for and apply the patch required to remediate. It no longer does. Having a patching cadence for internet-facing systems that is measured in days or weeks is no longer fit for purpose. We explored what is needed to close that gap in our article on Patching Vulnerabilities in the Age of Frontier AI.
The estate is no longer entirely yours to patch
A meaningful share of any enterprise’s exposure now sits in software as a service, managed platforms, embedded appliances, operational technology, container images and transitive dependencies. In many of those cases the organisation cannot apply the fix directly, and must instead mitigate, isolate, escalate to a supplier, or accept and monitor with an expiry date.
A discipline built around “apply the patch” cannot govern an estate where applying the patch is frequently not an available move. VulnOps starts from the response decision, not from the patch.
What capabilities does VulnOps involve?
Stripped to essentials, a VulnOps capability does four things well:
It knows what it runs and who owns it
It makes a governed decision about each exposure
It executes that decision through a controlled path that can stop and recover
It proves, independently, that the exposure is gone or held below an approved threshold
The end-to-end VulnOps Process Loop
Every signal follows the same sequence - whether it concerns a vendor patch, an internally developed application, a cloud service, a container, an appliance or a headline disclosure. The SANS field guide sets out seven phases, each with a defined exit condition: [3]
Two decisions, not one
The response. What are we going to do about the exposure? Close it as not affected, remediate, mitigate, avoid, or accept temporarily. These map onto the risk-response taxonomy in NIST SP 800-40 Revision 4. [3] [7]
The execution route. How will that decision reach production, and under what controls? A standing preauthorised update, an expedited staged change, a normal staged change, a supplier-managed action, a specialist manual change, or emergency containment. [3]
The definition of "done"
VulnOps applies a deliberately demanding definition of done. The loop is closed only when the remediation or avoidance is complete, applicability is authoritatively disproved, or a verified mitigation holds residual risk below an approved threshold across the recorded scope. An independent query, rescan, runtime check or configuration test must confirm it. Supplier action alone is not sufficient. The record must carry the executor, the verifier, timestamps, evidence source, result and policy version. [3]
And critically: an exception never satisfies these conditions, and never stops the exposure clock. An acceptance is a decision to live with a risk for a defined period, with a named business owner and an expiry. It is not closure, and a VulnOps capability refuses to let it be recorded as one.
Governed automation
Because VulnOps exists partly as a response to AI-driven discovery, it has to be explicit about AI in the response path too:
Governance-in-the-loop (GITL). Leadership and accountable risk owners approve the rules before the event - eligible maintenance groups, exclusions, response targets, test requirements, rollout order, hold periods, health thresholds, stop conditions and escalation paths. It does not mean convening a change board for every preauthorised update.
Human-in-the-loop (HITL). A named practitioner decides when evidence conflicts, decision-critical data is missing, an asset falls outside preapproved policy, a safety or mission constraint applies, or a control fails - and records that decision with its evidence.
The governing principle is worth committing to memory: an AI recommendation is a hypothesis until it is verified, and any system that can change production is privileged infrastructure. An unrecorded verbal approval is not a control.
What is measured
VulnOps replaces activity metrics with flow and outcome metrics - in effect, site reliability engineering measures applied to vulnerability work. [2] Six metrics from the SANS field guide make for a great starting point:
Observed exposure hours - How many hours a vulnerability actually sat exploitable on your systems, from the moment you knew about it to the moment closure was proven.
Pipeline absorption ratio - Whether you are closing vulnerabilities faster than new ones arrive. Above one, the backlog shrinks; below one, it grows.
Triage latency - How long it takes from a vulnerability landing in your intake to someone deciding what to do about it and who will do it.
Change-failure rate - How often fixing a vulnerability broke something, and needed a rollback, a recovery, or an incident to be raised.
Verification rate - What proportion of the things you marked as closed were actually proven closed by an independent check.
Exception staleness - How many accepted risks have passed their expiry date and are still sitting open.
What VulnOps is not
With the term rapidly growing in popularity, it is important to establish how VulnOps differs from existing practices. VulnOps orchestrates and is the combination of several established functions, but does not replace any of them:
Discipline | What it owns | How VulnOps differs |
SecOps | Monitoring, detection, threat hunting and response to adversary activity, usually via a SOC. | SecOps responds to what an attacker is doing. VulnOps treats the conditions that make the attack possible, before anyone is in the building. Different trigger, different clock, different evidence. |
Vulnerability management | Scanning, enumeration, scoring, prioritisation and reporting of findings. | Vulnerability management produces the queue. VulnOps is the decision, execution and verification layer that empties it — and proves it. It also treats inbound rate, not team size, as the binding constraint. |
Patch management | Acquiring, testing and deploying vendor updates on a maintenance cadence. | Patching is one response of five, delivered through one of several execution routes. VulnOps governs the whole set, including exposures where no patch exists or none can be applied. |
DevSecOps | Security testing, dependency scanning and controls inside the software delivery pipeline. | DevSecOps governs code before it ships, in systems the organisation builds. VulnOps governs what is running in production, including everything the organisation bought, subscribed to or inherited. |
Attack surface management | Outside-in discovery of internet-facing assets and exposure. | ASM is an input to intake. It tells you what is visible. It does not decide, execute or verify. |
Incident response | Containment, investigation and recovery once compromise is suspected or confirmed. | Incident response owns containment and investigation. VulnOps retains the residual remediation, mitigation, avoidance and verification work afterwards. |
A product category | Not applicable. | VulnOps is an operating model. Scanners, SCA tools and patch platforms remain the instrumentation beneath it; what VulnOps reorganises is how their output is consumed and acted upon. |
Why not SecVulnOps, or DevSecVulnOps?
There are two primary reasons VulnOps is emerging as a discipline in its own right, rather than being shoehorned into existing working practices:
It sits between two owners, not inside either one
DevSecOps lives inside the software delivery value stream and is ultimately owned by engineering. SecOps lives inside the security function. VulnOps belongs to neither, because the work spans both and stalls precisely at the join. Security finds the exposure. IT operations controls the change window, the CMDB, the rollback and the maintenance group. Neither party can complete the loop alone, and in most organisations neither is accountable for the outcome end to end. It is the same gap our Cyber Resilience & Recovery practice exists to bridge.
This is the structural problem FinOps solved. Cloud spend became its own discipline not because the maths was hard, but because the decision loop was orphaned between engineering and finance. Vulnerability response is orphaned in exactly the same way, between security and IT operations. Naming it is how you give it an owner and a budget line.
It has a distinct decision loop
The trigger is a new vulnerability signal. The loop then runs from intake to verified closure. The definition of done is proof, not a closed ticket.
The original authors and subsequent industry research reached for the same analogy independently: that VulnOps would follow DevOps and site reliability engineering - both of which each began as informal labels for a set of practices before crystallising into recognisable disciplines with their own patterns, tooling and career paths. [1] [2]
Where to start with VulnOps
The single most common mistake is attempting an enterprise-wide rollout. It produces a programme plan, a governance forum and very little verified risk reduction.
The alternative is narrow and evidential. Identify the ten business transactions whose compromise or loss would cause the greatest operational, safety, financial, legal or customer impact, and select one to three for a pilot.
Map the applications, identity paths, data stores, infrastructure, cloud services, SaaS, endpoints, network controls, suppliers and owners each one depends on - the discipline we describe in our article on service mapping - and write executable tests that prove the transaction still works after a change. Then run one real signal end to end, through all seven phases, to verified closure. [3]
Expect the first loop to be a diagnostic rather than a delivery. It will expose missing owners, stale inventory, absent transaction tests, an unclear approval path, or a rollback nobody has rehearsed. That is the value. Fix the single change that would most improve the next run, then repeat on the same scope until it runs cleanly, and widen it one maintenance group at a time.
How Automiq can help
We work at the intersection of cyber, risk, IT operations and automation - the seam where vulnerability response consistently breaks down. VulnOps is less a new domain for us than a new name for the problem our service management, observability and automation work has addressed for years.
For a single view of how we help clients prepare for AI-enabled cyber threats, start with Frontier AI Threat Defence & Readiness.
Put ownership and accountability where the risk sits. The decision loop needs a named owner spanning security and IT operations - see Target Operating Model Design & Optimisation.
Establish the asset context the loop depends on. No VulnOps capability can match a signal to an owner without reconciled, dependency-aware data — see Observability Implementation & Integration and Service Mapping for Operational Resilience & Rapid Recovery.
Redesign change and release for hours-scale remediation. Execution routes, rings, canaries, stop conditions and tested rollback are process design as much as tooling — see Service Process Design & Interoperability.
Make the automation you already own do the work. Orchestration acting on reconciled data is what turns a decision into a controlled change — see Service Automation Platform Optimisation & Modernisation and Enablement of Service Automation AI.
Remediate the technical debt AI finds first. A structured programme closes the loop and shrinks the attack surface — see Cyber Vulnerability / Tech Debt Remediation and Remediating Vulnerable Legacy Business Workflows.
The bottom line
VulnOps is not a product, a platform or a rebrand of vulnerability management. It is the operating model that sits between finding a vulnerability and being able to prove you have dealt with it. Mythos and Frontier AI models have expedited the need for this capability to exist in a governed, managed way in its own right.
The term will keep evolving, however the organisations that wait for it to settle will spend that time attempting to manage a volume of vulnerabilities they cannot absorb. The organisations that will succeed in managing this threat are those that pilot the practice, complete their first loop, prove it works on something that matters, and widen it on evidence.
The attacker only needs you to be slow. Discovery is already automated. Response is the part you still own - and the part worth operationalising now.
Frequently asked questions
What does VulnOps stand for?
VulnOps is short for vulnerability operations. It describes the continuous operational discipline of turning vulnerability discovery into verified risk reduction — joining discovery and asset context to a governed response with named owners, target times, controlled execution, and independent proof that the exposure has gone. It is an operating model rather than a product category.
What is the difference between VulnOps and SecOps?
SecOps monitors for and responds to adversary activity — detection, threat hunting and incident handling, usually run from a security operations centre. VulnOps treats the conditions that make an attack possible, before any adversary is present. They have different triggers, different clocks and different definitions of success. Most organisations need both, and the two hand off to each other when compromise is suspected.
Is VulnOps just vulnerability management with a new name?
No. Vulnerability management produces the queue — it scans, enumerates, scores and reports. VulnOps is the decision, execution and verification layer that empties that queue and proves it. The two distinguishing features are the separation of the risk decision from the execution route, and a definition of closure requiring independent verification rather than a closed ticket. VulnOps also treats inbound discovery rate, rather than team size, as the binding constraint.
Why can organisations no longer rely on the National Vulnerability Database alone?
Because it has formally conceded that it cannot enrich everything. NIST enriched 41,925 CVEs in 2025, a record for the database, and still ended the year with a substantial backlog. On 15 April 2026 it adopted a risk-based triage policy limiting full enrichment to known-exploited vulnerabilities, software designated under Executive Order 14028, and software in active federal use. The majority of new CVEs now arrive without the CVSS scores, CPE identifiers and CWE classifications that scanners depend on, so programmes need multiple intelligence sources and exploitability signals such as CISA KEV and EPSS. [2] [4] [8] [9]
How do you measure whether VulnOps is working?
By flow and outcome rather than activity. The simplest and most revealing measure is saturation: the inbound rate of findings against the throughput of verified remediation, reported to leadership monthly. Beyond that, six measures work well — observed exposure hours, pipeline absorption ratio, triage latency, change-failure rate, verification rate and exception staleness. Scan volume, ticket volume and patch counts measure how busy a team has been, not how long an exploitable condition remained live. [2] [3]
What is “verified closure”, and why does it matter?
Verified closure means an independent query, rescan, runtime check or configuration test has confirmed the vulnerable condition is absent or controlled across the recorded scope, with executor, verifier, timestamps, evidence source and policy version recorded. It matters because reported completion and actual completion diverge more often than most organisations realise — and because an exception, however well documented, never satisfies closure and never stops the exposure clock. [3]
How long does it take to stand up a VulnOps capability?
A first pilot loop typically runs over eight to twelve weeks, covering one to three critical business transactions from intake through to at least one verified closure. Enterprise-wide coverage takes considerably longer and should be earned one maintenance group at a time. Attempting a full rollout from the outset is the most common and most expensive mistake.
Sources and further reading
[1] Heather Adkins, Gadi Evron and Bruce Schneier — “Autonomous AI Hacking and the Future of Cybersecurity”, CSO, 8 October 2025.
[2] Cloud Security Alliance Labs — “VulnOps: Vulnerability Management in the Age of AI”, research note, 4 May 2026.
[3] SANS — VulnOps Field Guide, August 2026.
[4] NIST — “NIST Updates NVD Operations to Address Record CVE Growth”, 15 April 2026.
[5] DARPA — AI Cyber Challenge (AIxCC), 2025.
[6] Google — “Google’s latest AI security announcements” (Big Sleep), 2025.
[7] NIST — SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning, April 2022.
[8] CISA — Known Exploited Vulnerabilities Catalog.
[9] FIRST — Exploit Prediction Scoring System (EPSS) and CVSS v4.0 Specification.
