2b Rust Source Analyzer

Identify sensitive Rust types and detect missing or incorrect zeroization at the source level. Uses rustdoc JSON for trait-aware analysis (resolves generics, blanket impls, type aliases) and a token-based scanner for dangerous API patterns. Produces source findings that drive crate-level compiler analysis.

Input

You receive these values from the orchestrator:

Process

Step 1 — Generate Rustdoc JSON

Generate the rustdoc JSON file for the crate. This provides trait implementation data, derive macros, and type information needed for semantic analysis.

cargo +nightly rustdoc \
  --manifest-path <cargo_manifest> \
  --document-private-items -- \
  -Z unstable-options --output-format json

The output is written to /target/doc/ .json. Find it with:

find <rust_crate_root>/target/doc -name "*.json" -not -name "search-index*.json" | head -1

If cargo +nightly rustdoc fails: write an error note and skip to Step 3 (dangerous API scan can still run without rustdoc JSON).

Step 2 — Semantic Audit (Rustdoc JSON)

Run the trait-aware semantic auditor:

uv run {baseDir}/tools/scripts/semantic_audit.py \
  --rustdoc <rustdoc_json_path> \
  --cargo-toml <cargo_manifest> \
  --out {workdir}/source-analysis/rust-semantic-findings.json

This detects:

• #[derive(Copy)] on sensitive types → SECRET_COPY (critical)
• No Zeroize/ZeroizeOnDrop/Drop → MISSING_SOURCE_ZEROIZE (high)
• Zeroize without auto-trigger → MISSING_SOURCE_ZEROIZE (high)
• Partial Drop impl → PARTIAL_WIPE (high)
• ZeroizeOnDrop with heap fields → PARTIAL_WIPE (medium)
• Clone on zeroizing type → SECRET_COPY (medium)
• From/Into returning non-zeroizing type → SECRET_COPY (medium)
• Source file containing ptr::write_bytes and no compiler_fence(...) call → OPTIMIZED_AWAY_ZEROIZE (medium, needs_review)
• #[cfg(feature=...)] wrapping cleanup → NOT_ON_ALL_PATHS (medium)
• #[derive(Debug)] on sensitive type → SECRET_COPY (low)
• #[derive(Serialize)] on sensitive type → SECRET_COPY (low)
• No zeroize crate in Cargo.toml → MISSING_SOURCE_ZEROIZE (low)

Section A of {baseDir}/references/rust-zeroization-patterns.md documents most of these as A1–A12, each with a minimal reproducing snippet and the recommended fix. Read the entry for a pattern before writing its finding detail, and use its snippet to judge how closely the flagged type matches.

Never drop or downgrade a finding because it reads as a poor match for the entry. A weak match is a needs_review finding whose evidence says how the code differs from the entry, not an omission: Step 5 combines both arrays in full, and a finding left out here is unrecoverable from any artifact the run produces.

The mapping is not one-to-one. The missing-zeroize-dependency check has no Section A entry, and A6 (a ManuallyDrop struct field) covers a pattern the list above does not name. Where a check has no entry, write the detail and the fix from that check's own output — borrowing a neighbouring entry's snippet produces a finding that describes the wrong flaw.

If the script is missing or fails: write a status-bearing error object to the output file and continue:

{
  "status": "error",
  "error_type": "script_failed",
  "step": "semantic_audit",
  "message": "<stderr or missing-script reason>",
  "findings": []
}

Step 3 — Dangerous API Scan

Run the token/grep-based scanner across all .rs source files:

uv run {baseDir}/tools/scripts/find_dangerous_apis.py \
  --src <rust_crate_root>/src \
  --out {workdir}/source-analysis/rust-dangerous-api-findings.json

This detects:

• mem::forget → MISSING_SOURCE_ZEROIZE (critical)
• ManuallyDrop::new → MISSING_SOURCE_ZEROIZE (critical)
• Box::leak → MISSING_SOURCE_ZEROIZE (critical)
• mem::uninitialized → MISSING_SOURCE_ZEROIZE (critical)
• Box::into_raw → MISSING_SOURCE_ZEROIZE (high)
• ptr::write_bytes → OPTIMIZED_AWAY_ZEROIZE (high)
• mem::transmute → SECRET_COPY (high)
• slice::from_raw_parts → SECRET_COPY (medium)
• mem::take → MISSING_SOURCE_ZEROIZE (medium)
• async fn with secret-named local + .await → NOT_ON_ALL_PATHS (high)

Section B of {baseDir}/references/rust-zeroization-patterns.md covers these as B1–B10. Each entry explains why the API defeats zeroization, which matters here because this scanner is token-based: it cannot tell mem::take used to steal a secret from mem::take used on an unrelated buffer.