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.
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.