Audit Code for Sensitive Data Zeroization

Detects missing zeroization of sensitive data (keys, seeds, nonces, secrets, tokens, PII) in C/C++ and Rust source code, and specifically identifies zeroization that compiler optimizations quietly remove or weaken (e.g. dead-store elimination) - flagging that only with mandatory LLVM IR/assembly evidence, never on a source-level guess alone. Capabilities span assembly-level register-spill and stack-retention analysis, data-flow tracking of secret copies, heap allocator security warnings, semantic IR analysis of unrolled loops, control-flow graph path-coverage checks, and runtime validation test generation.

Use it for auditing cryptographic implementations, reviewing authentication systems, analyzing code that handles PII or sensitive credentials, or verifying secure cleanup in security-critical codebases - not for general code review without a security focus, performance work unrelated to secure wiping, or refactoring unrelated to sensitive data. It carries a mandatory confirmation gate: before running anything that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target, it must get the exact target, confirmed written authorization and scope, and explicit user confirmation in the conversation - staying read-only and defensive-guidance-only otherwise.

Requires a repo path plus either a compile_commands.json (C/C++) or Cargo.toml (Rust); runs read-only against the audited code, writing analysis artifacts to a temporary working directory. An 11-agent pipeline across 8 phases (preflight, source analysis, per-translation-unit compiler analysis, report assembly, PoC generation/validation/verification, optional test generation) produces two outputs: a human-readable final-report.md and a machine-readable findings.json. Each finding requires at least 2 independent evidence signals to be marked confirmed (1 signal = likely, 0 strong signals = needs_review); across 11 named finding categories, some - OPTIMIZED_AWAY_ZEROIZE, STACK_RETENTION, REGISTER_SPILL - are never valid without specific IR or assembly evidence, regardless of source-level signals or user assertions. Every finding is validated against a bespoke generated proof-of-concept that is compiled, run, and independently verified to actually test the claimed vulnerability:

{
  "id": "ZA-0001",
  "category": "OPTIMIZED_AWAY_ZEROIZE",
  "severity": "high",
  "confidence": "confirmed",
  "language": "c",
  "file": "src/crypto.c",
  "line": 42,
  "symbol": "key_buf",
  "evidence": "store volatile i8 0 count: O0=32, O2=0 - wipe eliminated by DSE",
  "compiler_evidence": {
    "opt_levels": ["O0", "O2"],
    "o0": "32 volatile stores targeting key_buf",
    "o2": "0 volatile stores (all eliminated)",
    "diff_summary": "All volatile wipe stores removed at O2 - classic DSE pattern"
  },
  "suggested_fix": "Replace memset with explicit_bzero or add compiler_fence(SeqCst) after the wipe",
  "poc": {
    "file": "generated_pocs/ZA-0001.c",
    "makefile_target": "ZA-0001",
    "compile_opt": "-O2",
    "requires_manual_adjustment": false,
    "validated": true,
    "validation_result": "exploitable"
  }
}

Requires clang or cargo +nightly for IR and assembly emission, and optionally Serena MCP (via uvx) for symbol and cross-reference resolution - findings like SECRET_COPY and MISSING_ON_ERROR_PATH get automatically downgraded to needs_review when MCP is unavailable. Recognizes approved wipe APIs per language (explicit_bzero, memset_s, SecureZeroMemory, OPENSSL_cleanse, sodium_memzero for C/C++; zeroize::Zeroize, Zeroizing<T>, ZeroizeOnDrop for Rust) and recommends them in that preference order as fixes.

Security engineers and auditors reviewing cryptographic or credential-handling code in C/C++ or Rust who need compiler-verified proof that sensitive data is actually wiped - not just source code that looks like it wipes - and who want a skill that refuses common rationalizations ("the compiler won't optimize this away," "memset is sufficient") for suppressing a finding.