security: workflow token scope + immutable action pins, with a gate (S2)

[CueCrux-Myles]

Slice S2 of the red-steel remediation replay (#630). Closes the CI half of that work — but not the way the original branch proposed, and the reason is a measurement rather than a preference.

What changed about the premise

f5ccc46e on #630 moves every CI job, including test and coverage, to ubuntu-latest, on the grounds that untrusted PR code runs on the privileged self-hosted pool. That justification no longer holds as stated. Against the live repository settings:

• approval_policy: all_external_contributors — every fork PR needs a maintainer to approve before any workflow runs
• forkCount: 0

The exposure is latent, gated behind a human click, with nobody positioned to attempt it. That does not warrant reversing #631's pool split and the shared CARGO_HOME design. f5ccc46e is dropped; the gate is documented and enforced instead (see the third commit).

What the same check did turn up were two un-gated problems that had nothing to do with runners, and had been stuck behind that decision:

	Found	Fixed by
default_workflow_permissions	write, repo-wide	commit 1
sha_pinning_required	false, with 95 mutable action refs	commit 2

The three commits

1 — least-privilege tokens. Sixteen of twenty-one workflows already declared contents: read. The other five — ci, ci-fallback, buf, private-paths, semver — declared nothing and inherited the repo default of write. None needs it. This is 8df28581 re-derived, not ported: that commit predates most of these workflows.

2 — immutable pins. 98 refs across 18 workflows, tag preserved as a trailing comment. Two cases are not mechanical:

• dtolnay/rust-toolchain reads its channel from the ref it was invoked by, so pinning the ref alone silently changes which Rust the job installs. All 18 call sites gain an explicit toolchain: input naming what the ref used to say — the pattern fuzz.yml already used for nightly.
• The SLSA generator stays on @v2.1.0. It is a reusable workflow, which GitHub's SHA-pinning policy exempts, and the generator rejects SHA refs.

Not a port of affd78ac either: those SHAs were captured 2026-07-30, so applying them verbatim would pin actions backwards. Same mechanism, re-resolved.

3 — the gate. scripts/check_workflow_policy.py + runner-policy.yml, so the first two commits stay true. Five rules: explicit top-level permissions:, no write-all, SHA-pinned actions, explicit toolchain: on pinned rust-toolchain, and no pull_request_target / workflow_run job on the self-hosted pool. That last rule is the runner decision made executable: pull_request on self-hosted stays allowed because approval gates it; pull_request_target does not and never should be.

Verification

• Checker run against the pre-M1 tree, not just the fixed one: 95 unpinned actions, 5 missing permission blocks, 21 stripped toolchain channels. Clean on this branch (22 workflows).
• 15 unit tests, covering every rule and both exemptions — including the PyYAML quirk that resolves the bare key on to boolean True, which would make a naive checker pass everything.
• check-licence-headers.sh, typos — clean locally.

Follow-up, after this merges

Two repository settings become safe to flip only once this is in — in this order, or CI breaks:

1. default_workflow_permissions → read
2. sha_pinning_required → true

Both are then belt-and-braces over what the files already say.

Not in this PR

bd440c26 (C2PA trust paths) still needs author sign-off — both sides took documented, opposite positions on an unvalidatable certificate chain. It is tracked in S6, not here.

Plan and decision log: PlanCrux/.agent/execplans/redsteel-remediation-replay-2026-08-07.md.

🤖 Generated with Claude Code