Audit Code for Sensitive Data Zeroization

zeroize-audit detects missing zeroization of sensitive data (keys, seeds, nonces, secrets, tokens, PII) in C/C++ and Rust source, and specifically catches zeroization that compiler optimizations silently remove or weaken (dead-store elimination), requiring mandatory LLVM IR or assembly evidence before it will claim that. Capabilities span assembly-level analysis for register spills and stack retention, data-flow tracking of secret copies, heap allocator security warnings, semantic IR analysis of loop unrolling, control-flow graph path-coverage analysis, and generation of runtime validation tests. It is read-only against the audited codebase - it never modifies source, only writes analysis artifacts to a temporary working directory - and always produces a structured JSON report alongside a markdown one.

Use it for auditing cryptographic implementations, reviewing authentication systems, analyzing PII/credential handling, verifying secure cleanup in security-critical code, or investigating memory safety of sensitive data. It is explicitly not for general code review without a security focus, performance work unrelated to secure wiping, unrelated refactoring, or code with no identifiable secrets. It requires a valid build context (compile_commands.json for C/C++, or Cargo.toml plus a working cargo check and nightly toolchain for Rust) and compilable translation units; C/C++ prerequisites also include clang on PATH and several bundled extraction/emission scripts, each with its own documented fail-fast-or-warn behavior if missing. Findings claiming a wipe was "optimized away" are only ever valid with compiler evidence (an IR diff), never on source-level signals alone.

Configuration (via a path, compile_db or cargo_manifest, and optional YAML heuristics) controls which optimization levels get IR-compared (default O0/O1/O2 - O1 is the diagnostic level, since a wipe that disappears there is simple dead-store elimination), which languages run, and whether assembly (enable_asm, on by default), semantic IR, and CFG analysis are enabled. An 11-agent pipeline across 8 phases - preflight, MCP symbol resolution, source analysis (separate C/C++ and Rust analyzers), per-translation-unit compiler analysis, report assembly, proof-of-concept generation, PoC validation and verification, and optional runtime-test generation - writes namespaced finding IDs (F-SRC-, F-IR-, F-ASM-, F-RUST-MIR-, etc.) to a shared working directory to support parallel execution. Findings are recognized across 11 categories (MISSING_SOURCE_ZEROIZE, PARTIAL_WIPE, SECRET_COPY, OPTIMIZED_AWAY_ZEROIZE, STACK_RETENTION, REGISTER_SPILL, and others), each requiring specific evidence types before it can be raised at all. Every finding is scored for confidence based on independent signal count (2+ signals = confirmed, 1 = likely, 0 = needs_review) and gets a generated, compiled, and independently-verified proof-of-concept exploit as an additional evidence signal:

{
  "id": "ZA-0001",
  "category": "OPTIMIZED_AWAY_ZEROIZE",
  "severity": "high",
  "confidence": "confirmed",
  "language": "c",
  "file": "src/crypto.c",
  "line": 42,
  "symbol": "key_buf",
  "suggested_fix": "Replace memset with explicit_bzero or add compiler_fence(SeqCst) after the wipe"
}

Final output is a comprehensive final-report.md (executive summary, sensitive-objects inventory, findings grouped by severity/confidence with full evidence, confidence-gate summary, coverage stats) plus a machine-readable findings.json.

Recognizes established wipe APIs as valid zeroization - explicit_bzero, memset_s, SecureZeroMemory, OPENSSL_cleanse, sodium_memzero, and volatile wipe loops for C/C++; zeroize::Zeroize, Zeroizing<T>, and ZeroizeOnDrop for Rust - configurable with additional approved entries. Optionally integrates with Serena MCP for symbol/type/cross-file resolution (mcp_mode: off/prefer/require), downgrading SECRET_COPY, MISSING_ON_ERROR_PATH, and NOT_DOMINATING_EXITS findings to needs_review when MCP is unavailable and prefer mode is set, or stopping the run entirely under require mode. It explicitly refuses to accept common rationalizations for suppressing a finding - "the compiler won't optimize this away," "this is a hot path," "stack secrets clean up automatically," "memset is sufficient," "we'll fix it later" - retaining the finding and logging the attempted override instead.

Security engineers and auditors reviewing cryptographic, authentication, or PII-handling code in C/C++ or Rust who need compiler-verified proof - not just source-pattern matching - that sensitive data is actually wiped from memory and survives optimization, with an auto-generated, auto-validated exploit attached to every confirmed finding.