How scanning works

Pipeline stages

Twelve stages in four phases. S0 to S9 find and report: S2, S4 and S6 run agentic model sessions, S8 asks a model for exploit chains, and the rest is code. S10 and S11 propose and score fixes. A scan started from this console stops at S9 unless told otherwise.

Discovery

S0 Static seedMatches built-in source and sink patterns against the source text. No model call; the code graph is built here.

S1 PreprocessMerges the S0 seed, CVEs and controls, and derives modules and languages from the code graph. No model call.

Analysis

S2 Threat modelingAgentic STRIDE and OWASP threat model grounded in the code graph: assets, trust boundaries, ranked threats.

S3 DecomposeMints one investigation unit per threat with a validated surface. No model call.

S4 Deep diveInvestigates units in batched sessions with graph tools and detection skills.

Verification & reporting

S5 Enrich & detectorsFills evidence and coordinates, drops rows that do not exist, and adds deterministic detector findings. No model call.

S6 Adversarial verificationVerifies findings in batches: TRUE or FALSE_POSITIVE, a 0-10 confidence and CVSS.

S7 DeduplicationCollapses findings at one site that share a CWE weakness. Semantic dedup is off in shipped profiles.

S8 Ranking & chainsOrders findings by severity in code; the model adds exploit chains and the summary.

S9 SARIFBuilds SARIF 2.1.0 from the typed report. No model call.

Remediation & validation

S10 Remediation agentProposes, and in fix mode applies, a minimal fix per finding.

S11 Validation panelAn adversarial panel scores each fix against weighted gates.

Multi-pass plans

S2 names at most step2.max_threats threats (50 on the shipped default) and S3 mints one unit per threat, which S4 investigates four units to a session. S2 reads at most step2.max_graph_files files as evidence (220), so a larger repository is split into passes until every file sits inside one pass's frontier.

A plan splits the repository into passes over files: every scannable file lands in exactly one pass and no file is scanned twice, so no quota is spent twice. A pass excludes the files it does not own, because the harness takes exclusions and no include list.

The plan advances itself. When a pass finishes, the next one waits until the session window reopens, read from the reset time the CLI returns with its 429. Two quota stops on one pass, or two failures in a row, stops the plan. A pass whose S2 found nothing to investigate is not counted as a failure, and a configuration error blocks the plan without spending a retry.

Commands

scan

Detection, stops at S9 by default

remediate

S10, patch captured, clone restored

validate

S11, scores fixes already applied

What writes to your source

A scan that runs past S9 lets S10 edit source files in the clone, and a scan restores nothing: the next scan of that repository reads patched source. The console refuses such a run unless the caller acknowledges the writes.

Propose fixes is deliberately not gated. S10 writes there too, but the console captures the diff as a patch and restores the clone, so the tree ends where it started and the change reaches the git provider only as a pull request someone approves. A failed restore is reported in the run log, and that is the case that actually leaves edits behind.

Findings are model-generated

Findings are LLM-generated candidates that need human review.

S6 gives each finding a TRUE or FALSE_POSITIVE verdict with a 0-10 confidence and drops what it rejects. The verifier is part of the same LLM pipeline, so a verdict is not proof and its confirmation rate is not a measured precision.

It is SAST: it reads source on disk, never a running service. CVSS is computed from the vector the model wrote, and severity is that band. A finding can be real in the file and unreachable in production, so read the evidence first.