v7 — Vulnerability Validation & Proof Orchestration

Sprint 028 transforms a vulnerability hypothesis into a validated, proved, report-ready finding with defensible evidence, reproduction, proof, impact and provenance.

Detection
   -> Hypothesis
   -> Evidence
   -> Independent Validation
   -> Reproducibility
   -> Proof
   -> Impact
   -> Validated Finding

Core principle

A scanner result is an input, never a confirmed vulnerability. HunterX optimizes not for “how many vulnerabilities were detected” but for “how many security findings were validated, proved, reproduced and supported with defensible evidence”.

• A hypothesis is not a finding.
• A finding without sufficient evidence is not validated.
• A validated finding without reproducibility is incomplete where reproducibility is required.
• A PoC that cannot be replayed is not proof.
• A proof without provenance is not report-grade evidence.
• A high AI confidence score is never a substitute for evidence.

Finding lifecycle

The canonical lifecycle state machine lives in hunterx.domain.vulnerability_finding.lifecycle. Every transition declares the evidence purposes it requires (hypothesis, validation, proof, reporting) and refuses to advance without them:

CANDIDATE -> SUPPORTED -> VALIDATION_REQUIRED -> VALIDATING -> VALIDATED -> PROOF_REQUIRED -> PROVING -> PROVED -> REPORT_READY

Terminal states: REPORT_READY, DISPROVED, DUPLICATE, OUT_OF_SCOPE, REJECTED. DISPUTED keeps the finding open pending conflict resolution.

Evidence model

Evidence is provenance-backed, redacted, hash-stable and quality-band (low/medium/high/proof). Kinds distinguish detection signatures, version and header evidence, reflection, behavioral and differential database behavior, controlled callbacks, independent reproduction, controlled proof, replay, authorization-state comparison, secrets, cloud exposure and business state-transition evidence.

Evidence Requirement Engine

hunterx.domain.vulnerability_finding.evidence determines, per vulnerability class and purpose:

• what evidence exists,
• what evidence is missing (EvidenceGap),
• what evidence is contradictory,
• what is required for hypothesis support, validation, proof and reporting.

Evidence sufficiency

Sufficiency is quality-aware and explainable — never a tool count. For SQL injection, for example:

• reflection alone is INSUFFICIENT,
• differential database behavior is stronger,
• independent reproduction is SUFFICIENT_FOR_VALIDATION,
• a reproducible controlled proof is SUFFICIENT_FOR_PROOF,
• report-grade reproduction + proof is REPORT_READY.

Validation strategies & strategy engine

hunterx.domain.vulnerability_finding.strategy ranks strategies per finding from its class, target intelligence, endpoint, parameters, method, authentication state, existing evidence, tool capabilities, scope, mission mode and risk policy. Strategy families cover SQL injection, XSS, SSRF, SSTI, LFI, RFI, XXE, RCE, IDOR, broken access control, authentication flaws, command injection, path traversal, open redirect, CSRF, CORS misconfiguration, host header injection, HTTP request smuggling, JWT weaknesses, GraphQL authorization, API authorization, cloud exposure, secret exposure, known CVEs, business logic and unknown behavior.

Each strategy declares a safe validation policy: risk level, required authorization, expected impact, safe alternatives, maximum execution intensity, stop conditions, rollback requirements and proof limitations.

Execution & tool chain

hunterx.domain.vulnerability_finding.execution builds a dynamically selected tool chain (precondition -> probe -> observation -> correlation -> verification -> proof -> replay). Actual tool invocation happens only through the Tool Integration SDK ExecutionEngine; tools are selected through the Tool Capability Registry (Sprint 025), never hardcoded one-per-vulnerability. The chain is scope- and safety-checked and fails closed.

Reproducibility & replay

ReproducibilityEngine records request, method, headers, cookies where authorized, parameters, payload reference, environment, response characteristics, timing, callback evidence and expected vs actual result, redacting sensitive values.

PoCReplayVerifier verifies a replay only when the target, scope, vulnerability hypothesis, relevant input, security behavior and evidence class all match. An HTTP 200 alone is never a successful replay.

PoC lifecycle

hunterx.domain.vulnerability_finding.poc:

GENERATED -> STATIC_VALIDATED -> EXECUTION_READY -> REPLAYED -> BEHAVIOR_CONFIRMED -> EVIDENCE_CAPTURED -> PROOF_VALIDATED

REJECTED is reachable from static validation (malicious content, secret patterns, out-of-scope references). A PoC is minimal, reproducible, deterministic, scope-bound, sanitized and report-friendly.

Impact assessment

ImpactAssessmentEngine reports impact only for dimensions positive evidence supports: confidentiality, integrity, availability, authorization boundary, data exposure, privilege boundary, remote execution, account takeover, cloud resource access and business impact. Maximum impact is never inferred.

Confidence engine

ConfidenceEngine derives an explainable numeric score from detection evidence, behavioral evidence, independent validation, reproducibility, impact evidence, proof state, evidence quality, source reliability, contradictions (negative) and freshness. Levels: LOW/MEDIUM/HIGH/VERY_HIGH/PROVEN. PROVEN requires a replayed, verified, evidence-captured PoC.

Contradiction handling

Conflicting evidence is never silently discarded. Conflicts are persisted (FindingConflict), investigated, retested, compared across conditions, evaluated for freshness, then resolved or the finding is marked DISPUTED.

False-positive reduction

Explicit rejection criteria (generic error responses, reflection without execution, timeouts without causal evidence, scanner-only signatures, stale historical evidence, unrelated callbacks, uncontrolled redirects, non-deterministic behavior, insufficient authorization context). Rejected findings retain their evidence and the rejection reason; no false positive may become REPORT_READY.

Deduplication & root cause

FindingDeduplicationEngine correlates target, asset, endpoint, parameter, class, behavior, evidence, root cause and proof and distinguishes the same finding, the same root cause, the same vulnerability across endpoints, related findings and independent findings. FindingRootCause groups symptoms sharing one underlying condition.

Unknown-behavior validation

UnknownBehaviorClassifier characterizes unknown behavior, generates hypotheses, runs controlled experimentation, assesses security relevance and classifies as KNOWN_CLASS, KNOWN_VARIANT, APPLICATION_SPECIFIC, NOVEL_BEHAVIOR or UNRESOLVED. It never labels a behavior “zero-day” solely because no local signature exists.

Business logic, authorization, API, cloud, CVE

• Business logic findings use multi-step state-transition evidence.
• Authorization findings compare unauthenticated, actor A, actor B and privileged contexts with protected credentials.
• API validation covers REST, JSON, GraphQL, webhooks and WebSockets.
• Cloud validation covers public exposure, misconfiguration, storage, identity/configuration, webhooks and resource access within cloud-specific authorization boundaries.
• Known CVE matches are candidates, never confirmation; validation considers version, configuration, affected component, exposure, vendor conditions, observed behavior and available proof.

Exploitation boundary

DETECTION < VALIDATION < PROOF < IMPACT_DEMONSTRATION < EXPLOITATION. The engine chooses the minimum stage necessary and never escalates to full exploitation merely to raise confidence.

Report readiness, package & redaction

ReportReadinessChecker evaluates a first-class checklist (title, asset, location, description, impact, severity, evidence, reproduction, proof, validation status, confidence, scope, redaction, provenance). A finding with missing mandatory evidence is incomplete. FindingPackage consolidates the finding, evidence, reproduction, PoC, impact, timeline, tool provenance, validation and proof history, confidence explanation and redaction metadata for the Reporting Engine. Redaction masks passwords, tokens, API keys, cookies, session identifiers, private credentials, unnecessary PII and internal secrets while preserving enough for reproduction.

Events

Typed finding.* events: finding.created, finding.supported, finding.validation.started, finding.validation.completed, finding.evidence.added, finding.evidence.conflict, finding.proof.required, finding.proof.started, finding.proof.replayed, finding.proof.validated, finding.impact.assessed, finding.confidence.updated, finding.duplicate.detected, finding.disproved, finding.report_ready. Every event carries mission_id, target_id, finding_id, correlation_id, timestamp and provenance.

Persistence

All lifecycle records persist through the TIDB entity set (hunterx.domain.entities.tidb.finding_orchestration) via the TidbRepositoryFactory: finding records, evidence requirements and gaps, validation attempts, PoCs, replays, impact and confidence assessments, conflicts, deduplication decisions, root causes, unknown-behavior profiles, reproductions, report checklists, state transitions and report packages. No uncontrolled JSON-only persistence.

AI integration

AI may assist with hypothesis interpretation, strategy generation, PoC drafting, evidence interpretation, impact reasoning, novel-behavior analysis and report wording. AI cannot declare proof without evidence, override policy, expand scope, execute arbitrary generated commands, mark findings validated without validation or claim impact without evidence. All AI-generated actions pass through Policy -> Validation -> Execution -> Evidence -> Verification. The entire engine is deterministic and works identically without AI.

Security

Scope escape, cross-target and cross-mission leakage, malicious tool output, prompt injection, malicious PoC content, secret and credential leakage, unsafe proof escalation, replay against the wrong target and stale evidence reuse are covered by tests/security/test_finding_orchestration_security.py. Evidence values are redacted at capture so secrets never persist verbatim.

Testing

• Golden datasets: tests/golden/finding/scenarios.json + tests/golden/test_finding_golden.py (SQLi, XSS, SSRF, SSTI, LFI, RCE, IDOR, authorization, GraphQL authorization, cloud exposure, secret exposure, known CVE, false positive, conflicting evidence, duplicate, unknown behavior, business logic).
• Acceptance: tests/acceptance/test_finding_orchestration_acceptance.py.
• Architecture: tests/architecture/test_finding_orchestration_architecture.py.
• Security: tests/security/test_finding_orchestration_security.py.
• Performance: tests/performance/test_finding_orchestration_benchmarks.py.
• Platform integration: tests/integration/test_finding_orchestration_platform.py.
• Unit: tests/unit/test_finding_orchestration_{domain,engines,service}.py.

Extension model

Add a vulnerability class by extending FindingVulnerabilityClass, the per-class evidence requirement tables in evidence.py, and a ValidationStrategyFamily with its safe policy and tool candidates in strategy.py. The strategy engine, execution engine, lifecycle and reporting adapt automatically.