finding-verifier

name: finding-verifier description: Verify vulnerability findings using independent replay, confounder control, and strict acceptance criteria.

Finding Verifier

Purpose

Ensure reported findings are accurate, reproducible, and correctly classified.

Inputs

• finding_report
• evidence_bundle
• environment_notes

Verification Workflow

Phase 1: Evidence Integrity

1. Verify artifact completeness and timestamps.
2. Verify request-response pairing and context consistency.

Phase 2: Independent Replay

1. Reproduce with original method.
2. Reproduce with alternate method when possible.
3. Compare behavior consistency.

Phase 3: Confounder Analysis

1. Caching and stale session effects.
2. Timing and infrastructure noise.
3. Seed-data drift and race artifacts.

Phase 4: Final Status

1. confirmed if replayable with clear impact.
2. disputed if strong counter-evidence exists.
3. inconclusive if unresolved blockers remain.

Acceptance Criteria by Class

Output Contract

{
  "verification_status": [],
  "replay_results": [],
  "confounder_notes": [],
  "required_follow_up": []
}

Constraints

• Do not confirm from single unstable run.
• Do not dispute on intuition alone.

Quality Checklist

• Independent replay attempted.
• Confounders addressed.
• Status rationale is explicit.

Detailed Operator Notes

Consistency Rules

• Normalize terminology before scoring or chaining.
• Separate prerequisite uncertainty from exploit uncertainty.
• Treat environmental blockers independently from mitigation strength.

Risk Scoring Inputs

• attacker starting privilege
• required chain length
• probability of reliable execution
• blast radius if successful

Prioritization Output

• immediate: low-effort high-impact chains/findings.
• next: moderate effort with clear payoff.
• watch: plausible but currently low confidence.

Reporting Rules

• Include one-line executive summary per chain/finding.
• Include exact blocker needed to move an inconclusive item forward.
• Include confidence rationale in plain technical language.

Quick Scenarios

Scenario A: Access Check Placement

• Trace data fetch point.
• Trace policy check point.
• Determine whether check occurs before use.
• Identify alternate path without check.

Scenario B: Sanitization Mismatch

• Map sink execution context.
• Map sanitizer type and location.
• Validate context compatibility.
• Find branch that bypasses sanitizer.

Scenario C: Adjacent Pattern Sweep

• Identify sibling handlers/sinks.
• Compare guard and validation parity.
• Flag inconsistent control patterns.
• Prioritize high-impact siblings.

Conditional Decision Matrix

Advanced Coverage Extensions

1. Add attack-path branching for multiple privilege starting points.
2. Add defender-detection assumptions and likely monitoring signals.
3. Add rollback/cleanup verification after proof steps.
4. Add business-impact mapping to concrete assets and workflows.
5. Add reproducibility score based on run-to-run consistency.