What Is VulnOps? Vulnerability Operations, Defined
The term, and who is using it
In April 2026, the Cloud Security Alliance, SANS Institute, and the OWASP GenAI Security Project published a briefing called The AI Vulnerability Storm. Its eleventh priority action put the function in plain terms:
"Stand up VulnOps," a function that owns "continuous discovery of zero-day vulnerabilities across your entire software estate" and that "establishes automated remediation pipelines," designed around triage discipline from the start.
The AI Vulnerability Storm, Cloud Security Alliance / SANS Institute / OWASP GenAI Security Project (April 2026), Priority Action 11
The word was older than the briefing. It had circulated informally in security-operations circles for years, and Heather Adkins (Google), Gadi Evron (Knostic), and Bruce Schneier reframed it for the AI era in an October 2025 essay. What the briefing added was a name and a working definition.
The term gets used a few different ways, worth separating before you go further.
• As a discipline. The CSA briefing treats VulnOps the way engineering treats DevOps or SRE, an operating practice rather than a product.
• As continuous scanning. Some vendors, like the managed-services firm Opsio, use "VulnOps" to mean scanning built into operations.
• As a command center. The Vulnerability Operations Center, or VOC, is modeled on the SOC, a centralized and often outsourced function that aggregates and orchestrates response across teams and tools.
None of these is wrong. They emphasize different parts of the same lifecycle.
The way we define VulnOps is close to the CSA's, just more specific about what running it actually takes. The same authors who named the discipline describe its mechanism as continuous discovery and repair run by AI agents at machine speed. In practice that means an agentic workflow. Software agents triage each finding for exploitability, draft a fix that matches the codebase, and record why it was handled that way, while engineers keep authority over what merges. That focus on execution is what most teams are missing, and it lives in the resolution layer.
Vulnerability Operations, or VulnOps, is the operating layer of a security program that ingests findings from every detection source, dispositions them under one exploitability and severity model, generates validated remediations against the codebase, and writes an auditable record of every step. The point of the function is throughput. A VulnOps practice lets a program resolve vulnerabilities at the rate findings arrive, instead of filing them into a backlog nobody clears.
Why this function is emerging now
Security teams have a find-versus-fix problem, and it predates the recent wave of AI-assisted offense. Detection got cheap and abundant. Resolution did not.
Most of that triage time goes to false positives, not real bugs. When inflow outpaces capacity, last quarter's unresolved findings are still open when this quarter's arrive, and the backlog compounds.
The unfixed 11 findings each month do not reset. At a constant 17-in / 6-out rate, one application carries 132 open findings after a year. (Contrast Security, 2025.)
AI changes the urgency, not the shape. As attackers use AI to compress the window between disclosure and exploitation, the cost of leaving findings open rises, but the bottleneck was already resolution. VulnOps is the name for closing that gap. For a deeper treatment of the find-versus-fix problem and how to work it down, see Pixee's backlog burndown playbook.
VulnOps is DevOps for vulnerability resolution
Before DevOps, shipping software was a batched, siloed handoff. Developers wrote code, threw it over a wall to operations, and waited. DevOps made deployment continuous, automated, and owned by a defined function with its own tooling and metrics. The work did not disappear. It became a pipeline instead of a queue.
VulnOps applies the same pattern to vulnerability resolution. The activity it owns, dispositioning findings and getting fixes merged, used to be a batched, manual handoff between security and engineering. VulnOps turns that handoff into a continuous, automated, owned pipeline with its own metrics. The naming convention is deliberate. The same move produced DevSecOps, MLOps, and FinOps, each one taking a previously ad-hoc activity and making it an operating discipline. In the VulnOps reading used here, the function sits downstream of detection: scanners feed it findings, and it decides what matters and gets it fixed.
Before VulnOps, resolution is a batched handoff that ends in a backlog. After, it is a continuous pipeline that keeps human merge authority at the checkpoint that needs judgment.
What a VulnOps function does
Strip away the framing and the function performs five concrete jobs.
Intake and normalization. Findings from every scanner enter one queue under one severity model. SAST, SCA, container, and infrastructure-as-code findings arrive in different formats with different severity scales. The function reconciles them at ingestion so the rest of the pipeline reasons about one normalized stream, not five vendor dashboards.
Triage as a gate. Exploitability, reachability, and compensating controls are evaluated automatically and continuously, not in a periodic human review pass. Findings that fail the gate never enter the remediation pipeline. Findings that pass become eligible for a fix. This is the step that controls noise. Reachability, the question of whether vulnerable code actually sits on a live execution path, is the contested part, and teams have been burned by models that overpromised, so trust in an automated gate gets earned per bug class rather than granted up front.
Remediation that merges. For findings that survive triage, the function generates a fix that matches the codebase's conventions, confirms the existing tests still pass and the change stays scoped to the fix, then opens it as a pull request against the right branch. Matching conventions means using the project's own libraries, idioms, and patterns instead of a generic snippet, which is most of what makes a reviewer willing to merge it. The metric that matters here is merge rate, not pull-request volume. A patch a reviewer rejects is not a resolved finding.
An auditable record. Every machine-judged step writes a disposition: triaged and dropped, fixed and merged, deferred, or escalated, each with a rationale. This is the system of record for why a finding was handled the way it was. It is what an auditor, a risk model, or a post-incident review points to, and in regulated environments that per-finding log is the kind of evidence SOC 2, PCI DSS, and the SEC's incident-disclosure rules ask for, not just operational hygiene.
Preserved human judgment. The function generates merge-ready candidates and tracks dispositions. Engineering reviews and merges. The per-finding triage burden goes away. The merge-decision authority does not. Machine speed does not mean no human in the loop. It means putting the humans at the checkpoints that need judgment. When a disposition is examined later in a post-incident review, the logged rationale has to show the decision was reasonable on the information available, not merely that a decision was recorded.
Triage and remediation are co-equal halves of the definition, and the market routinely splits them apart. A function that only prioritizes findings hands you a cleaner backlog. A function that only generates fixes floods your review queue. VulnOps means doing both under one model, with one record.
What VulnOps is not
VulnOps overlaps with several established categories, and the fastest way to define it is to draw the boundaries. Each adjacent category is organized around a different verb.
The VOC, or Vulnerability Operations Center, deserves its own line because the names look alike. A VOC is modeled on the SOC: a centralized, often outsourced command center that aggregates and orchestrates vulnerability response across teams and tools. VulnOps is modeled on DevOps: a continuous flow discipline embedded in how software gets resolved. A team can run a VOC and still lack a VulnOps capability, because centralizing and orchestrating is not the same as generating and merging fixes.
The operating-model spectrum
In practice, a VulnOps capability is a pipeline with a few defined roles and clear checkpoints. Findings flow in from detection. A triage gate runs continuously and drops the noise. Surviving findings move to fix generation. Engineering holds merge authority and reviews what comes through. Every step writes to the disposition record, which feeds the risk model and reporting.
Where the function sits is its own decision. A central AppSec team can own the triage model and the remediation policy while routing generated fixes to the squad that owns each repository. In a large organization, the hard part is usually the routing across dozens of product teams, not the fix generation itself, and a tool will not solve it for you.
Teams build that capability in one of three ways, and each carries a real trade-off.
There is no universally right answer. It depends on your engineering capacity, how much of the pipeline you want to own, and whether your binding constraint is people, tooling, or trust. The build-versus-buy decision in particular turns on fix quality, which is largely a context problem rather than a model problem.
A VulnOps capability is also measurable, which is part of what separates it from ad-hoc remediation. Triage drop rate captures how much noise the gate removes before an engineer sees it. Merge rate, not pull-request volume, captures whether generated fixes are good enough to ship. Time-to-resolution by bug class shows where the pipeline stalls. Disposition coverage confirms every finding has a logged outcome. A function that cannot report these numbers is not yet operating as a function.
Most organizations are already somewhere on a maturity curve.
• Implicit. An engineer reconciles scanner outputs in a spreadsheet. That is VulnOps work without the name or the automation.
• Tooled. Cross-scanner normalization and prioritization get automated. This is where many ASPM and VM deployments sit.
• Operating. The triage gate and fix generation run automatically, engineers keep merge authority, and the disposition record becomes a first-class system of record.
The point of naming the function is not to add headcount. It is to make resolution work visible, owned, and measurable.
Where VulnOps implementations fail
The honest version of any operating model includes how it breaks, and VulnOps breaks in fairly predictable ways. The triage gate carries a false-negative rate, which means it will occasionally drop a finding that turns out to matter, so the disposition log and a defined escalation path are not optional extras. Fix generation can pass the existing tests and still change behavior the tests never covered, or collide with another open pull request in the same sprint, which is why "the tests pass" is a floor and not a guarantee.
The most common failure, though, is human rather than technical. Once most generated fixes are good, reviewers start to rubber-stamp, and the occasional bad one merges because nobody is really looking. A function measured only on merge rate, with no attention to review quality or to tracking false negatives, optimizes its way straight into that trap. The integration layer is the other quiet cost, since every scanner added is another normalization and authentication project before a single finding flows.
VulnOps is one layer of machine-speed defense
Resolution is necessary, but a program that only resolves is exposed everywhere else. The CSA briefing is useful precisely because it does not stop at VulnOps. It groups its priorities into three layers, plus governance.
The other layers are not optional. Detection finds what is there, foundation limits the blast radius when something gets through, and governance keeps approvals fast and risk models honest. If your board reporting still assumes weeks between disclosure and exploit, it is working from numbers that no longer hold.
VulnOps is the resolution layer, one of three plus governance in the CSA framing.
That last point is the real "why now." The Zero-Day Clock built by Sysdig CISO Sergej Epp, which tracks median time-to-exploit across roughly 3,500 disclosure-to-exploit pairs from the CISA KEV, VulnCheck KEV, and XDB catalogs, recorded a collapse from 771 days in 2018 to 6 days in 2023 to about 4 hours in 2024. Those medians skew toward the high-value CVEs attackers prioritize, and most application findings are not zero-days, but the trend line is the point. A program designed for the 2018 number cannot survive the 2024 one. VulnOps closes the resolution gap, and detection, foundation, and governance are the rest of the program that makes closing it matter.
Median time from disclosure to exploit fell from 771 days to roughly 4 hours in six years. The window to resolve is closing faster than manual handoffs can. (Zero-Day Clock by Sysdig CISO Sergej Epp; CISA KEV, VulnCheck KEV, and XDB.)
Where Pixee fits
Pixee builds in the resolution layer described above. Our platform ingests findings across scanners, dispositions them under one exploitability model, and generates validated, merge-ready fixes, writing an auditable disposition at every step. Across the Pixee customer cohort, up to 95% of findings are dispositioned and dropped at the triage gate before an engineer sees them, and the pull requests that do open merge as-is at a 76% rate (the published merge-rate methodology defines the denominator and the cohort).
Both are cohort-wide figures. The 95% is an upper bound. The triage-drop rate you would actually see depends on your scanner mix and how noisy those tools are, and the merge rate moves with your codebase and review culture, so a team with mandatory multi-stage sign-off will see different numbers than a lean one.
We treat triage and remediation as co-equal, and the reason fixes merge at that rate is mostly context engineering, not raw model horsepower. Resolution is only one layer of the CSA model, and we work the prevention side too. Foresight reads a product spec the way a security reviewer would and pushes security requirements into the work before code is written, so fewer findings reach the resolution layer at all. Either way, this is one implementation of the VulnOps idea, not the definition of it.
Frequently asked questions
What is VulnOps?
VulnOps, short for Vulnerability Operations, is the operating layer of a security program that takes in findings from every detection source, dispositions them under one exploitability and severity model, generates validated remediations, and records an auditable disposition for each step. It exists so a program can resolve vulnerabilities as fast as they are found.
How is VulnOps different from vulnerability management?
Vulnerability management focuses on finding, prioritizing, and tracking weaknesses, where remediation typically means routing a ticket to a human owner. VulnOps owns the step that vulnerability management hands off: generating a validated fix and getting it merged, with a record of why. VulnOps assumes detection is largely solved and concentrates on resolution throughput.
Is VulnOps the same as DevSecOps?
No. DevSecOps is a culture and practice that shifts security checks into the build pipeline, producing findings early. VulnOps is the function that resolves those findings after they surface. DevSecOps is how you build securely. VulnOps is how you clear what the build process reveals.
Do I need a VulnOps team?
Not necessarily, and not yet for every organization. Run the three diagnostics above: count your scanner severity models, measure your triage throughput against the rate findings arrive, and audit your security pull-request merge rate by bug class. If findings outpace your ability to disposition and resolve them, you have the operational case for a VulnOps function, built in-house, bought, or run as a hybrid.
Related reading
• The VulnOps Playbook: machine-speed security against offensive AI
• Context engineering for security
• The security backlog burndown playbook
