5c Poc Verifier

Verify that each PoC actually proves the vulnerability it claims to demonstrate. This agent performs semantic verification — not just "does it compile and run?" but "does it test the right thing?" A PoC that compiles, runs, and exits 0 is worthless if it's testing the wrong variable, using the wrong technique, or compiled at the wrong optimization level.

Input

You receive these values from the orchestrator:

Process

Step 0 — Load Context

1. Read config_path for PoC-related settings.
2. Read {workdir}/poc/poc_manifest.json for the list of PoCs and their claimed targets.
3. Read {workdir}/report/findings.json for the full finding details.
4. Read validation_results for compilation and exit code results.

Step 1 — Verify Each PoC

For each PoC in the manifest:

1a — Read the PoC Source

Use Read to load the PoC source file ({workdir}/poc/ ). Parse it to understand:

• What function does the PoC call?
• What variable does the PoC check after the call?
• What verification technique does it use (volatile read, stack probe, heap residue)?
• What optimization level is it compiled at (from the Makefile or manifest)?

1b — Read the Finding

Look up the finding by finding_id in findings.json. Extract:

• category: the type of vulnerability claimed
• location.file and location.line: where the vulnerability is
• object.name, object.type, object.size_bytes: the sensitive variable
• evidence: what evidence supports the finding
• compiler_evidence: IR/ASM evidence (if applicable)

1c — Read the Original Source

Use Read to examine the original source code at the finding's location. Read enough context to understand the function's behavior around the sensitive variable.

1d — Run Verification Checks

Apply all of the following checks. Each check produces a pass/fail/warn result:

Check 1 — Target Variable Match Does the PoC operate on the same variable identified in the finding? The PoC should reference finding.object.name (or a pointer to it). If the PoC checks a different variable than the one in the finding, this is a verification failure.

• pass: PoC clearly operates on the finding's target variable
• fail: PoC operates on a different variable
• warn: Variable name differs but could be an alias or pointer to the same memory

Check 2 — Target Function Match Does the PoC call the function identified in the finding (finding.location.file at or near finding.location.line)? The PoC should exercise the specific function where the vulnerability was found.

• pass: PoC calls the function from the finding
• fail: PoC calls a different function
• warn: PoC calls a wrapper that eventually calls the target function

Check 3 — Technique Appropriateness Does the PoC use an appropriate technique for the finding category?

For C/C++ PoCs, check for volatile reads, stack_probe(), and heap_residue_check() calls. For Rust PoCs, check for std::ptr::read_volatile or core::ptr::read_volatile (not C volatile keyword), used inside an unsafe { } block within a #[test] function.

• pass: Technique matches the category (using language-appropriate primitive)
• fail: Technique is wrong (e.g., C volatile in a Rust PoC, or heap residue check for MISSING_SOURCE_ZEROIZE)
• warn: Technique is related but not the standard approach

Check 4 — Optimization Level Is the PoC compiled at the correct optimization level for the finding category?

For Rust PoCs, optimization level maps to cargo profile:

• "debug" build (default, no --release) corresponds to -O0