.jpeg)
Published 11/03/2026
AI is accelerating vulnerability discovery, but it is not equally accelerating every part of vulnerability management. Findings and vendor fixes can now arrive at machine speed. Testing, deployment, and verification still depend on the infrastructure of a slower era.
So, are you resolving vulnerabilities at least as fast as validated findings enter the system? You can answer this question with one key metric: absorption rate.
Absorption rate measures remediation throughput against validated inflow. Above 1.0, a backlog shrinks; below 1.0, it grows. However, the number only works when teams define “created” and “resolved” carefully and report different streams separately.
Why Not Use Vulnerability Counts? #
Discovery volume is a vanity metric that's easy to count and easy to celebrate. A growing finding count says that scanners and AI discovery agents are busy. It does not show whether you're actually reducing exposure.
AI has accelerated the "find" side of the lifecycle faster than the "fix" side. When inputs outrun remediation throughput, the process saturates. More discovery then produces a larger backlog instead of better security.
Unvalidated findings can flood engineering queues, consume scarce deployment capacity, and erode trust in the security program. A program that rewards finding counts may accidentally reward the creation of work that no one can safely finish.
What is the Absorption Rate? #
The absorption rate is: Findings resolved ÷ findings created.
The operating target should be at or above 1.0 (and above 1.0 for as long as a backlog remains).
- Above 1.0: The organization is resolving more validated findings than it creates. Existing backlog should shrink.
- At 1.0: The organization is keeping pace, but it is not reducing prior backlog.
- Below 1.0: Validated findings are accumulating faster than the organization can resolve them. The program is moving toward saturation.
This makes absorption rate more useful than a static backlog count. A backlog shows accumulated work. Absorption shows whether the operating system behind that work is recovering or falling further behind.
Count Validated Findings #
In the formula, a finding should count as "created" when it exits validation. This prevents false positives and duplicate findings from inflating the denominator. It also gives engineering a queue of evidence-backed work rather than an alert factory.
A finding should count as "resolved" only when verification confirms its disposition. Every sequenced finding should end in one of three paths:
- Fix: Correct the vulnerable code or component.
- Mitigate: Reduce the risk with a compensating control, segmentation, exposure reduction, or virtual patch.
- Disclose: Report a confirmed flaw in third-party code, with a paired mitigation in place while you wait for an upstream patch.
Deployment alone is not resolution. A patch that you have not retested can fail, reopen the vuln, or create a production incident. Verification is what closes the loop.
Mitigations also need an expiration or revisit condition. Once a mitigation expires, the finding re-enters the flow as newly created. Otherwise, temporary controls quietly become permanent accounting tricks.
Separate the Streams #
Bring three inbound streams into one continuous pipeline:
- Pre-release findings in your own code
- Findings in deployed systems
- External advisories or vendor fixes
They compete for remediation capacity, but they do not have the same economics. A PR-time scanner may surface issues that developers can fix quickly before release. A vuln in a stateful legacy system may require compatibility testing, a maintenance window, and rollback planning.
For that reason, report pre-release and deployed-systems absorption separately before combining them. The external stream folds into deployed systems because those findings resolve against the same deployed assets.
Pair Absorption with Speed & Stability Metrics #
Absorption does not show where the pipeline constraints occur. It also doesn't explain whether teams are creating new operational risk to improve the ratio.
Support the absorption rate with:
- Validated-output rate: Confirmed findings divided by candidate findings, per fleet. A sustained decline signals that the fleet needs tuning.
- Time from discovery to validated: A rising value means validation has become the queue.
- Time from validated to deployed: A rising value points to a constraint in engineering, testing, or deployment.
- Cost per validated finding: Rising cost with flat output can indicate poor scope or limited environment capacity.
- Change-failure rate on patches: This shows whether faster deployment is causing incidents or rollbacks.
- Recurrence rate: Reopened findings reveal incomplete fixes or weak regression protection.
The final two stop teams from “improving” absorption by shipping fixes faster than they can verify them.
What Do You Do When Absorption Stays Below 1.0? #
A rolling 30-day absorption rate below 1.0 should be the saturation trigger. A single bad week may be noise, but a full window below the threshold means the program needs an explicit response.
Three levers are available:
- Narrow discovery scope: Retask fleets toward the systems where the organization has capacity to act.
- Raise validation gates: Increase the evidence threshold so only the most actionable findings enter remediation.
- Add remediation capacity: Expand the people, automation, test environments, and deployment paths that resolve more findings.
The first two can reduce inflow quickly. Only the third increases long-term remediation throughput. If saturation persists, it should become an executive escalation with a named signer accepting the exposure.
Additionally, narrowing scope or raising thresholds shrinks the denominator and can make absorption look better without resolving anything faster. Report the ratio alongside candidate volume and scanned scope. This allows stakeholders to see whether the gain came from improved throughput or reduced coverage.
#
AI-driven vulnerability discovery will keep increasing the pressure on security teams. Buying another discovery tool will not solve a throughput problem.
The absorption rate gives CISOs and security leaders a practical health number for the complete system: validation, prioritization, remediation, deployment, and verification. Used with separate stream reporting and stability guardrails, it shows whether vulnerability operations are shrinking exposure or simply producing a better-organized backlog.
CSA's The VulnOps Operating Model publication places this metric inside a continuous pipeline. It follows that pipeline from intake, enrichment, and deduplication through validation, sequencing, remediation, deployment, and verification. Along the way, the paper explains why context should determine remediation order instead of a CVSS-sorted queue alone. It also examines the different operating realities of ephemeral infrastructure, stateful and legacy systems, and unpatchable environments.
The paper also goes beyond workflow design to address the governance required for AI-driven vulnerability discovery. Readers will find defined decision rights for:
- Agent fleets and human owners
- Mandatory human-in-the-loop gates
- Requirements for sanctioned exploit environments
- Guidance for coordinated disclosure when internal fleets uncover flaws in third-party code
The final sections provide prerequisites for launching a bounded pilot, measurable success conditions, and early indicators for failure modes. Read the complete paper to see how these elements work together as a permanent VulnOps function.
Unlock Cloud Security Insights
Subscribe to our newsletter for the latest expert trends and updates
Related Articles:
AI Agents: Securing the Path from Intent to Action
Published: 11/02/2026
The Adversary Economy: How Threat Actors Are Reacting to PHP2Shell
Published: 11/02/2026