Why MTTR matters more than detection rate
Security tooling tends to compete on detection rate: how many vulnerabilities did the tool find that others missed? Detection rate is a real metric, but it is not the one that most directly determines your security posture. The number that matters for operational risk is mean time to remediate — how long from confirmed finding to verified fix.
An industry survey of development teams (Ponemon Institute 2025) puts average MTTR for application vulnerabilities at 47 days. In our internal benchmark across AssurePort scans where customers have self-reported remediation timelines, the teams using AI-assisted findings (with remediation code suggestions and verified PoC) reported average MTTR of under 8 days. This is an internal benchmark, not a controlled study. It reflects the specific population of teams who chose to use automated scanning and self-reported their results. We flag it as directional, not prescriptive.
The mechanism is straightforward: a finding that arrives with a confirmed proof-of-concept, a specific file and line reference, and a language-specific patch suggestion can be actioned without a separate triage and investigation step. The engineering team receives something they can act on in the same sprint, rather than something they need to reproduce and understand before they can begin fixing.
External data reinforces why fast CVE remediation is now a structural requirement, not a nice-to-have. Verizon's 2025 Data Breach Investigations Report found that vulnerability exploitation as an initial access vector grew 34% year over year, and that the median time to remediate vulnerabilities on internet-facing edge devices was 32 days — with only 54% of known-vulnerable edge devices fully patched during the study window. For critical edge-device flaws, the median gap between public disclosure and mass exploitation was effectively zero days: attackers moved the moment the vulnerability became known. When the exploitation window is measured in hours, a CVE remediation process measured in weeks is a liability you can quantify.
The pipeline from surface to remediation
The AssurePort Web Pentest engine runs 13 coordinated agents across 5 phases. The phases are sequential; each agent outputs structured findings that the next phase consumes. Here is how a BOLA finding moves through the pipeline from detection to remediation guidance:
Reconnaissance
Tech stack fingerprinting, endpoint enumeration, auth flow mapping. The recon agent builds a surface map that informs which exploit agents are worth running. A Node.js/Express API behaves differently from a PHP monolith under the same payload.
Auth and session analysis
Token structure inspection, session fixation probes, JWT algorithm confusion tests. The auth agent outputs a signed map of which endpoints require authentication and which do not — the precondition for BOLA testing.
Exploit attempt with PoC generation
The exploit agent runs targeted payloads and captures HTTP-level evidence. For a BOLA finding, this means a curl command showing User A’s token accessing User B’s resource — a working proof-of-concept that an engineer can reproduce in 30 seconds.
Validation and false-positive filtering
A validation agent retests the finding with a second payload to confirm it is reproducible. Findings that cannot be confirmed are marked status: "unconfirmed" and surfaced separately. Only confirmed findings proceed to the remediation phase.
Remediation synthesis
The remediation agent inspects the tech stack, the specific endpoint pattern, and the exploit proof-of-concept, then generates a language-specific fix recommendation. For a Node.js/Express BOLA: a middleware snippet that enforces tenant_id comparison before returning any resource.
What a remediation suggestion actually looks like
For a BOLA finding on a Node.js API endpoint, the remediation agent might output something like the following — not generic advice, but code shaped to the specific route pattern it observed:
// Before: vulnerable route handler
router.get('/api/documents/:id', authMiddleware, async (req, res) => {
const doc = await db.documents.findById(req.params.id);
return res.json(doc);
});
// After: enforce object-level authorisation
router.get('/api/documents/:id', authMiddleware, async (req, res) => {
const doc = await db.documents.findById(req.params.id);
if (!doc || doc.tenantId !== req.user.tenantId) {
return res.status(403).json({ error: 'Forbidden' });
}
return res.json(doc);
});This is not a fix the agent invents from first principles. It is derived from the exploit evidence: the agent observed that the endpoint returned data for a resource belonging to a different tenant when presented with a valid token for another tenant. The fix is a direct response to the demonstrated exploit path.
Unconfirmed findings: Not every potential issue reaches remediation. If the validation agent cannot reproduce a finding, it is flagged status: "unconfirmed" with the raw evidence preserved. Unconfirmed findings are displayed in the scan report with a distinct label. Teams should investigate them, but they should not carry the same urgency weight as confirmed findings with working PoC.
The GitHub SAST engine: finding CVEs before deployment
The Web Pentest engine finds runtime vulnerabilities in deployed applications. The GitHub SAST engine (also live in AssurePort v1.23.x) finds them in the repository before deployment. The seven-agent GitHub pipeline covers:
- Hardcoded secrets and credentials in source files and git history
- Dependency CVEs (npm, PyPI, Maven, Cargo, Go modules)
- Infrastructure-as-Code misconfigurations (Terraform, Kubernetes YAML, Dockerfile)
- Auth implementation anti-patterns (weak JWT algorithms, missing CSRF protection)
- OWASP Top 10 source-level patterns (SQL injection, XSS, SSRF in code)
For dependency CVEs, the SAST pipeline maps the CVE ID, the affected version, the patched version, and whether the vulnerability is reachable from the application’s call graph. A dependency with a known CVE that is imported but never called in a path that reaches user-controlled input is a different priority than one directly in the authentication flow.
The audit trail: why the finding timestamp matters
Beyond MTTR, the audit value of an AI-assisted finding is in the structured trail it creates. Each confirmed finding in AssurePort includes:
- Timestamp of first detection (UTC, stored in D1 weur)
- Timestamp of validation confirmation
- CVSS v3.1 base score with vector string
- Affected endpoint and parameter
- Proof-of-concept HTTP transaction
- Remediation status (open / in-progress / resolved / accepted risk)
This structured record is the artefact that satisfies ISO 27001 Annex A 8.8 (vulnerability management) and DORA Article 10 (continuous vulnerability management). A finding with a confirmed timestamp and a resolution timestamp gives auditors the evidence they need to verify your vulnerability management SLA is being met.
Frequently Asked Questions
What is CVE remediation and why does remediation speed matter?
CVE remediation is the process of fixing a confirmed vulnerability from detection through to a verified patch. Speed matters because attackers now weaponise disclosed flaws in hours — Verizon's 2025 DBIR found the median time from publication to mass exploitation of critical edge-device vulnerabilities was effectively zero days. A CVE remediation process measured in weeks leaves a wide exposure window.
How do AI agents accelerate CVE remediation?
AI agents shorten CVE remediation by delivering a finding that already includes a confirmed proof-of-concept, the exact file and line reference, and a language-specific patch suggestion. The engineering team can act in the same sprint instead of spending days reproducing and triaging the issue before any fix begins.
Is AI-generated fix code verified before it reaches my team?
Yes. AssurePort's validation agent retests each finding with a second payload before it enters CVE remediation. Findings that cannot be reproduced are flagged status: "unconfirmed" and surfaced separately, so only confirmed findings with working proof-of-concept carry full urgency.
How does automated CVE remediation support ISO 27001 and DORA evidence?
Each finding produces a timestamped record — detection time, validation time, CVSS score, affected endpoint, and resolution status. That structured CVE remediation trail is exactly the evidence ISO 27001 Annex A 8.8 and DORA Article 10 auditors ask for to verify your vulnerability management SLA.
How much does it cost to start?
AssurePort pricing starts at $69 for a single scan with no subscription, and $199/month for the Pro plan. Both the Web Pentest and GitHub SAST engines deliver confirmed findings with proof-of-concept and language-specific remediation code.