exploit-validation-agent

name	exploit-validation-agent
description	GRIMSEC Agent 8 — Exploit Validation Agent. Use when validating security findings from devsecops-repo-analyzer with Real Risk Score >= 7. Generates proof-of-concept exploits, proves exploitability through static analysis and code tracing, and produces structured validation reports. Triggered by keywords: exploit validation, PoC generation, prove exploitability, validate finding, RRS >= 7, reachability-analysis.json, grimsec validation, devsecops exploit, security finding confirmation.
license	MIT
metadata	{"author":"GRIMSEC","version":"1.0","agent-number":"8","suite":"GRIMSEC DevSecOps","inspired-by":"Raptor /validate pipeline"}

Exploit Validation Agent (Agent 8 — GRIMSEC)

When to Use This Skill

Load this skill when:

• Validating findings from the devsecops-repo-analyzer with Real Risk Score (RRS) >= 7
• Asked to generate proof-of-concept (PoC) exploits for security findings
• Confirming whether a vulnerability is actually exploitable
• Producing exploit validation reports for the executive-reporting-agent
• Any task involving reachability-analysis.json, app-context.json, or doc-profile.json from the GRIMSEC suite

Overview

This agent takes high-risk findings (RRS >= 7) and systematically attempts to prove they are exploitable. It generates minimal, safe proof-of-concept exploits for documentation purposes, classifies exploitability status, and produces structured reports.

Always read references/safety-guidelines.md before generating any PoC. All generated code is FOR SECURITY ASSESSMENT ONLY.

Input Files

File	Source Agent	Purpose
reachability-analysis.json	devsecops-repo-analyzer Stage 4	Primary findings (RRS >= 7 only)
app-context.json	devsecops-repo-analyzer	Data flow and framework context
doc-profile.json	devsecops-repo-analyzer	Security control inventory

Output Files

File	Description
exploit-validation/validation-report.json	Machine-readable structured results per finding
exploit-validation/pocs/	Directory of generated PoC files (one per finding)
exploit-validation/validation-summary.md	Human-readable summary for executive-reporting-agent

The 7-Stage Validation Pipeline

Input: reachability-analysis.json (findings with RRS >= 7)
  │
  ├─► Stage 0: Inventory
  ├─► Stage A: Quick Assessment
  ├─► Stage B: Attack Surface Mapping
  ├─► Stage C: Exploit Hypothesis
  ├─► Stage D: PoC Generation
  ├─► Stage E: Validation
  └─► Stage F: Report

Read references/validation-methodology.md for the full stage-by-stage methodology.

---

Stage 0: Inventory

Goal: Load and normalize the finding for pipeline processing.

1. Parse reachability-analysis.json. Filter to findings where real_risk_score >= 7.
2. For each finding, extract:
   • finding_id — unique identifier
   • vuln_type — e.g., sqli, xss, hardcoded_secret, cicd_injection, ssrf, auth_bypass, container_escape, iac_misconfiguration, sca_cve
   • location — file path, line range, function name
   • rrs — Real Risk Score
   • description — analyzer's finding description
   • reachability_path — call chain from entry point to sink (if available)
3. Load app-context.json to extract:
   • Framework/language
   • Authentication mechanisms
   • Data flow context for this component
4. Load doc-profile.json to extract:
   • Declared security controls (WAF, CSP, input validation libraries)
   • Mitigation notes flagged by prior agents
5. Output: normalized finding_context dict used by all subsequent stages.

---

Stage A: Quick Assessment

Goal: Determine if the finding can be confirmed without generating or running code.

Check the vuln_type against these trivially-confirmable conditions:

Vuln Type	Instant Confirm Condition
hardcoded_secret	Credential value is present in source; format matches known service pattern
iac_misconfiguration	Policy/config directly states the insecure value (e.g., "*" in S3 bucket policy)
sca_cve (known PoC exists)	CVE has a public PoC and the vulnerable function is imported and called
cicd_injection	Untrusted input variable used directly in run: step with no sanitization

If a finding meets an instant-confirm condition:

• Set status = EXPLOITABLE
• Document the evidence (the raw value, the config line, the CVE reference)
• Skip to Stage F (do not waste pipeline stages on already-confirmed findings)

If not instantly confirmable, continue to Stage B.

---

Stage B: Attack Surface Mapping

Goal: Identify all entry points that can reach the vulnerable sink.

1. Using reachability_path from the finding (if present) as the starting call chain.
2. Identify the entry point category:
   • HTTP endpoint (REST, GraphQL, WebSocket)
   • CLI argument
   • File input
   • Environment variable
   • Inter-service message (queue, event bus)
   • Third-party webhook
3. Identify the vulnerable sink:
   • Query execution (SQL, NoSQL, LDAP)
   • HTML/template rendering
   • Shell command execution
   • File read/write
   • Network request construction
   • Deserialization
4. Map trust boundaries crossed between entry point and sink:
   • Does user-controlled data cross into a privileged execution context?
   • Is there any intermediate processing that could sanitize the data?
5. Identify all parameters that flow from entry point to sink.
6. Note any authentication gates in front of the entry point (unauthenticated paths are higher severity).

Output: attack_surface dict with entry_points, sink, trust_boundaries_crossed, reachable_params, auth_required.

---

Stage C: Exploit Hypothesis

Goal: Formulate a specific, testable exploitation scenario.

Based on the vuln_type and attack_surface, generate a hypothesis that answers:

1. What input causes the vulnerability? (specific payload or value)
2. Which entry point do we use? (specific endpoint, parameter, or vector)
3. What observable behavior proves exploitation? (error message, data leak, OOB callback, privilege escalation, etc.)
4. What is the assumed attacker position? (unauthenticated, authenticated-low-priv, internal network, etc.)

Hypothesis format:

IF attacker sends [specific payload] to [specific entry point]
THEN [observable outcome] BECAUSE [code path / missing control]
WHICH proves [impact: data exfil / auth bypass / RCE / etc.]

Consult references/exploit-patterns.md for vuln-type-specific hypothesis templates.

---

Stage D: PoC Generation

Goal: Generate a minimal proof-of-concept that demonstrates the hypothesis.

BEFORE generating any PoC, re-read references/safety-guidelines.md.

PoC generation rules:

• Minimal: does exactly enough to prove exploitability, nothing more
• Annotated: every PoC file begins with the safety header (see below)
• Bounded: targets only the specific finding, not a general-purpose attack tool
• Non-destructive: demonstrates the vulnerability without deleting data, exfiltrating real data, or causing outages

Required PoC safety header:

# ============================================================
# FOR SECURITY ASSESSMENT ONLY — GRIMSEC Exploit Validation
# Finding ID: <finding_id>
# Target: <repo/component> (LOCAL ANALYSIS ONLY)
# DO NOT run against production systems
# DO NOT exfiltrate real data
# ============================================================

PoC by vuln_type:

Vuln Type	PoC Form
sqli	Python/curl snippet constructing the SQLi payload for the specific parameter
xss	HTML/JS payload + request showing injection point
auth_bypass	Request sequence demonstrating the bypass (missing token, JWT manipulation, etc.)
hardcoded_secret	Extract and display the credential value + service identification (DO NOT authenticate)
cicd_injection	Exact PR title/label/branch name payload that triggers code execution in the CI workflow
ssrf	Request with crafted URL showing internal redirect chain
container_escape	Command sequence demonstrating privileged escape (against local test environment only)
iac_misconfiguration	Show the config value + terraform/aws CLI command that would confirm the exposure
sca_cve	Reference public PoC + show the triggering call in the codebase

Save each PoC to exploit-validation/pocs/<finding_id>.<ext>.

---

Stage E: Validation

Goal: Assign an exploitability status and confidence level.

Evaluate the PoC and analysis against this decision tree:

Is the PoC trivially provable (hardcoded value, public config)?
  YES → EXPLOITABLE (confidence: HIGH)

Can the full attack path be traced in static analysis with no mitigations found?
  YES → LIKELY_EXPLOITABLE (confidence: MEDIUM–HIGH)

Is there a mitigation present (WAF, parameterization, escaping) but potentially bypassable?
  MAYBE → LIKELY_EXPLOITABLE (confidence: MEDIUM)

Does the code path require runtime state (session tokens, race conditions, specific DB state)?
  YES → NEEDS_RUNTIME (hand off to DAST agent)

Does static analysis prove the sink is unreachable or the input is sanitized?
  YES → RULED_OUT (false positive)

Status definitions:

Status	Meaning
EXPLOITABLE	PoC generated and confirmed, or trivially provable (e.g., hardcoded secret exists)
LIKELY_EXPLOITABLE	Code path analysis confirms reachability + no effective mitigations found; runtime PoC not generated
NEEDS_RUNTIME	Requires the running application to confirm; hand off to DAST agent
RULED_OUT	Analysis disproved the vulnerability; likely false positive

Assign:

• status: one of the four above
• confidence: HIGH / MEDIUM / LOW
• confidence_rationale: 1–2 sentences explaining the confidence level
• mitigations_found: list of any controls identified (even partial)
• bypass_possible: boolean — is the mitigation bypassable?

---

Stage F: Report

Goal: Produce structured output for downstream consumers.

Per-finding JSON record (append to validation-report.json):

{
  "finding_id": "<id>",
  "vuln_type": "<type>",
  "rrs": <score>,
  "validation_status": "<EXPLOITABLE|LIKELY_EXPLOITABLE|NEEDS_RUNTIME|RULED_OUT>",
  "confidence": "<HIGH|MEDIUM|LOW>",
  "confidence_rationale": "<string>",
  "attack_surface": { ... },
  "exploit_hypothesis": "<IF...THEN...BECAUSE...WHICH string>",
  "poc_file": "exploit-validation/pocs/<finding_id>.<ext>",
  "poc_summary": "<one-line description of the PoC>",
  "mitigations_found": [ ... ],
  "bypass_possible": true|false,
  "stage_skipped_to": "F",
  "analyst_notes": "<any additional context>"
}

Validation summary (validation-summary.md): Use the template at assets/templates/validation-report-template.md. Populate the executive summary table with counts by status, then list each EXPLOITABLE and LIKELY_EXPLOITABLE finding with its PoC summary.

Hand-off notes:

• EXPLOITABLE findings → flag for immediate escalation in executive-reporting-agent
• NEEDS_RUNTIME findings → queue for DAST agent with attack_surface context
• RULED_OUT findings → document for devsecops-repo-analyzer calibration

Running the Validation Script

Use scripts/validate-finding.py for automating the pipeline over a batch of findings:

python scripts/validate-finding.py \
  --findings reachability-analysis.json \
  --app-context app-context.json \
  --doc-profile doc-profile.json \
  --output-dir exploit-validation/

The script orchestrates all stages and writes the output files. Review and supplement with manual analysis for LIKELY_EXPLOITABLE and NEEDS_RUNTIME cases.

Integration Map

devsecops-repo-analyzer
  └── reachability-analysis.json (RRS >= 7)
        │
        ▼
  exploit-validation-agent (Agent 8)
        │
        ├── exploit-validation/validation-report.json
        ├── exploit-validation/pocs/
        └── exploit-validation/validation-summary.md
              │
              ▼
        executive-reporting-agent
        (proven exploits = stronger risk quantification evidence)
              │
        NEEDS_RUNTIME findings
              │
              ▼
        DAST Agent (future)

Reference Files

File	When to Read
references/validation-methodology.md	Detailed stage-by-stage methodology with decision tables
references/exploit-patterns.md	Vuln-type-specific patterns, payloads, and detection hints
references/safety-guidelines.md	ALWAYS read before generating any PoC or executing any command
assets/templates/validation-report-template.md	Template for validation-summary.md output