security: fix rust-secrets — 12.5% of Rust repos were never scanned

[hyperpolymath]

Found while verifying the 201-repo secret-scanner re-pin sweep. Two defects in rust-secrets.

1. Silent no-scan — the serious one

grep -rn --include="*.rs" -E "$pattern" src/     # <- root src/ only

A Cargo workspace keeps its code in crates/*/src, so src/ does not exist at the root. grep exits 2, the enclosing if reads that as no match, and the job passes.

Measured across the 64 Rust repos in the sweep: 8 (12.5%) have no root src/ and were never scanned at all.

Proven on a fixture — a planted secret in crates/core/src/lib.rs:

	old job	this PR
pub const SERVICE_TOKEN: &str = "…" in crates/core/src/lib.rs	exit 0 ✅ green	detected

Another gate that could not fail.

2. False positive on the correct pattern

let.*api_key.*=.*" matches any let api_key = line containing a quote — including:

let api_key = env::var("CLOUDGUARD_API_KEY").ok();

…which is precisely the practice this job exists to enforce. This was the only rust-secrets failure in the entire sweep (cloudguard-server src/main.rs:59). A gate whose sole route to green is to stop reading from the environment is inverted.

Exemptions

Mirror the four layers already documented on shell-secrets, and match on the value or an explicit pragma — never on a file path, because a path exemption blinds the job to a real secret in the same file (the failure mode .gitleaks.toml was rewritten to avoid in #512).

Layer	Rationale
env-lookup RHS	the correct pattern. Anchored to the assignment and stopped at ;, so a literal secret with an unrelated env::var mention later on the line still trips
URL values	an OAuth endpoint is public, not a credential (const MS_TOKEN_URL = "https://login.microsoftonline.com/…" tripped const.*TOKEN.*=.*" 4× in one repo)
comment lines	documentation of a pattern is not a live secret
// scanner-allow: rust-secrets	explicit, per-line, auditable

Warn-first on the widened scope

Hits outside ./src are newly visible, so they warn until 2026-08-21 — the same cutoff and idiom as check-package-policy.sh / check-docs-presence.sh — rather than reddening repos that were never actually being scanned. Hits inside ./src block exactly as before, so there is no regression.

The advisory branch prints the finding and says NOT YET ENFORCED; it never claims a pass. A malformed cutoff refuses to run rather than defaulting to warn forever.

Verified, not assumed

Canary suite run against the script extracted from this YAML (yaml.safe_load → execute), not a copy:

PASS  env::var + comment + pragma + OAuth URL -> ALLOWED
PASS  secret in ./src                        -> BLOCKS
PASS  secret in crates/                      -> ADVISORY today
PASS  secret in crates/                      -> BLOCKS after cutoff
PASS  literal + env mention after ;          -> BLOCKS  (exemption not over-broad)
PASS  malformed cutoff                       -> refuses to run
6 passed, 0 failed

Replayed over all 64 Rust repos in the sweep: 0 regressions today, 1 fixed (cloudguard-server).

Follow-up for repo owners (before 2026-08-21)

Three repos carry fixture-shaped hits outside ./src and need a one-line pragma; each is named in the run output today:

• echidnabot — fuzz/fuzz_targets/fuzz_hmac.rs:17 (fuzz corpus)
• filesoup — plugins/secret-scanner/src/lib.rs:159 (the plugin's own detection fixture)
• heterogenous-mobile-computing — examples/basic_usage.rs:61 (demo of a blocked query)

Pre-existing and unchanged by this PR: aerie and conative-gating fail under both old and new (request["api_key"] dynamic lookup; a scanner's own r#"…"# test fixtures).

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud