Executive Summary

AI has shown itself to be incredibly capable of discovering new vulnerabilities, continuously, at scale. We are already seeing a flood of new discoveries resulting in larger patch sets, more-frequent patches, and increasing numbers of zero-days. We only expect this trend to continue and to exceed our historical approaches to vulnerability management, which runs in batches, on a schedule.

Batch-oriented vulnerability management is becoming increasingly insufficient where AI-accelerated discovery and patch production materially exceed remediation throughput. Scheduled vulnerability assessments cannot keep pace with the kind of autonomous discovery we saw that surfaced 271 vulnerabilities in Firefox in a single evaluation pass [7]. Monthly patch windows cannot absorb a vendor fix stream that is itself AI-accelerated: Microsoft addressed roughly 200 vulnerabilities in its June 2026 Patch Tuesday and a record 974 in September, which the company attributed to its own use of AI.

Batch patch triage also relies on shared infrastructure that is completely saturated, with NIST enriching nearly 42,000 CVEs in 2025, more than in any prior year. NIST is now moving to a “Quality Era” to completely modernize their program since it can no longer keep up with the volume of new vulnerabilities. And the exploitation window has compressed substantially, with attackers capable of developing exploits within hours, not months.

VulnOps is to vulnerability management what DevOps is to software delivery: a modern cybersecurity operating model designed to automate, streamline and scale how organizations identify, prioritize and fix security issues across the full stack. This process flow spans three inbound streams: pre-release vulnerabilities in your own code, vulnerabilities in deployed systems (scanning and first-party discovery of new vulnerabilities in deployed systems), and vendor advisories and patches (including open source). All three converge on one pipeline with triage, deduplication, validation, sequencing, deployment, and verification.

This paper proposes an operating model for the VulnOps function described in the AI Vulnerability Storm briefing [1], built on the definition CSA Labs sketched in its research note [2] and on the organizational design of the companion CSA whitepaper [4]. It walks through the pipeline stage by stage, including the validation gates that make machine-scale discovery manageable, using the “absorption rate” as the key metric, the governance and disclosure obligations, and the steps for standing up the VulnOps function.

VulnOps is about making the organizational and process changes to move to an integrated, continuous model for vulnerability, risk, and patch management. It isn’t merely another tool to buy.

VulnOps Operating Model CISO Review

Scope and Operational Limitations

VulnOps does not mandate automated patching, continuous deployment, or synthetic exploit generation across all organizational assets. Rather, it establishes a calibrated framework where evidence thresholds, human decision gates, and remediation cadences are tailored to specific system classes, operational risks, and regulatory requirements.

The End of the Cycle

Vulnerability management has largely run as a set of periodic cycles based on release cycles, arbitrary time ranges (e.g. 90 days), or vendor release timing (patch Tuesday). The common industry understanding breaks it into a handful of stages: discovering vulnerabilities, correlating to deployed assets, assessing and scanning to find where you are exposed, prioritizing what matters most, remediating through a patch or a mitigation, and verifying the result before the loop begins again [29][30]. Most organizations still run those stages on separate schedules (especially for different platforms), such as a quarterly penetration assessment, daily vulnerability scans, a monthly patch window, and batch triage against a CVSS-sorted queue. These processes also have to account for change management controls, testing requirements, maintenance windows, and other complicating factors.

The whole arrangement reflects constraints on both sides of the process: vulnerabilities historically surfaced slowly enough to be queued, while fixes could be created, prioritized, tested, and deployed through scheduled release and maintenance cycles shaped by change-management controls, vendor cadence, and operational risk. AI is undermining both, and it is doing so unevenly. The inputs to the cycle, discovery and the creation of fixes, are quickly accelerating. The throughput of the cycle, prioritizing and deploying those fixes, is still paced by people and by infrastructure built for a slower, manual era. When the inputs outrun the throughput of the process, the cycle gets saturated, never fully closes, and exposures persist longer (if they are ever even closed).

The stages below show where AI impacts these processes the most.

Discovery and Assessment (finding new and existing vulnerabilities). Assessment has always included four separate activities, each run on a different schedule and each answering a different question. Discovery identifies what is deployed within your organization (including exposure management, to identify unknown assets exposed to the Internet). Vulnerability discovery in development looks for flaws no one has found yet, most often in your own software. Vulnerability scanning matches known vulnerabilities against your assets to find where you are exposed. Penetration testing measures how well your defenses actually hold, and whether a given flaw is exploitable in the context of the controls surrounding it. All four are usually run periodically because they can be expensive and are often human-paced, but we do see some transitioning to a continuous model.

AI is impacting discovery the most. In February 2026, Anthropic reported that its frontier model found more than 500 validated high-severity zero-days in production open-source code, with every finding human-validated [6]. Mozilla then reinforced that trend across two passes against Firefox, where an earlier scan with a prior model led to fixes for 22 security-sensitive bugs, and a single later pass with a more capable model produced 271 vulnerabilities, all of them shipped as fixes in one release [7]. Even earlier than that the DARPA AI Cyber Challenge discovered and patched flaws end to end, autonomously [8].

Scanning has already been migrating from periodic sweeps to always-on scans. AI is now adding a second kind of scanning alongside traditional scans: agents explore deployed systems and reason about what they find, surfacing misconfigurations and context-specific weaknesses that traditional signature scanners don’t cover. AI agents are also particularly effective at chaining vulnerabilities instead of relying on one-shot exploit attempts. That capability is closer to penetration testing than to traditional scanning, since it asks whether something is a problem in context rather than simply if a known flaw is present (based on version or signature). Penetration testing, thanks to improved automation often driven by AI, is in the early stages of moving from scheduled engagements to autonomous platforms that also exercise defenses continuously. XBOW showed what this looks like, becoming the first autonomous system to top the HackerOne US leaderboard with roughly 1,060 submissions in a single quarter [9].

Creating the fix. Once a vulnerability is known, someone has to produce a fix, and where that happens depends on who owns the code. For software you build yourself the flaw is hopefully corrected before the code ships, inside the same secure development pipeline that found it [22]. As AI identifies increasingly complex vulnerabilities, it may take longer to understand the vulnerability workflow and create a patch than it does to identify the vulnerability in the first place. For the third-party software that makes up most of any environment, you wait for the vendor, and patch sizes and frequency are rapidly growing. A phrase recurred across the CISO summit series: every day is patch Tuesday. Vendors whose own discovery is AI-accelerated are now shipping larger and more consequential fix sets on shorter timelines as Microsoft’s mid-2026 releases show. Its June 2026 Patch Tuesday addressed roughly 200 vulnerabilities, a record at the time [25], and its July release then broke that record with 570, a jump the company attributed directly to its own use of AI in vulnerability discovery [26]. September? 974 patches across various product lines.

A fix stream that nearly triples in a single month is not one a monthly maintenance window can easily handle. The gap between a fix being available and a fix being applied is not new, but it widens as the fix stream grows. The binding constraint has always been applying the fix rather than producing it. The Mythos-ready briefing (The AI Vulnerability Storm [1]) addresses this directly, directing programs to re-orient for permanently higher patch volume and shorter time-to-patch.

Prioritizing and deploying the fix. With more available fixes than any team can easily or safely deploy at once, prioritization is critical, and the processes and tooling for prioritization are saturated. An ecosystem built for roughly ten thousand CVEs per year is now absorbing four to five times that volume [2]. NIST’s National Vulnerability Database shows the strain directly: it enriched nearly 42,000 CVEs in 2025, 45 percent more than the year before and more than in any prior year. NIST is now working with the private sector to completely transform the program to meet this new volume. It now reserves full enrichment for vulnerabilities in the KEV catalog, software designated under Executive Order 14028, or software in active federal use [10][2].

The same pressure shows in the private sector, such as when Trend Micro’s Zero Day Initiative saw submissions rise 450 percent year over year, and Pwn2Own Berlin ran out of capacity and turned away researchers carrying working zero-day chains for the first time in the program’s nineteen-year history [11][31].

A CVSS-sorted queue built on that infrastructure orders work by a score that increasingly arrives late or not at all. Deployment has scaled least of all, and it is the hardest stage to automate. Testing a fix, validating it, deploying it (during an approved window), and confirming nothing broke largely remains human-paced. A patch that breaks production is its own incident. For third-party and legacy systems these limitations and risks are especially impactful. Ownership, change management and control, and risk ownership also limit patching velocity. Prioritizing and deploying patches is the choke point and throughput limit constraining the cycle.

The result: the exploitation window. These stages describe a cycle whose find side has accelerated and whose fix side has largely not, leaving us exposed. One report says exploitation of vulnerabilities is now the leading initial access vector at roughly 31 percent of initial access actions, while organizations fully remediated only 26 percent of known exploited vulnerabilities in 2025, down from 38 percent the year before, at a median of 43 days, up from 32 days the year before [5]. The Mythos-ready briefing’s judgment, which we share, is that the window between disclosure and weaponization has compressed from weeks to hours [1]. The old cycle assumed that the window was wide enough to absorb a scheduled response, and that assumption no longer holds.

The cycle never closed especially well even before this. Cyentia’s analysis documented as much back in 2019, when it found the typical organization remediates about one in ten open vulnerabilities per month [12]. The cycle was already losing ground before AI accelerated discovery, and the new volume simply removed the slack that had obscured the problem.

The reframe argued in CSA’s Labs note, and supported by academic analysis of the discovery surge, is that vulnerability management is a flow problem rather than a queue problem, and the binding constraint is remediation throughput, not discovery [2][13].

Figure 1. Vulnerability management is one lifecycle historically run as scheduled stages. AI accelerates the inputs, discovery and fix creation, faster than the throughput of prioritizing and deploying can absorb, so the batch model collapses into one continuous flow.

What is VulnOps?

Adkins, Evron, and Schneier coined VulnOps in an October 2025 essay, as the second of four phases in a defensive evolution they explicitly label as speculative. They describe the phase as AI-assisted vulnerability research available to everyone, at scale, repeatable, and integrated into enterprise operations [3]. The Mythos-ready briefing then converted the concept into a directive by calling on organizations to stand up a permanent VulnOps function [1]. CSA Labs followed with a definitional note framing vulnerability management as a flow problem and proposing the inbound rate of findings against remediation throughput as a saturation metric [2]. This paper builds on all three, with one stated departure. The essay treats VulnOps and continuous discovery with continuous repair as successive phases, while this paper treats the continuous cycle as the core of VulnOps now instead of breaking it into phases.

The name comes from DevOps, and it mirrors that philosophy and structure. DevOps collapsed scheduled release cycles into continuous integration and delivery, built on automation, shared ownership, fast feedback, and measurement. VulnOps applies the same collapse to the vulnerability lifecycle: continuous discovery replaces scheduled assessment, and continuous remediation (which isn’t necessarily automated) replaces patch windows. Verification feeds back into discovery, closing a loop the old model never had. The continuous pipeline covers all three input streams, but the continuous deployment half of it applies fully only where you control both the code and the release. Vendor software moves at the vendor’s pace, and some systems can’t take continuous change at all.

Three inbound streams feed the process:

• First, scanning your own code at commit and pull-request time (pre-release and first-party). This is the cheapest point of absorption in the program since a vulnerability patched before release is never exposed.

• The second stream is vulnerabilities in deployed systems. It includes two components. Vulnerability scanning is the classic instrument of vulnerability management, matching known vulnerabilities against deployed systems. It is already moving to a continuous process that’s been adopted by some organizations. The second component sits closer to penetration testing but stops short of the exploitation. AI discovery agents explore the running environment and reason about what they find, looking for misconfigurations and context-specific weaknesses that a deterministic scanner has no signature for. The difference is the kind of question each one answers. A scanner establishes whether a known flaw is present on a given asset, while an agent can ask whether the way a system is configured, down to its permissions and network paths, creates an exploit path. This can expand into continuous autonomous testing of live defenses, the successor to the periodic penetration test, measuring how well controls and detections stand up to attack. Note that we’ve simplified the options, and there are other approaches including attack graphs that combine various signal feeds to determine exploitation instead of using an agent.

• The third stream is the external feed: the disclosures and advisories in your software supply chain, commercial or open source, and the associated patches. This includes everything from code components to COTS packages (like Windows). Every organization already absorbs this feed, and we are already seeing it arrive heavier and faster.

The three streams differ in economics and in the validation rigor they warrant, which we cover in later sections. They still converge in one pipeline because they compete for the same remediation capacity.

Organizationally the structure follows the guidance in the Designing the AI-First Security Organization companion paper [4]. Five functions consolidate into the pipeline: vulnerability management, threat and exposure management, patch management, application security assessment, and red team infrastructure testing. Pre-release discovery is also in scope, because it is the assessment half of application security that fits into VulnOps. Vendor-side product security (PSIRT) and the SOC remain outside of VulnOps.

Red team and penetration test output also enters through the deployed-systems stream, since it produces findings about running systems and increasingly also relies on continuous tooling. VulnOps is also not a rebrand of continuous threat exposure management, though the two overlap. CTEM organizes the discovery and validation of exposure, while VulnOps is the operating model and can absorb the information CTEM surfaces. SaaS and managed services are a harder problem because you can neither scan them nor patch them yourself. Our AI security organization research routes that through identity and posture management, and through third-party risk (TPRM), rather than through this pipeline. That said, we recommend including the SaaS metrics when communicating with leadership so they understand the full picture of the security posture. In the AI security organization paper’s terms, VulnOps is a complicated-subsystem team: a small cell of agent-managers whose expertise cannot be distributed across the organization, and is offered as a service.

Flow Telemetry

VulnOps measures the health of the vulnerability pipeline through flow telemetry rather than ticket volume. The objective is to understand whether validated findings are being absorbed faster than they arrive, and where work accumulates when they are not. A small set of operational metrics is sufficient to characterize pipeline health:

Organizational Boundaries & Decision Authority. While VulnOps consolidates core exposure and remediation flows, it relies on clear operational boundaries with adjacent security, platform, and governance bodies. Table 1 defines decision authority across the lifecycle using the RACI framework:

• Responsible (R): The function that executes the activity or builds the deliverable.
• Accountable (A): The single role/function with final approval authority and ownership of the risk.
• Consulted (C): Subject matter experts whose inputs are required prior to execution.
• Informed (I): Stakeholders updated on progress, outcomes, or status changes.

Note: In smaller organizations where PSIRT or dedicated platform teams do not exist as separate units, the designated VulnOps owner retains the Accountable (A) role while executing disclosure through external legal counsel.

The pre-release stream. The pre-release stream is the one place the pipeline crosses both the security and application development teams, and this paper recommends the DevOps ownership model since a decade of DORA research proves its effectiveness [20]. The platform side owns gates and telemetry while the developer owns the fix, with policy governing the tension between them.

That tension is structural, because the party that sets a gate does not absorb the cost when the security gate actually blocks. The developer is the one whose work stops. Applied here, VulnOps owns the discovery fleets, the validation standards, the gate thresholds, and the flow telemetry across every stream, including pre-release. Developers own fixes at the merge gate, and AppSec enablement owns the paved roads, fed by VulnOps telemetry identifying recurring finding classes.

Existing SAST, DAST, and SCA tooling feeds the pre-release stream as discovery sources alongside AI-driven fleets, and findings from all sources enter the same intake and deduplication process. The toolchain is additive during transition and rationalized as VulnOps telemetry identifies which sources produce the highest validated-output rate. That feedback loop potentially converts a hundred individual fixes into one secure-by-default root change.

These security gate policies are set jointly by security and development, with an explicit exception path when needed. Cooperation matters here. If VulnOps owns everything, it recreates the AppSec-as-gatekeeper dynamic that blocked merges and burned developer trust. The opposite failure is just as damaging. When enablement owns everything, pre-release findings drop out of absorption accounting, which blinds the program and lets shipping take priority over fixing.

The Pipeline

The pipeline is one continuous flow serving all three streams. Evidence gates stand between machine-scale input and human-scale consequence. Each stage below describes how the agent and human work is divided, and the requirements for a finding to pass. Figure 2 shows the loop, and Table 1 assigns the decision rights for each stage.

Figure 2. The pipeline as a continuous loop: three intake streams, evidence gates, and human touchpoints.

Three intake streams. Pre-release findings arrive from scanning at commit and PR time. Deployed-systems findings arrive from the two sources previously discussed: continuous vulnerability scanning and agent discovery fleets hunting for new flaws and misconfigurations. Agents may also find vulnerabilities in areas a traditional vulnerability scanner might miss. The external stream includes vendor advisories, upstream releases, bug bounty reports, and coordinated disclosures. Everything enters one intake and one flow, but with different fast paths.

A vendor patch from a trusted source that doesn’t need discovery enters at validation for deployment, and a KEV-listed advisory affecting an exposed asset can move to sequencing on applicability alone. Fast-pathed items still pass the integrity gate (when they include integrity checks like hashes); the fast path bypasses validation, not provenance. This matters because the fix stream is itself an attack vector: the xz-utils backdoor arrived as a trusted upstream release [23], and the 2025 npm ecosystem compromises delivered the same attack at package-registry volume [24]. In 2026, the axios library is a recent example of upstream compromise with real-world impact.

Enrichment and deduplication. Some deterministic vulnerability management tools include enrichment and deduplication. Agents can further enrich the process and tag reachability, attach asset and exposure context, collapse duplicates across streams, and propose a local severity for later human review, based on the additional local context (e.g. reachability).

This is where we may see an external advisory and a first-party finding align, as your agents potentially discover vulnerabilities in other people’s software. That collision was almost unthinkable until recently, and it becomes more likely as more organizations point AI agents at vulnerability discovery on external software, especially open source. As first-party fleets mature and start working on external software dependencies, the program rediscovers externally disclosed findings, and deduplication converts that overlap into early warning. The stage is agent-run and human-sampled, meaning humans audit a sample of the output distribution instead of reviewing every item, following the supervision pattern known as governance in the loop (GITL).

Beyond deduplication, enrichment should identify shared root cause or control failure clusters across otherwise distinct findings, services, repositories, identities, and configurations. A cluster level signal can justify a systemic remediation or security default change even when the individual findings are heterogeneous.

Validation gates. Discovered vulnerabilities are then validated to see if they are exploitable, either inherently or in the way the organization uses the software. This is a load-bearing stage to reduce the burden on engineering and deployment. Many vulnerabilities are not exploitable at all, and many more are not exploitable in context, so validation focuses efforts so we aren’t wasting time on issues that aren’t actually security issues. Mozilla’s experience shows the scale a validated finding set can reach. Firefox version 150 shipped fixes for all 271 vulnerabilities from a single evaluation pass, and the team described having to reprioritize everything else to handle the load [7]. To manage the potential scale of AI-discovered vulnerabilities, the summit participants converged on confirmed exploitability as the best escalation bar. The gates exist to make sure the queue reaching engineering is worth the disruption.

For the two first-party streams, validation is multi-stage and evidence-based. To ensure validation scales safely without introducing severe false-negative rates, legal bottlenecks, or operational risk, VulnOps replaces binary exploit testing with a four-tier Evidence Assurance Model:

• E1 (Applicability & Reachability): Automated verification confirms an executable path exists from an exposed attack surface to the vulnerable component. Code that is never called from an exposed surface can be downgraded (only in that context), no matter how severe the flaw looks on its own.

• E2 (Reproducible Behavior): Controlled testing confirms that specific inputs trigger anomalous state changes, memory faults, unexpected error conditions, or other potentially harmful behavior without requiring full exploit execution.

• E3 (Controlled Exploitability Demonstration): Proof-of-concept payload execution is demonstrated within a strictly isolated sandbox or synthetic test harness.

• E4 (Validated Operational Attack Path): Contextual confirmation proves the flaw is exploitable past surrounding environmental controls, compensating policies, and network segmentation.

Adversarial verification operates across these tiers based on asset criticality and risk, rather than requiring E3 or E4 exploit creation for every finding. The difference between attacking and reviewing is what makes this stage work: discovery agents reason their way to the finding, while the second stage produces observable evidence that the flaw is exploitable [15]. This functions like a penetration tester’s contextual judgment, except that the judgment runs continuously inside the pipeline before deployment. Because adversarial testing increases confidence but is not absolute, fleets should run continuous false-negative controls, including benchmark suites with seeded flaws, model diversity, and periodic human expert sampling.

Flaws coming from vendors and other official sources don’t need further exploit confirmation. When a scanner matches a known vulnerability, or a vendor advisory, the flaw is considered real. You may still need further validation since scanners can make mistakes, or the vulnerability may not be reachable in your context. The bar becomes a confirmed path to exploitation, established through reachability, exposure, and whatever controls protect the resource. Zero confirmed findings may be a valid outcome of this stage.

Prioritization and sequencing. A critical flaw in a public-facing resource is easy to prioritize, but after that things become more complex. It’s all too easy for medium and lower severity findings to keep piling up due to the fear of breaking changes, making it even harder to deploy them without downtime.

As with DevOps, the goal is to fail fast and fail small, making it easier to revert changes.

Many organizations run severity-based remediation SLAs because PCI DSS, FedRAMP, a regulator, or a customer contract requires it, and KEV carries fixed federal deadlines regardless of local context. Context-based sequencing operates inside those deadlines, not around them, with exemptions tracked, dated, and assigned to someone for responsibility.

Context matters more than any single score. Reachability, chainability, blast radius, and compensating controls determine the order, with KEV listings and EPSS scores [16] as inputs rather than the defining metric. Each asks a different question about the same finding. Reachability asks whether an attacker can get to the vulnerable code at all, and compensating controls if that path is accessible. Blast radius asks how far the damage travels once the flaw is exploited. Chainability asks whether the finding can be leveraged for further action. This is why a medium-severity flaw that yields credentials for a high-value system can outrank a critical flaw with a small blast radius. Relying on a CVSS-sorted queue fails here for a structural reason: the score describes the vulnerability, while the decision depends on the environment around it.

Sequencing what patches deploy when is a single decision across all three streams. An unpatched vendor advisory and a first-party finding compete for the same deployment capacity, and treating them as separate queues recreates the silos the VulnOps function exists to remove. Human judgment is the scarce input at this stage. Agents propose the sequence with full supporting context, and the human owns the call, including the explicit decision to defer, which is risk acceptance and gets recorded as such.

Remediation and deployment. Every sequenced finding is assigned to fix, mitigate, or disclose, and managed in its path (e.g. first-party vulnerability in first-party code is resolved in the development process).

Remediation is not necessarily a code change. Depending on the exposure, the effective corrective action may include revoking credentials or access grants, rotating secrets, invalidating tokens or sessions, removing exposed data, disabling an affected integration, restricting network exposure, or applying other control plane changes that eliminate the risk without modifying the vulnerable component.

In your own code the fix is your responsibility, and the cheapest option may be to address the vulnerability class and not the individual vulnerability instance. Many findings from continuous discovery are instances of a class rather than isolated defects. The same unsafe parsing call or the same missing authorization check tends to repeat across a codebase, because developers follow an existing example. Patching each instance closes those findings and leaves the pattern in place, so the next scan returns the same class in new locations.

Substituting a secure-by-default alternative changes that. The substitution might be a hardened library or a safe wrapper around a risky API, and it might be a framework setting that makes the unsafe path unavailable. It closes the current instances and prevents the same future ones, which is what stops a finding class from consuming capacity month after month. Repetition is the trigger for making that investment, and pipeline telemetry should make the repetition visible. AppSec enablement builds and owns those paved roads, per the process described earlier, while VulnOps supplies the evidence that a given class should be managed at the root cause. Agent-generated fixes carry regression evidence produced alongside the fix, and pre-release fixes land before the code ships at all, which is the pre-release stream paying for itself.

An evidence bundle should be required for every agent generated remediation. At a minimum, it should include the original finding, enriched context, patch diff, dependency changes, build and test results, and final verification status. Retaining this evidence with the pull request or in an immutable audit log improves traceability, auditability, and compliance. It also gives developers and reviewers clear visibility into the rationale behind the change, the validation performed, and the confidence level of the proposed remediation.

In third-party code the fix belongs to the vendor. Vendor patches pass through compatibility testing and staged rollout, and pre-authorized change classes (e.g. Windows workstations) deploy under GITL, with human in the loop (HITL) reserved for deployment outside those classes. The change-class boundaries are themselves governance artifacts, and are reviewed periodically to ensure the program is adapting to changing needs.

Where vendor remediation is unavailable and exploitation pressure justifies action, organizations may use a temporary local remediation such as a vendor-source patch, maintained fork, wrapper, configuration hardening, or other compensating implementation, subject to legal, compatibility, provenance, and maintenance review. Such measures should remain explicitly tracked as temporary technical debt and be revalidated when the upstream fix arrives.

The mitigate path covers what can’t be safely patched now. Mitigations include compensating controls tagged to the specific finding, segmentation, exposure reduction, and virtual patching. Every mitigation is treated as temporary technical and security debt, carrying an assigned business owner, fixed expiration date (e.g., maximum 90 days), residual risk statement, and a funded plan toward permanent patch, refactoring, or system retirement. Keep in mind that resource-constrained organizations may not be capable of this same level of diligence, but all mitigations still need to be periodically reviewed with the goal of eventually fully eliminating the flaw.

The disclose path handles the case for a confirmed flaw in someone else’s code for which no patch yet exists. This is most likely to appear when scanning open-source libraries and applications used in your own applications. Your fleets will find these, since your environment is built from other people’s software. Disclosure requires a paired mitigation until there’s an upstream patch (unless you create your own, which creates versioning/forking risk), and it counts toward absorption only once that mitigation is in place.

Verification and feedback. Post-fix retest confirms each finding is closed, and regression protection keeps it closed. Patching may cause breaks, and this telemetry feeds the change-failure metric, and false-positive patterns route back to the discovery fleets to help with tuning. Recurring finding classes route to AppSec enablement as candidates for a root-cause remediation or paved road, while absorption telemetry feeds the scoping decisions described in the next section. This stage provides continuous feedback to keep improving the process. Traditional vulnerability management ended at ticket closure, and the absence of feedback is a large part of why backlogs kept expanding.

Table 1. Decision rights per pipeline stage under a GITL-default model. The fleet is Responsible everywhere and Accountable nowhere, consistent with the companion paper [4].

Patching Without Breaking

The test-validate-patch-validate loop is critically important, but it also slows down the process. VulnOps has to speed that loop up without skipping it. Deployment is the hard half of the pipeline for four reasons: patches can break things, vendor patch quality is outside your control (and summit participants expect it to suffer under volume pressure), stateful and legacy systems resist rebuild, and some environments require a level of determinism that precludes casual change.

AI makes validation faster, but it does not remove the need for it. Agents generate tests and produce regression evidence at machine speed to compress the loop. This should still occur with tools like branch testing and quality engineering, for organizations with the resources to support it.

Three tiers of deployed systems behave differently within the loop. Ephemeral/immutable and containerized systems are rebuilt from a patched base as the default, with tested rollback. Stateful (when state can’t be handled externally) and legacy systems keep the full loop, accelerated by AI-generated test harnesses and digital twins. Unpatchable systems, including end-of-life systems and OT, rely on mitigation, where degraded-mode operation is an accepted posture rather than a temporary embarrassment. SaaS and other external services are a fourth tier, but organizations can’t control patching and have to rely on other mitigating controls.

• Cloud-Native & Microservices: Rebuild-from-patched-base is the default, leveraging progressive canary rollouts and automated rollback triggers.

• Stateful Enterprise Systems: Automated test harnesses and digital twins validate patch compatibility before executing scheduled, human-supervised deployment windows.

• Legacy & OT/Operational Systems: Changes shift to a governed Mitigate disposition. Compensating controls, network micro-segmentation, and exposure reductions are deployed as long-term risk mitigations rather than temporary fixes.

• SaaS & External Services: Remediation is managed through identity boundaries, posture configuration, and vendor SLA enforcement rather than direct code updates.

Canary and progressive rollout with automated rollback is the deployment default wherever it applies, and it serves as supply chain containment. Staged rollout limits the blast radius of a compromised patch or library, and rollback is a security response as much as a reliability response. The xz-utils incident is the example case [23] and the 2025/2026 npm compromises prove that attackers are targeting the supply chain at scale [24]. The axios library compromise is another recent example.

Soak time before adopting an upstream release is likely a per-package or per-source decision rather than a standing policy for everything. Waiting reduces supply chain risk while extending the exposure window, so the program decides based on provenance confidence [21] and exploitation pressure, and records the decision at the integrity gate (Appendix A).

Before deployment, each validated fix passes a deployment decision gate that balances three competing risks: exploitation risk, deployment risk, and operational criticality. Internet-facing actively exploited flaws generally favor immediate rollout, while high-impact but low-confidence vendor updates may justify controlled soak time. Systems whose availability requirements outweigh patchability transition to the Mitigate disposition with documented residual risk and review intervals.

Measuring Absorption

The continuous model uses absorption rate as the key performance metric: findings resolved divided by findings created, across all streams, over a rolling thirty-day window [14]. The fix and mitigate dispositions both count as resolution, with a mitigated finding counting once its paired mitigating control is actually in place. Below 1.0, more findings enter the pipeline than leave it, and the backlog grows structurally. A program sustained above 1.0 is gaining ground by clearing backlog faster than it is growing.

Absorption can be gamed by shrinking discovery scope, so it is never reported alone. It is always paired with the stability pair, two checks that show whether the absorption number is real: change-failure rate on fixes (are the fixes breaking things?) and recurrence rate (do closed findings stay closed, or do they fail verification and reopen?). A program that hits 1.0 by rushing fixes that break production, or by closing findings that come back the next scan, shows it in these two numbers. Alongside the pair, report the raw volume of findings created and resolved so the ratio has a denominator; risk-weighted absorption (the same ratio weighted by the enrichment signals, such as reachability, exposure, blast radius, and chainability) so closing one critical reachable finding counts for more than closing ten unreachable lows; and the age of open critical findings so a ratio above 1.0 cannot hide a critical that has sat for months.

Absorption rate shows if your program is able to handle the volume, or if your process or technology can’t keep up.

Four rules help keep the number meaningful. First, count a finding as created when it exits validation (or was fast-tracked, as in a KEV), and as resolved when verification confirms its disposition. Counting raw candidates in the denominator would let scanner noise dominate the ratio, and counting resolution at deployment rather than at verification would let unverified fixes inflate it. Second, mitigations count as resolution only while their recorded expiration or revisit condition is in place. Third, an expired mitigation re-enters the flow as a created finding. Fourth, the count should be based on what actually needs to be fixed rather than the unit of disclosure. If one vendor update addresses hundreds of CVEs across the same group of workstations, it should still count as one finding because there is only one change to test and deploy. The CVEs, severity, and number of affected systems should stay with the finding for prioritization and due dates, but they should not be counted as separate findings.

Without this rule the metric is undefined rather than merely imprecise, because the result depends on how a vendor packages and reports its vulnerabilities. One vendor may address fifty CVEs in a single cumulative update while another issues fifty separate patches for effectively the same remediation work. Counting affected asset instances creates the same problem from a different direction, letting fleet size rather than remediation workload drive the measurement.

Report on pre-release and deployed-systems absorption separately before combining them. The streams have different economics. A noisy PR-time scanner generating trivially resolved findings would otherwise inflate the combined ratio while the backlog on deployed systems quietly grows. The external stream folds into deployed-systems absorption for reporting, since its findings resolve against the same deployed assets.

Absorption tells you whether the pipeline is keeping up, but not where it is failing or working. A few supporting metrics answer that (Table 2). Validated-output rate shows whether the fleets are producing trustworthy findings or need tuning. Timing splits the pipeline in half, since time from discovery to validated locates a forming backlog in the security gates, while time from validated to deployed locates one forming in engineering. Cost per validated finding keeps the economics visible as fleets scale.
Discovery volume is largely a vanity metric, but can indicate problems like scanning effectiveness and be useful for tuning or identifying a tool failure. But all findings must go through validation since flooding engineering with unvalidated findings is as dangerous as doing nothing, because it burns the credibility and the capacity the program needs.

Absorption has one gaming vector of its own, which a program might reach for under saturation. Narrowing discovery scope or raising gate thresholds shrinks the denominator, so the ratio improves without a single additional finding being resolved. Those are legitimate responses to saturation, and they are also the easiest way to report progress that does not exist. To avoid this, report absorption alongside the discovery scope and candidate volume that produced it. A smaller denominator then shows up as a scope decision rather than a performance gain.

Figure 3. Absorption rate is the program’s health number. Above 1.0 the backlog shrinks. Below 1.0 for a rolling thirty days, the program enters saturation response.

Saturation behavior goes past published practice, so CSA offers it as emerging practice. That framing is consistent with SRE saturation discipline [19] and with the saturation-metric position in CSA’s Labs note [2]. The trigger is the rolling thirty-day figure sitting below 1.0 rather than a single bad week. The three levers differ in lead time rather than in value. Narrowing discovery scope and raising gate thresholds both cut inflow (but may reduce visibility), and both take effect as soon as the fleets are retasked.

Those two are what stops the backlog growing in a given month, but should be reported as a re-scoping decision and be signed off since it may reduce visibility and increase risk. Adding remediation capacity, either automated or manual, is the only lever that actually resolves more findings, but that takes time.

Table 2. The VulnOps metric set.

Agent and Org Governance, Decision Rights, and Disclosure

Within VulnOps, GITL is the default, so agents operate inside a governed envelope of pre-authorized actions with monitoring and audit, and HITL is reserved for defined high-consequence gates [4]. VulnOps reserves three gates of its own. Humans still authorize sanctioned exploit confirmation and production deployment outside a pre-authorized change class (e.g. emergency manual patch of a firewall). The third gate is external disclosure, something most organizations never had to previously worry about but is likely when using your own agents to scan open-source code.

There are two different facets to the sanctioned exploit environment. The first is that it is a place to build exploits. Proving a novel flaw means having your agent write working exploit code, in the existing test harness, and against isolated infrastructure running a copy of the application. This is the one the summit series kept returning to as a blocker, because programs that had the discovery capability often had nowhere legitimate to confirm what it found, and engineers were improvising on laptops or against shared development systems.

The second is permission to test systems that are already running. Here the constraint is not where the exploit executes but whether you may touch a live system at all, and how far you may go once you do. Confirming a path to exploitation against a production service, even without running a full exploit, is still an action against a production service. Very few organizations will run automated exploits against production systems. Most will instead consider alternatives like digital twins, or simply perform the analysis to see whether the vulnerability is exploitable in the context of the existing implementation and security controls.

Sanctioned means an explicit authorization chain. That chain runs from legal and executive sign-off through documented scope down to the specific fleet tasking. The sign-off names which systems may be tested and by which fleets, and it should require periodic renewal. (This level of permission can be less strict when working with digital twins or other non-impactful environments.) Exploit work outside that chain is a serious control failure.

How far the exploit-building environment can stretch is an effective cap on absorption for novel findings, because every proof of exploit consumes its capacity. Model providers add friction of their own, because safety filters and data-retention policies complicate exploit development even against your own systems, so negotiate terms with the provider rather than improvising workarounds. The major frontier providers keep expanding access to their cyber-capable models for individuals and organizations that go through an additional verification process. Small organizations likely take the managed-service path, buying discovery and validation externally under contract while keeping the authorization chain internal.

Discovery agents are a risk surface of their own, and pointing them at live infrastructure requires controls on the agents as well as their targets. In July 2026 an OpenAI evaluation agent escaped its sandbox by discovering a zero-day in a package registry cache proxy. It then gained unauthorized internet access and chained stolen credentials with further zero-days to reach remote code execution on Hugging Face production systems. No external adversary was involved [27][28]. The evaluation deliberately ran without the production classifiers that restrict high-risk cyber activity, showing both the value of safeguards and the capabilities of the model. The only control standing between the agent and the internet was restricted network egress, which was bypassed. A discovery fleet aimed at a production environment is one misconfiguration or one more capable model away from the same behavior. Agent safety controls must extend beyond basic sandbox boundaries. Prerequisites for first-party discovery fleets include:

• Control-Plane Isolation: Execution harnesses run on dedicated, isolated control planes with default-deny outbound network egress.

• Ephemeral Scoped Credentials: Fleets utilize short-lived, least-privilege tokens bounded strictly to authorized targets.

• Visibility & Immutable Audit: Every API call, network request, and system interaction is logged to immutable write-once storage.

• Tested Hardware/Software Kill Switch: Out-of-band mechanism capable of instantly revoking credentials and severing network paths without relying on agent cooperation.

• Prompt & Output Defense: Defenses against prompt injection and manipulated tool outputs when processing unauthenticated third-party code.

External Disclosure Interface: While VulnOps discovers, validates, and packages evidence for third-party vulnerabilities, formal external disclosure (CVD) is owned and executed by PSIRT or a dedicated disclosure office in close coordination with Legal, ensuring compliance with vendor license agreements and statutory requirements.

Two scope limits keep this apparatus from swallowing the program. The external patch stream is never gated on exploit work of either kind, because the flaw is already established as real and exploit capacity is better spent on findings that haven’t been validated yet. That stream is prioritized on applicability and exposure instead, plus exploitation evidence such as KEV listings and EPSS scores [16]. Digital twins are the second limit. They prove their value on high-consequence systems that can’t afford an outage caused by testing.

Legal should be involved in any newly discovered vulnerability in third-party code from the start, not after the first report goes out. Many enterprise license agreements prohibit reverse engineering or security testing, and finding flaws in software you licensed rather than wrote can carry contractual and statutory exposure, depending on the jurisdiction and the method. The authorization chain that governs testing your own systems does not extend to someone else’s code. Settle two things with counsel before the capability is pointed at a vendor product: the scope of what fleets may examine in third-party software, and the terms under which findings are reported.

Anthropic’s coordinated vulnerability disclosure policy is a working reference. It sets a 90-day default with a compressed seven-day timeline for vulnerabilities under active exploitation, and its reports generally reflect a human researcher’s confirmation before they go out [18]. Project Zero’s reporting transparency policy shows a different adaptation, disclosing that a report exists within about a week of filing while leaving the remediation timeline unchanged, which is aimed squarely at the upstream patch gap [17]. A validated finding that sits undisclosed becomes a growing liability, and Table 3 lists the undisclosed backlog as a named failure mode.

Pre-approved change windows and renegotiated vendor SLAs are part of the same governance work, and across the summit series both took time to put in place wherever they had been attempted.

Standing Up VulnOps

There are seven prerequisites before starting a VulnOps pilot:

• A named owner. One accountable person holding the human seats in Table 1, starting with gate thresholds and deferral decisions. This authority should be delegated from executive sponsorship.

• A central asset inventory. This requirement is met when it can identify when a named component and version are running anywhere, and who owns it, without additional manual validation.

• The security platform and AI engineering substrate. In place when a fleet can be tasked and audited through it rather than run from an engineer’s terminal.

• Somewhere to build exploits, and authorization to test running systems. Ready when the authorization chain has run end to end on a real finding rather than on paper.

• The five discovery-agent safety controls. Met when the boundary is enforced, credentials are short-lived and scoped, fleet actions are logged as they happen, the kill switch has been tested and validated, and prompt and output defenses are in place.

• Pre-authorized change classes. Validated once a class has carried a deployment without a per-change approval.

• Deployment automation. Enough when a validated fix can ship when it is ready instead of waiting for the next window.

The pilot is bounded and covers both first-party streams: one segment of deployed systems under continuous discovery, plus one development pipeline under commit-time scanning. Covering both matters, because the two streams surface different governance friction. The full gate structure runs from day one, and absorption is measured from the first week. Run it long enough to track absorption over several consecutive thirty-day windows.

Treat the first pass over previously unscanned code or systems as a baseline rather than as inflow. (Most organizations already have ongoing scans.) A massive pre-existing backlog says nothing about the operating model. Absorption starts counting once that baseline is established, and the baseline itself becomes the backlog to work through.

Three conditions mean the pilot has succeeded.

• Absorption sits at or above 1.0 in the pre-release and deployed-systems streams.
• The stability pair holds flat across those same windows, so the gain did not come from shipping fixes faster than they can be verified.
• The exploit authorization chain has been exercised on a real finding.

From there, scale by evidence. Extend to the next segment of deployed systems or development pipeline only when absorption in the stream holds above 1.0 across consecutive windows. Report candidate volume and scanned scope alongside the ratio to ensure the number isn’t being gamed. Confirm that the exploit-building environment has headroom for any added segment and that authorization covers the systems as they are added. Watch for discovery scope outrunning remediation capacity, which indicates saturation.

Staffing follows our AI-centric security organization recommendations: a small senior cell of agent-managers whose skill is validation judgment [4]. That judgment is the ability to assess whether a fleet’s confident output is trustworthy without redoing all the work. Small organizations run the same model at minimum scale, with managed discovery and validation services and an internal owner who keeps the sequencing and prioritization decisions.

This table catalogs the failure modes specific to VulnOps. Each is cheaper to prevent than to unwind, and most show up in the metrics before they show up in an incident.

Table 3. VulnOps failure modes. Diagnostic use: the right column is the leading signal, so act on it before the middle column becomes the program’s normal state.

The executive ask is organizational and process change rather than asking for more tools (although you might need some if you have gaps in your portfolio). The charter covers a new, permanent function and a continuous operating model, using an initial pilot to justify expansion. The Mythos-ready briefing suggested a deadline of 12 months [1]. For most organizations, the two gaps to close first are deployment automation and an exploit environment with a working authorization chain.

Appendix A: Gate Reference

Table A1. Validation gates with entry criteria, pass criteria, and failure disposition, per stream where they differ.

References

[1] SANS Institute, Cloud Security Alliance, [un]prompted, and OWASP GenAI Security Project, The AI Vulnerability Storm: Building a Mythos-ready Security Program, April 2026. https://cloudsecurityalliance.org/artifacts/the-ai-vulnerability-storm

[2] Cloud Security Alliance Labs, VulnOps: Vulnerability Management in the Age of AI, CSA Research Note, May 4, 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-vulnops-age-of-ai-20260504/

[3] Heather Adkins, Gadi Evron, and Bruce Schneier, “Autonomous AI hacking and the future of cybersecurity,” CSO Online, October 8, 2025. https://www.csoonline.com/article/4069075/autonomous-ai-hacking-and-the-future-of-cybersecurity.html

[4] Cloud Security Alliance, Designing the AI-First Security Organization, companion whitepaper, 2026 (in review).

[5] Verizon, 2026 Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/

[6] Anthropic Frontier Red Team, “Zero-days” (500+ validated high-severity zero-days), February 2026. https://red.anthropic.com/2026/zero-days/

[7] Mozilla, “The zero-days are numbered,” 2026. https://blog.mozilla.org/en/firefox/privacy-security/ai-security-zero-day-vulnerabilities/

[8] DARPA, AI Cyber Challenge (AIxCC) Final Results, August 2025. https://www.darpa.mil/news/2025/aixcc-results

[9] XBOW, “Top 1: How XBOW did it,” June 2025. https://xbow.com/blog/top-1-how-xbow-did-it

[10] NIST, “NIST Updates NVD Operations to Address Record CVE Growth,” April 15, 2026. https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

[11] Trend Micro Zero Day Initiative, “Pwn2Own Berlin 2026,” June 2026. https://www.trendmicro.com/en_us/research/26/f/pwn2own-berlin-2026.html

[12] Baker, W. (2019, March 12). Prioritization to prediction, Vol. 3: Wade’s take. Cyentia Institute. https://www.cyentia.com/p2p-vol3-wade/

[13] Pesoli, Errico, and Cavallaro, “Demystifying the Mythos or Disrupting Bugonomics?”, arXiv preprint arXiv:2605.24632 [Preprint - Not Peer-Reviewed], May 2026. https://arxiv.org/abs/2605.24632

[14] AppSec Santa, “AppSec Metrics Guide” (fix-rate practitioner literature). https://appsecsanta.com/application-security/appsec-metrics-guide

[15] Korda and Evron, “OpenAnt,” arXiv preprint arXiv:2606.19149 [Preprint - Not Peer-Reviewed], June 2026.. https://arxiv.org/abs/2606.19149

[16] FIRST, Exploit Prediction Scoring System (EPSS) v4. https://www.first.org/epss/

[17] Google Project Zero, “Reporting Transparency,” July 29, 2025. https://projectzero.google/2025/07/reporting-transparency.html

[18] Anthropic, Coordinated Vulnerability Disclosure Policy. https://www.anthropic.com/coordinated-vulnerability-disclosure

[19] Adkins et al., Building Secure and Reliable Systems, Google/O’Reilly. https://google.github.io/building-secure-and-reliable-systems/

[20] DORA, Accelerate State of DevOps Research. https://dora.dev

[21] SLSA, Supply-chain Levels for Software Artifacts. https://slsa.dev

[22] NIST, SP 800-218: Secure Software Development Framework (SSDF). https://csrc.nist.gov/pubs/sp/800/218/final

[23] Ars Technica, “What we know about the xz Utils backdoor that almost infected the world,” April 2024. https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/

[24] CISA, “Widespread Supply Chain Compromise Impacting npm Ecosystem,” September 2025. https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

[25] SANS Internet Storm Center, “Microsoft June 2026 Patch Tuesday,” June 9, 2026. https://isc.sans.edu/diary/33064

[26] Zack Whittaker, “Microsoft patches record number of security vulnerabilities, citing its use of AI,” TechCrunch, July 15, 2026. https://techcrunch.com/2026/07/15/microsoft-patches-record-number-of-security-vulnerabilities-citing-its-use-of-ai/

[27] Sergiu Gatlan, “Hugging Face discloses breach linked to autonomous AI agent,” BleepingComputer, July 20, 2026. https://www.bleepingcomputer.com/news/security/hugging-face-breach-autonomous-ai-agent-system-internal-datasets-credentials/

[28] “OpenAI models behind breach of Hugging Face systems, companies say,” The Record, July 22, 2026. https://therecord.media/openai-cyberattack-hugging-face

[29] Microsoft, “What is vulnerability management?” Microsoft Security 101, June 2026. https://www.microsoft.com/en-us/security/business/security-101/what-is-vulnerability-management

[30] CrowdStrike, “Vulnerability Management,” Cybersecurity 101. https://www.crowdstrike.com/en-us/cybersecurity-101/exposure-management/vulnerability-management/

[31] Tom Spring, “Pwn2Own Berlin 2026: ZDI AI submissions surge, rejected researchers,” Security Point Break, May 2026 (quoting Dustin Childs of the Zero Day Initiative). https://securitypointbreak.com/2026/05/14/pwn2own-berlin-2026-zdi-ai-submissions-surge-rejected-researchers/