Introduction

The arrival of Mythos changed the pace of vulnerability work. Anthropic's Mythos Preview, which only a small group of trusted organizations can use today, belongs to a class of AI models able to find software weaknesses and chain them into working attacks faster than any team of people can follow. Attackers should expect to hold comparable tools soon, and with them they can scan an entire estate, link weaknesses across components, and start an attack with little human involvement. The window between discovery and exploitation has shrunk to under ten hours, and a program built on tickets, sprints, and monthly patch cycles cannot close findings inside it.

VulnOps is the practice of running vulnerability management as a continuous operation that finds, prioritizes, and closes findings at the speed attackers now work. Building it in one jump asks too much of most organizations, so this guide splits the path into three stages, each producing value on its own and preparing the ground for the next.

• Stage 1, A More Efficient and Focused Vulnerability Management Program, filters findings by consequence, reachability, susceptibility, and damage so people only see what needs attention.
• Stage 2, A Hybrid Vulnerability Operations Team, adds AI agents that close mechanical fixes at machine speed while engineers handle the findings that need judgment.
• Stage 3, An Autonomic Vulnerability Operations, adds a dedicated team that runs agents as the primary remediation engine across the whole estate.

Each stage takes roughly a year to build. Stage 1 depends mostly on process changes and on connecting data the organization already holds, Stage 2 depends on hiring two people and proving an agent in a monitored environment, and Stage 3 depends on building a team of about seven and extending agent coverage to every system. More resources and a firm commitment from company leadership can shorten each stage, and a company that starts hiring for Stage 2 while Stage 1 is still underway can shorten the total timeline considerably.

Stage 1: A More Efficient and Focused Vulnerability Management Program

Stage 1 gives the organization a program that ranks vulnerabilities by what they threaten, and it comes first because every later stage depends on the data it produces. Agents and people can only move fast when they know which findings deserve speed, and CVSS cannot say that, since it describes a flaw in isolation and says nothing about the system carrying it.

The program starts from the consequence map. Before any scanner runs, security and business owners set a consequence tier for each system in the inventory. A payment system or a customer data store sits in the existential tier, an internal reporting tool sits lower, and the tier travels with the asset through every later step, setting how fast a finding needs to move regardless of its CVSS score. Two rules apply throughout, everything gets recorded somewhere the whole team can reach, so no control depends on one engineer's memory, and anything tagged existential gets fixed on a set, fast timeline with no case by case negotiation.

Every finding then passes three checks before a ticket opens. The first is reachability, which asks who can reach the vulnerable component from outside and what that component can reach once an attacker controls it. Answering both questions requires one authoritative record, kept in a configuration management database or a structured shared record with fixed fields, and fed on a recurring schedule with real configuration data from cloud provider consoles and firewall management systems. An external exposure scan compares public addresses and domains against what should be open to the internet, and an internal path analysis traces what an attacker could reach after getting inside, which is how a system with no public exposure turns out to sit one hop from a critical database. In general, platform teams tend to resist giving a scanning process broad access to firewall and cloud configuration, so ask for a scoped/focused read-only access with logged queries, that way there is an audit trail settling the concern. Everyone wins. The record stays current when its upkeep attaches to a step that already exists, such as a deployment pipeline stage or a required field on a firewall change request.

The second check is susceptibility, which confirms that the running application loads the vulnerable dependency and executes the flawed code path. A software composition step in the build pipeline produces a software bill of materials on every build and flags known vulnerabilities against it, while runtime visibility shows which flagged functions the application calls under realistic traffic. Functions that never run drop out of the priority queue and functions called on every request move forward, with pattern based tooling proposing answers on large codebases and an engineer confirming the most critical ones. Teams with fragile pipelines accept the scan more readily when it first runs in report-only mode, and keeping every finding in security's queue until it clears this check means the first thing a developer sees has already been confirmed as real.

The third check is damage, which estimates what exploitation would cost through the sensitivity of the data, the privilege level the system runs under, and the time it takes to restore after a rebuild. Data owners supply classification during onboarding, identity data already pulled for reachability supplies runtime privilege, and restoration exercises supply recovery time, run at least quarterly on existential and high recoverable systems so a measured result replaces an estimate. Once those three values sit on the asset record, a new finding inherits its damage score the moment it appears, and a senior security reviewer only decides whether the specifics of that finding change what the tier already implies.

A finding that clears all three checks and appears on the Known Exploited Vulnerabilities catalog or carries a high exploit prediction score becomes a ticket, and everything else goes to scheduled maintenance or a lower priority ticket scaled to its tier. Each ticket describes the attack path in plain language, the access an attacker needs, what the attacker gains, the exact file, package, or configuration flag responsible, and a specific fix, with infrastructure fixes routed to the team that owns the infrastructure. The pipeline rescans the fix in staging, and the ticket closes only when the scan confirms the vulnerable path is gone.

Ownership splits three ways, with security owning the tiers, the scoring logic, and the exception process, development owning fixes and timelines for the services it runs, and IT/Infra owning infrastructure and operating system patching. Exceptions need a documented reason, a compensating control where one exists, and an expiration date, and exceptions on existential or high recoverable systems need approval from a CISO or VP of Security and ownership by the most senior executive of the affected department, since security calls out risk and does not own it. Measurement covers time to remediate by consequence tier, the share of findings closed through manual override, which points to scoring logic that misses something, and the count of open and expired exceptions.

Teams that want faster results while this work proceeds can set up a shared tracker in the issue system they already use, with fields for the finding, the owning team, the agreed close date, and the escalation status, and can build a fast lane that deploys patches on critical systems within forty-eight hours outside the monthly cycle. Stage 1 produces a small, trustworthy list of findings and, just as important, the consequence map, the reachability record, and the damage values that Stage 2 uses to decide what an agent may fix on its own.

Stage 2: A Hybrid Vulnerability Operations Team

Stage 1 sharpens the list, yet an engineer working a four-hour weekly block still cannot answer a critical finding as quickly as the threat requires. Stage 2 closes that speed difference by running two tracks in parallel, one for machine speed and one for engineer speed, without requiring a large new team.

The automated track covers a narrow class of mechanical fixes defined in advance. That class includes dependency updates with a known safe version, container image rebuilds against a patched base image, configuration values with a single correct setting, package updates known not to break anything, and CVE patches that change one file with no architectural effect. An AI agent watches the scanning infrastructure continuously and acts as soon as a finding falls inside that class. It opens the change, runs the existing automated test suite, and submits the result for a single human approval before production. The reviewer only confirms that tests passed and the change belongs to the authorized class, so approval takes minutes. When tests fail or a finding falls outside the class, the agent stops and routes the item to the human track. The agent makes no judgment calls, and its guardrails come from the build pipeline the organization already trusts, which keeps a human involved in everything beyond the defined boundary.

The human track serves every other finding. Each one goes to the engineer who owns the affected system, and security delivers a daily prioritized queue in which every item is fully described, weighted by consequence, and pre-drafted with a proposed fix where possible. Engineers receive ready-to-act items and close them without triaging anything themselves. Teams whose systems appear on the consequence map hold a block of four to eight hours per week for this work, protected by the CTO and CIO, and teams outside the map follow the normal sprint process with a tighter timeline, with critical vulnerabilities fixed within 24 hours of discovery. A team that meets an existential or high priority system outside the map updates the map, and a system that was wrongly marked as high priority moves to the automated track over time.

Most routine findings, such as dependency updates, configuration drift, and known patch applications, belong to the automated track, which frees engineers to spend their protected hours on findings that need knowledge of their systems. The track expands one fix class at a time, only after it has shown consistent accuracy on that class, and anything discovered along the way feeds back into the filters or moves a class back to the human track.

Two people are needed to run this safely. The first is an AI operations specialist, maybe a new hire or an existing AI expert, who owns the agent infrastructure, the guardrails, the monitoring that catches an agent acting outside expected limits, and the authorization policy that lists every fix type the agent may apply. This person needs real production experience with AI agents and enough security judgment to evaluate whether an agent's action fits its context. The second is a program lead, who can come from inside the company, and who owns the human track, the daily queue, the timelines, the escalation path, the monthly review, and the consequence map in coordination with security. Credibility with senior leaders and enough technical fluency to judge whether a delay is justified are the qualities this role needs. Stalled findings, vendor patches, and cross-team agreements can sit with the program lead at launch and become a part-time role if the volume grows.

Leadership commitment is critical here and it keeps both tracks running. The CTO, CIO, and the CISO sign the authorization class document together before the automated track starts, and the CTO and CIO see every automated change that reaches production in the same daily health check they receive for the human track. A P1 finding not acknowledged within four hours of delivery goes to the relevant SVP, who has 24 hours to confirm an assignment with a committed close date or to document a risk acceptance with a name on it. The CTO and CIO attend a 30-minute monthly review of open P1 and P2 items, the trend in mean time to close, findings that reached exploitation before the program closed them, and any change to the authorization policy or the map. If the weekly block gives way to roadmap pressure, the human track stalls and the program covers only what the automated track can reach, so both tracks need that protection.

The tracks launch separately. The human track can start within weeks, as soon as the program lead is in place and the daily queue runs. The automated track waits until the AI operations specialist is hired, the authorization document is signed, an agent is selected, and the agent has run in test and read-only mode in a monitored environment long enough to earn that specialist's confidence. The data from the first months of the human track shows which finding classes close quickly and which stall, and that data tells the authorization policy where to begin. Starting with dependency updates alone and expanding from there carries less risk than starting broad and pulling back after an agent causes a problem.

Stage 3: An Autonomic Vulnerability Operations

Stage 3 gives the organization a function that owns the whole path from discovery to closure at the speed attackers move. In earlier stages the work still passes between security, engineering, IT, and infrastructure, each doing its part well, and a critical finding in a shared dependency can sit for days before the right engineer sees it. Against an exploitation window under ten hours, that handoff time decides the outcome. A dedicated VulnOps team removes it.

The team reports to a senior technology leader outside the CISO's chain of command. Security needs independence and sometimes an adversarial stance toward partner teams, so its requests arrive as compliance findings, whereas a request from a peer function arrives as a shared operational problem. When VulnOps asks IT to patch a server, the request should be received the way a production incident is received. VulnOps takes the consequence map and risk priorities from security, returns every finding to security, and works closely with incident response, so the two functions stay interdependent and organizationally distinct.

VulnOps carries several responsibilities. Continuous discovery runs static and dynamic analysis, software composition analysis, container image scanning, infrastructure-as-code scanning, cloud posture management, external attack surface management, and endpoint and server scanning, all feeding one tracking system where every team can see each finding from discovery to closure. Triage starts from the assumption that any findable vulnerability will be exploited, so the questions become how bad the outcome is and how exposed the system is. The consequence map and exposure analysis answer them, and a medium-severity finding on a top-tier system outranks a high-severity finding on an isolated internal tool. A P1 finding calls for mitigation or isolation within four hours and full remediation within 24, P2 closes within 36 hours, P3 within two to three days, and P4 carries a documented risk acceptance reviewed monthly. The triage criteria themselves get a monthly review, because standards calibrated six months ago may already misjudge the current risk, and the queue runs continuously with no sprints.

Remediation follows the Stage 2 pattern at larger scale. Agents handle the default path, from detecting a finding to generating the fix, validating it, and submitting it for a single human approval, and the on-call engineer receives a notification that a P1 was handled rather than a request to start work. When an agent's confidence drops below the defined threshold, when no automated validation exists, or when the fix needs an architectural decision, the agent hands off to a human with full context, so a P1 that needs judgment reaches a person within minutes. Findings outside agent authority go to a team that owns this, and a stalled item goes to the engineering director or IT manager and then to a senior VP within 24 hours. The fourth responsibility, forward visibility, tracks where offensive AI capabilities are heading, so VulnOps can check that scanning covers each new AI agent deployment, partner integration, or cloud service before it launches. End-of-life systems that cannot be patched need compensating controls, stronger detection, and a migration timeline with a real date and an executive sponsor.

The team is small because the agents take care of the volume. It starts with four people, a Head of VulnOps with operational credibility and AI systems experience, a vulnerability engineer who tunes agent policies and reviews sampled agent decisions, the AI operations specialist from Stage 2, and a remediation coordinator for the hard exceptions that stalled or need vendor negotiation. By month twelve it grows to seven with a second vulnerability engineer and two embedded engineers. The first embedded engineer joins the CTO's organization around months three to five, and the second joins IT/Infra around months seven to nine, once the central team is stable and has findings to show. Embedded engineers calibrate agent policies to their partner team's systems and report to the Head of VulnOps for metrics and methodology. A third embedding focused on production AI agents suits the second year.

Leadership supports the team with three commitments. A clear mandate tells every function that cooperating with VulnOps carries the same urgency as a production incident, pre-authorized read access to codebases and infrastructure spares the team months of access negotiation, and visible backing in the first conflict with a product deadline shows that VulnOps can create friction. A function overruled once does not create friction again.

There are four measures that show whether the program works along with a plain (non technical) language quarterly report that presents them to leadersnip. Mean time to close a critical finding covers the span from identification to deployment across all affected systems. Coverage reports the share of software and systems under continuous scanning and lists every blind spot. Backlog aging tracks open findings by priority and age, where a growing count at any tier warns that something in the pipeline has broken. Escapements count vulnerabilities exploited before VulnOps closed them, and each one triggers a post-mortem that identifies where the finding sat in the pipeline and what would have closed it in time.

VulnOps Needs to Support Survivability Engineering

Security survivability engineering starts from the expectation that attacks will succeed and designs the business to keep operating anyway. Vulnerability work supports that goal because every unclosed finding on a consequential system is a path an attacker can use, and every hour of delay gives that attacker more room to move.

Each stage builds a part of that support. The consequence map tells the organization which systems it cannot afford to lose, the reachability record limits how far an attacker can travel from a compromised system, and the tested recovery times show how quickly a rebuilt system returns to service. Agents closing mechanical fixes at machine speed shrink the number of open paths before an attacker finds them, and engineers with protected time handle the findings that need judgment on the systems that carry the business. The dedicated team in Stage 3 keeps all of this current, reviews its criteria monthly, and turns every escapement into a post-mortem that improves the program.

When a breach does happen, an organization with this structure has fewer open paths, a smaller blast radius around its most important systems, and recovery procedures that it has practiced and measured. A VulnOps function keeps those conditions true as the business changes, and that is how it helps a company survive the breaches it cannot prevent.