Docs / Scanning

Findings & workflow

Findings are stateful work items moved by a deterministic transition table (workflow/states.py). Illegal transitions are impossible; every legal one is recorded on an append-only timeline.

The 21-state lifecycle

NEW → DEDUPED → OWNER_RESOLVED → VALIDATING
  → LIVE_VALID | DEAD_INVALID | PARTIAL_CONFIDENCE | UNVERIFIED
  → DECISION (escalate | remediate | investigate | close)
  → PENDING_APPROVAL → APPROVED | REJECTED
  → REMEDIATION_PLANNED → ESCALATED
  → VERIFYING → CLOSED
REOPENED re-enters the flow · failures → dead-letter queue (retry-limited)

Ownership resolution

Owners resolve in order from git blame, CODEOWNERS, and a configurable team map — so escalations land with the person who can fix the exposure, not a shared inbox.

Decision engine

Routing is rule-based and reproducible: validation outcome × exposure × confidence → escalate, remediate, investigate, or close. No LLM sits in the decision path. Critical findings wait in a human approval queue; nothing destructive happens without a person's decision. Remediation is advisor-only — plans and checklists, never provider-side revocation.

Working a finding

Assignment, comments, and an append-only timeline per finding
SLA tracking with breach detection
Closure requests require verification before CLOSED
Suppress with POST /agent/findings/{id}/suppress
Criticality 0–100 — public-leak- and validity-aware — ranks the queue

Source: workflow/states.py · finding_management/ · orchestrators/agent/

← Scanning modes Validation →