fix(security): restore secret scanning — drop unused actions: read from reusable

[hyperpolymath]

Restores standards own secret scanning, which has not executed since 2026-07-26.

The outage

Every recent Secret Scanner run on main is startup_failure — zero steps, no log, no check run at all. The repo secret scanning was silently dead, while a live write-scoped credential sits in the tree.

Root cause

0ced540 ("chore: estate-wide security compliance", 2026-07-26) added actions: read to the workflow-levelpermissions: block of secret-scanner-reusable.yml.

No job needs it — the only action used is actions/checkout (×3); there are no artifacts, no cache, no gh api calls, no workflow-run queries. Since #500 replaced gitleaks-action with a pinned checksum-verified binary, pull-requests: write is unnecessary too.

rust-secrets and shell-secrets had no job-level block, so they inherited that unused grant. A called workflow cannot exceed its caller job-level grant, so the correctly least-privileged caller — granting contents: read alone — was rejected at startup.

A sweep named "security compliance" disabled the security scanner.

Fix — all three layers

1. Workflow-level block reduced to contents: read, restoring parity with the known-good pinned versions (c65436ee, d135b05).
2. All three jobs declare permissions: contents: read explicitly instead of inheriting. Inheritance is what let an unused grant leak into two jobs unnoticed; explicit blocks mean a future widening cannot silently re-break callers.
3. The caller-example comment block is corrected. It still instructed wrappers to grant pull-requests: write + actions: read — guidance that was correct only before ci(secret-scanner): make gitleaks gate for real, not continue-on-error #500, and which propagates to every wrapper minted from it. It now documents the minimal correct shape plus the two rules that make this failure mode invisible.

Also removes the caller own unused actions: read, and the incorrect claim that moving to a local path meant "this class of breakage cannot recur" — it recurred by a different route.

Prevents a latent mass outage

326 estate wrappers call this reusable; 156 grant contents: read only. They are green today solely because they pin older, clean SHAs (181 on c65436ee, 83 on d135b05).

Re-pinning them to current main — as the planned pin-refresh sweep would do — would have broken all 156 at once. This must land before any such sweep.

Verification

• yq parse OK; effective grants confirmed contents: read at workflow level and on each of the three jobs.
• actionlint clean on the caller. On the reusable the only finding is a pre-existing, intentional SC2053 (glob matching for .shell-secrets-ignore) — count identical before and after (1 → 1).
• Sampled five contents-only estate callers on their current pins (anamnesis, boj-server, echidnabot, conflow, …): all green, confirming they are insulated rather than already broken.

⚠ Draft pending the real proof: the check that matters is this PR own Secret Scanner run going green. A rejected run produces no check run, so absence of red is not evidence — verify with gh run list --json conclusion. This exact failure mode has already survived one "fix".

Refs #500. Fixes the startup_failure introduced by 0ced540.

🤖 Generated with Claude Code

[hyperpolymath]

Second, deeper fault found — and fixed in 49877ee

The permissions fix (e3f982d) worked: the scanner ran green, all three jobs, real steps. It then reported no leaks found on a repo containing a live write-scoped GitLab PAT. So I kept going.

gitleaks cannot see any .adoc file

gitleaks default global allowlist excludes paths matching (jpg|gif|doc|docx|zip|xls|pdf|bin|svg|socket)$. That doc alternative is an unanchored substring match on the filename, so it swallows .adoc and .asciidoc as collateral. AsciiDoc is plain text and was never the intended target of a binary-file exclusion.

Proven with identical content across four extensions:

extension	result
.txt	DETECTED
.md	DETECTED
.adoc	MISSED
.asciidoc	MISSED

This estate writes docs in AsciiDoc by default — ~40,000 files estate-wide, 1,620 in standards alone, none of which has ever been secret-scanned. That is precisely why 40 occurrences of a live glpat- token in rhodium-pipeline/docs/QUICKSTART.adoc were never flagged.

Why the config cannot fix it

The exclusion cannot be switched off while [extend] useDefault = true. Verified: neither [allowlist] paths = [] nor an explicit custom rule re-enables scanning — the file is dropped at path level, before any rule runs. Setting useDefault = false would forfeit all ~150 default rules.

So the new step scans a throwaway mirror in which each AsciiDoc file is copied under a .txt suffix: same binary, same rules, same repo config — only the filename differs, which is the sole thing the allowlist keys on. Findings are mapped back to real paths before reporting.

Warn-first, same cutoff as #513

This makes ~40,000 previously unscanned files visible at once, and every hit is pre-existing debt, not a regression from the PR in front of it. So it uses the established 2026-08-21 cutoff. It never prints a pass while findings exist, always lists them, and the date flips itself.

Red-teamed both directions

case	result
leak in .adoc, pre-cutoff	exit 0 + NOT YET ENFORCED + findings listed
leak in .adoc, post-cutoff	exit 1
clean .adoc, post-cutoff	exit 0 — no false positive
no .adoc present	exit 0
path containing spaces	exit 1, correct real path
malformed date	exit 1, refuses to run

⚠ The clean-docs case initially FAILED (exit 1).grep exits 1 on no match, which under set -e + pipefail aborted the step — so every repo with clean AsciiDoc would have been failed by this gate. Caught only because I red-teamed the passing case, not just the failing one. Fixed, with the reason recorded in-line.

actionlint: no new findings (1 pre-existing SC2053 before and after).

---

⚠ This does not un-leak the token. The credential in QUICKSTART.adoc is still live and still public — it must be revoked at gitlab.com, then purged from history. This PR only ensures the next one gets caught.

[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