The Autonomous Remediation Playbook: Automated Vulnerability Remediation From Detection to PR in Under 60 Seconds

Automated vulnerability remediation is the practice of turning a verified security finding into a tested, reviewer-ready pull request without a human writing the fix. The autonomous remediation playbook below does it in four steps, in under 60 seconds from detection to PR, and keeps a human engineer as the final merge gate.

The conversation about vulnerability remediation has been stuck for ten years. Detection has gotten faster. Triage has not. Patching has not. Edgescan’s 2026 Vulnerability Statistics Report puts the mean time to remediate high and critical application and API vulnerabilities at 54.81 days, and Veracode’s State of Software Security 2025 found that the average time to fix security flaws has grown 47% since 2020.

Then the AI coding tools arrived. They made the volume problem worse — but they also made the playbook below possible. The four-step pattern below is what we mean when we say “autonomous remediation.” It is not a feature on a vendor’s roadmap. It is a discipline, a pipeline, and a feedback loop. If your team is not running it, the attackers are running a faster version of it against you.

This is the playbook.

Why Mean Time to Remediate Is the Bottleneck

The numbers are stubborn. Across the customer repositories we have visibility into (Plexicus internal data, not an industry benchmark), the median lifecycle of a high-severity finding in 2025–2026 looked like this before the playbook:

Seventeen days for a high-severity finding to clear, and that is a well-run team compared with the industry averages above. In the meantime, the attacker side keeps getting cheaper. The research agent RapidPen reached shell access on a vulnerable target in 200–400 seconds at roughly $0.30–$0.60 per run, and Amazon Threat Intelligence documented a single low-skilled actor using commercial generative AI to compromise more than 600 FortiGate devices across 55 countries in about five weeks.

The asymmetry is no longer subtle. Mandiant measured the average time-to-exploit at five days in 2023. A remediation cycle measured in weeks is the structural problem the autonomous remediation playbook is built to close.

The Four-Step Automated Vulnerability Remediation Pipeline

The playbook has four stages. Each stage has one job. The handoff between stages is where most teams lose the evidence trail that auditors need.

Stage 1 — Verified finding

A scanner such as Deep Code Analysis proposes, say, 1,247 findings. The pipeline rejects the large majority of them on the grounds that they do not survive an independent replay pass. (Why pattern-matching scanners produce so much noise is covered in What Is Deep Code Analysis?)

The bar for survival is exact:

• The proposed finding must reproduce end-to-end against a sandboxed target.
• The reproduction must be performed by an agent that did not author the finding.
• The reproduction artifact (a curl request, a CI job, a container snapshot) must be stored.

Findings that do not pass all three are discarded with reason codes. The reason codes matter — they are how you debug the pipeline later. The most common reason codes we see are:

• not_reachable (no real path from a public endpoint to the sink)
• guard_present (an upstream check makes the finding inert)
• mitigated_at_runtime (WAF rule, feature flag, or env var neutralises it)
• replay_failed (the second agent could not reproduce it)

The output of Stage 1 is a small set of verified findings, each with its replay artifact attached.

Stage 2 — Context preserved

A verified finding is not enough to ship a fix. The next stage attaches everything the developer needs to validate the patch:

• The graph node (host, endpoint, parameter)
• The capability class (read, write, impersonation, RCE, exfiltration)
• The reachability path (the full chain from request to sink)
• The request/response pair (what the original exploit looked like)
• The agent reasoning trace (why the original agent classified it as it did)

This is the audit trail. Without it, the engineer reviewing the patch has to take the system’s word for it. With it, the engineer can rerun the original exploit against the unpatched code, confirm it reproduces, then rerun it against the patched code, confirm it returns the expected mitigation.

The point is not to make the engineer do extra work. The point is to make the work verifiable.

Stage 3 — Patch drafted

Plexicus Remediation takes the verified finding + context and produces a reviewer-ready diff. The diff is not a generic fix. It is the minimum change that removes the reachability path while preserving the original business logic.

The pipeline enforces three properties:

• The patch removes the class of vulnerability, not just the instance. A parameterised query fix is preferred over a replace() sanitiser, in line with the OWASP SQL Injection Prevention Cheat Sheet (see our SQL injection remediation walkthrough). An ownership check at the handler is preferred over a route-level allowlist.
• The patch includes regression tests. The original exploit becomes a test. If the patch passes the test, the finding is closed. If the patch breaks the test, it is reverted.
• The patch includes the documentation update. If the API contract changes, the docs change. If a new environment variable is introduced, the README reflects it.

The output of Stage 3 is a pull request branch. Not a code snippet. Not a “here’s the diff” suggestion. A full PR that an engineer can clone, run, and review.

Stage 4 — Reviewer-ready PR

The patch lands in the existing repository with:

• Reviewer assignment (from CODEOWNERS, with security team escalation)
• SLA tracking (the PR is auto-assigned a fix-by date based on severity)
• Re-test hook wired to CI (the original exploit runs against the patched branch on every push)
• Audit metadata attached (the original finding, the graph node, the replay reference)

The PR does not auto-merge. The engineer’s review decision is the last human gate. What changed is that the review takes minutes, not hours. The engineer is not reading 200 lines of unfamiliar code. They are reading a 12-line diff that came with the original exploit, the graph context, and the regression test result.

If the engineer approves, the PR merges, the re-test confirms, and the finding closes. If the engineer rejects (with reason), the patch proposal is logged as rejected_with_evidence and the finding stays open for the next attempt.

The Numbers That Matter: Mean Time to Remediate Before and After

We have been running this playbook across customer repositories since Q4 2025. The medians we observed (Plexicus internal data):

The headline number we advertise — under 60 seconds from detection to reviewer-ready PR — is the Stage 1 to Stage 3 metric. The full lifecycle to production is dominated by the human review and the existing CI/CD process, which is exactly where it should be. The pipeline’s job is to remove the unforced latency. The review and the deploy stay with the team.

The other number worth highlighting is the false-positive rate. In our deployments, before the playbook, 87% of scanner findings were closed as “not an issue” after human triage. After, that number dropped to 6%. The remaining 6% are the cases where the engineer disagrees with the verifier’s read of the evidence — exactly the cases where the human gate matters.

What This Costs to Implement

Three operational requirements:

1. A graph-aware scanner that can produce a reachability path. Not regex SAST. Not an LLM wrapper. A graph.
2. A replay-verifiable verification pass. A second agent that can independently reproduce the finding. Without this, the pipeline produces confident, polished, and ungrounded patches — the worst possible outcome.
3. A patch generator that respects business logic. In our experience, the most common failure mode of “AI auto-fix” products in 2025 was patches that compiled but changed the meaning of the code. The playbook requires the patch to be minimal, test-covered, and reviewable.

The Plexicus implementation has all three. If you are building this yourself, our estimate of the integration cost is roughly one senior engineer for one quarter. If you are buying it, the line item is in the Continuous Program tier on the pricing page.

What This Does Not Do

The playbook does not eliminate the human gate. A patch is still reviewed by a human before merge. The verifier’s evidence is still surfaced for an auditor. The system does not push to production on its own.

This is intentional. The argument from the “fully autonomous remediation” vendors is that humans are the bottleneck and the system should just merge the PR. The argument from the Plexicus AI Swarm Pentest team is that humans are the accountability and the system should make their review cheap, fast, and evidence-backed.

We are on the second side of that argument. The playbook optimises for time-to-fix without removing human oversight. That matters more as AI coding assistants raise the volume of changes to review: in our analysis, 78% of AI-generated PRs contained a vulnerability. That is a feature, not a bug, for any team that has to answer to a CISO, an auditor, or a regulator.

The Failure Modes We Have Seen

Three failure modes show up repeatedly in the playbook’s first six months in production:

Failure mode 1 — The patch fixes the symptom, not the class

The first iteration of the patch generator occasionally produced patches that addressed the specific finding but did not remove the underlying vulnerability class. The fix was to add a class-level reasoning step to the patch proposal. Patches now include a “class removed” attestation that the reviewer can check.

Failure mode 2 — The replay verifier disagrees with the patch

About 3% of the time, the verifier that confirmed the original finding later re-runs the patched code and the exploit still reproduces. This is a sign the patch is incomplete. The pipeline catches this in CI and reverts automatically. The finding stays open.

Failure mode 3 — The reviewer’s CODEOWNERS does not match the file

The patch landed in the right branch, the CI re-test passed, and the audit trail was complete — but the reviewer assignment was wrong because the file had been moved across teams and CODEOWNERS had not been updated. The fix was to add an automated CODEOWNERS drift check to the pipeline.

These are not theoretical. They are the things that broke in the first six months and are now caught automatically.

What Your Team Does Tomorrow

If you are not running this playbook, three actions, in order:

1. Audit your current scanner. Can it produce a reachability path for the findings it produces, or just a CVSS score? If the answer is “just a score,” the bottleneck will not close.
2. Add a replay-verification pass. Manual is fine to start — a human re-runs the top 10 findings per week against a sandbox. The point is to prove the principle that findings that survive independent verification are the ones worth fixing.
3. Tie the patch to the same evidence. When the engineer opens the PR, the original finding, the graph node, and the replay reference should be one click away.

The playbook does not require AI. It does not require a vendor product. It requires structure, replay, and a tight feedback cycle. It also maps cleanly onto the “Respond to Vulnerabilities” practices in NIST’s Secure Software Development Framework (SP 800-218), which asks teams to assess, prioritize, and remediate vulnerabilities as a repeatable process.

Frequently Asked Questions

Where This Goes Next

The autonomous remediation playbook is the third leg of the Plexicus loop. Deep Code Analysis finds the flaws. AI Swarm Pentest replays them. Remediation closes them. The four-loop structure — propose, replay, fix, verify — is the operational definition of Proof-Driven AppSec and its vulnerability remediation process.

In 2027, the playbook will be table stakes. The teams that adopt it in 2026 will close the 17-day gap before the attackers close theirs further.

Related reading:

• From Alert to Fix: Closing the Loop with Proof-Driven AppSec — the full loop
• 78% of AI-Generated PRs Contain a Vulnerability — what your team is producing today
• Top 15 AI Pentest Tools — options for the replay-verification step