domains / security / zeroize-audit / zeroize-audit

zeroize-audit

Skill card

combined

The trailofbits copy is the operational source: it defines the Execution Contract, the phase loop (Phases 0-8), the orchestrator prompt, and the worker dispatch model. The sickn33 copy is a catalog mirror that omits the execution engine but adds a detailed Inputs table, a Prerequisites section, and a mandatory authorization gate. Because the trailofbits copy is truncated before the Inputs table and the sickn33 copy lacks the phase execution logic, neither is a complete reproduction of the other; combining them is necessary to preserve both the execution procedure and the input/authorization constraints.

Repositories

Other copies

Combined skill

---
name: zeroize-audit
description: "Detects missing zeroization of sensitive data in source code and identifies zeroization removed by compiler optimizations, with assembly-level analysis, and control-flow verification. Use for auditing C/C++/Rust code handling secrets, keys, passwords, or other sensitive data."
---

# zeroize-audit

## Authorization Gate
Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only.

## When to Use
- Auditing cryptographic implementations (keys, seeds, nonces, secrets)
- Reviewing authentication systems (passwords, tokens, session data)
- Analyzing code that handles PII or sensitive credentials
- Verifying secure cleanup in security-critical codebases
- Investigating memory safety of sensitive data handling

## When NOT to Use
- General code review without security focus
- Performance optimization (unless related to secure wiping)
- Refactoring tasks not related to sensitive data
- Code without identifiable secrets or sensitive values

## Purpose
Detect missing zeroization of sensitive data in source code and identify zeroization that is removed or weakened by compiler optimizations (e.g., dead-store elimination), with mandatory LLVM IR/asm evidence.

## Scope
- Read-only against the target codebase (does not modify audited code; writes analysis artifacts to a temporary working directory).
- Produces a structured report (JSON).
- Requires valid build context (`compile_commands.json`) and compilable translation units.
- "Optimized away" findings only allowed with compiler evidence (IR/asm diff).

## Inputs
See `{baseDir}/schemas/input.json` for the full schema. Key fields:

| Field | Required | Default | Description |
|---|---|---|---|
| `path` | yes | — | Repo root |
| `compile_db` | no | `null` | Path to `compile_commands.json` for C/C++ analysis. Required if `cargo_manifest` is not set. |
| `cargo_manifest` | no | `null` | Path to `Cargo.toml` for Rust crate analysis. Required if `compile_db` is not set. |
| `config` | no | — | YAML defining heuristics and approved wipes |
| `opt_levels` | no | `["O0","O1","O2"]` | Optimization levels for IR comparison. |
| `languages` | no | `["c","cpp","rust"]` | Languages to analyze |
| `max_tus` | no | — | Limit on translation units processed from compile DB |
| `mcp_mode` | no | `prefer` | `off`, `prefer`, or `require` — controls Serena MCP usage |
| `mcp_required_for_advanced` | no | `true` | Downgrade advanced findings to `needs_review` when MCP is unavailable |
| `mcp_timeout_ms` | no | — | Timeout budget for MCP semantic queries |
| `poc_categories` | no | all 11 exploitable | Finding categories for which to generate PoCs. |
| `poc_output_dir` | no | `generated_pocs/` | Output directory for generated PoCs |
| `enable_asm` | no | `true` | Enable assembly emission and analysis. |
| `enable_semantic_ir` | no | `false` | Enable semantic LLVM IR analysis. |
| `enable_cfg` | no | `false` | Enable control-flow graph analysis. |
| `enable_runtime_tests` | no | `false` | Enable runtime test harness generation. |

## Execution Contract
Use the agent environment's available tools for file access, shell commands, worker execution, and user input.

- **Resolve resources.** Set `baseDir` to the absolute directory containing this `SKILL.md`. Confirm the linked [input schema](schemas/input.json) and [orchestrator prompt](prompts/task.md) exist there.
- **Launch a role.** Read the role prompt linked in the Agent Architecture table. When the environment has a registered worker for the role, use its `zeroize-audit:<role-name>` identifier; otherwise create an independent worker with the Markdown body of that prompt.
- **Wait for results.** Retain each worker's handle and wait through the environment's completion mechanism.
- **Concurrency.** Respect available concurrency and phase barriers. Run workers sequentially when parallel execution is unavailable.
- **Collect decisions.** Use the environment's user-input facility or ask in the conversation.

## How to Run
1. **Collect inputs.** Map the request onto the Inputs table. `path` is required, plus at least one of `compile_db` (C/C++) or `cargo_manifest` (Rust).
2. **Read the [orchestrator prompt](prompts/task.md)**, substituting the collected inputs for its `{{placeholder}}` values.
3. **Execute its phase loop.** Run Phases 0-7 sequentially. Before each phase, read that phase's workflow file from `{baseDir}/workflows/phase-{N}-{name}.md`.
4. **Return the report** (Phase 8, inline): read `{workdir}/report/final-report.md` and return its contents as the skill output.

To resume an interrupted run: if a `workdir` is known from prior context, read `{workdir}/orchestrator-state.json` and continue from its `current_phase` instead of starting at Phase 0.