Scan Pipeline
Every DAST run executes as an ordered set of phases grouped into two visible stages: a deterministic DAST stage (broad automated coverage) and an AI-driven AI exploitation stage (depth, exploitation and triage). The scan detail page renders these phases live as a timeline.
This page documents what each phase does and how they chain. For the operator-facing walk-through see Running a scan and Reading results.
The two stages
Phase reference
| # | Phase | Stage | What it does |
|---|---|---|---|
| 0 | Recon & AI planning | DAST | Before any traffic: reconstructs the attack surface and builds a targeted test set - source analysis → attack map, STRIDE threat model, business-logic test plan, and your AI-pentest instructions are merged. |
| 1 | Authentication | DAST | Logs in (form / token / header), verifies the session via a logged-in indicator so the scan reaches pages behind the login wall. |
| 2 | Spider crawl | DAST | Classic crawler maps in-scope links, forms, parameters and endpoints. |
| 3 | AJAX / SPA crawl | DAST | Headless-browser crawl that executes JavaScript to discover client-rendered endpoints the classic spider misses. |
| 4 | Active scan | DAST | Injects payloads against discovered + targeted endpoints: SQLi, XSS, command/path injection, SSRF, header/auth issues. |
| 5 | Vulnerability signatures | DAST | Curated signature library: known CVEs, misconfigurations, exposed panels/secrets, default credentials. |
| 6 | Multi-engine scan | DAST | Several independent engines cross-check the attack surface; agreeing results raise confidence. |
| 7 | Out-of-band (OAST) | DAST | Collaborator payloads catch blind SSRF/RCE/SQLi/XXE - a received callback is hard proof. |
| 8 | DOM XSS (browser) | AI exploitation | Drives a real headless browser; a finding is raised only when the injected script actually executes. |
| 9 | Gray-box exploitation | AI exploitation | Source-informed deep tests: IDOR (two-user), broken access control, JWT flaws, SSTI, business-logic abuse. |
| 10 | Exploit verification | AI exploitation | Safely re-issues a minimal proof-of-exploit for high-impact findings - no destructive payloads. |
| 11 | AI triage | AI exploitation | LLM reviews findings: false-positive filtering, severity / business-impact adjustment, de-dup, fix suggestions. |
| 12 | Correlation & coverage | AI exploitation | Cross-references source predictions with dynamic hits, maps threat-model coverage, reconciles against prior scans. |
Lighter profiles skip the heavier AI exploitation phases; the deep profile enables every phase and the most aggressive crawl. Phases with nothing to do are marked skipped in the timeline rather than failing.
Recon: planning before traffic
Phase 0 is what makes scans targeted rather than brute-force. It fuses several inputs into a single plan before a single packet is sent.
When a target has source attached the scan becomes gray-box: it knows routes, parameters and sink locations, so it crafts precise attacks and produces higher-confidence findings. See Threat Models and Attack Map.
Proof over noise
High-impact findings are not trusted on signature alone - they pass through an explicit verification gate, and the most aggressive validation uses an agentic exploit loop that attempts a safe, minimal proof.
A verified finding carries a stored proof of exploit; exploit_status
records confirmed / likely / not_exploitable. This is the signal the
Priorities funnel treats as proven.
Where output goes
- Findings unify into the Vulnerabilities hub and each run is recorded as an Assessment.
- Coverage is quantified into a crawl/test coverage score.
- Correlated results feed Attack Chains.
Next
- Unified Data Model - how findings collapse into vulnerabilities.
- System Architecture - the surrounding platform.