A SHA-pinned action that pulls unpinned actions isn't pinned

## Spark

Digest, week of 2026-08-08: `pre-commit/action` was found pulling an *unpinned*
`actions/cache`, breaking the blog's pre-commit workflow (#484). The fix didn't
stop at the blog — within days six repos swapped to
`tox-dev/action-pre-commit-uv`, and the principle was promoted upward into
chezmoi's CLAUDE.md and into the Terraform module that governs every managed
repository.

## Why it could be interesting

The activity is "I swapped a GitHub Action." The claim is that SHA-pinning is
conventionally applied only one level deep, and a composite action is a
*dependency tree*, not a leaf. You pin the action you call; the action calls
whatever it likes. Every pinning policy, every audit checklist, and every "we
pin our actions" security claim stops at the front door — so the guarantee is
weaker than it reads, and nothing reports the gap until a transitive dependency
moves under you.

The second half is the remedy's shape: verifying transitivity by hand doesn't
scale past a couple of repos, so the answer was to make "verified pinned all the
way down" a property the fleet's Terraform module asserts, rather than a habit
each repo maintains. That's the same move as #457 (put the constraint where the
tool can see it) applied one layer out.

## Open questions

- [ ] Is this genuinely distinct from #457, or the same claim about a different
opacity? #457 is "the updater can't parse the pin"; this is "the pin
doesn't cover what it transitively runs". Settle whether that's one post
or two before drafting.
- [ ] How do you *verify* transitive pinning mechanically? Is there tooling, or
was every check here manual? The post is much weaker if the answer is
"read the action's source each time".
- [ ] Which of the six swaps were genuinely forced versus opportunistic
consistency? The narrative needs the blast radius to be real.
- [ ] Does the allow-list approach (#376) subsume the pinning question — if only
vetted actions can run, does transitive pinning still matter?
- [ ] Relationship to #190, which covers fleet supply-chain posture generally.
Is this a section of that post or its own thing?

## Source material

- alunduil/blog.alunduil.com#484 — pre-commit workflow fails: pre-commit/action pulls an unpinned actions/cache (the trigger)
- The fleet-wide swap to `tox-dev/action-pre-commit-uv`: blog#485, alunduil-chezmoi#576, collection-json.hs#263, zfs-replicate#615, alunduil-infrastructure#378, woodland-generators#481
- alunduil/woodland-generators#482 — third-party composite actions are verified SHA-pinned all the way down
- alunduil/woodland-generators#473, #474 — actions verified SHA-pinned at commit time
- alunduil/alunduil-chezmoi#577 — CLAUDE.md records that third-party actions must pin their own inner steps
- alunduil/alunduil-infrastructure#372, #376, #377 — Actions baseline in the repository module; allow-listed actions; pinning disableable through the module
- alunduil/alunduil-infrastructure#165 (closed) — read-only workflow token and SHA-pinned actions
- alunduil/network-arbitrary#131 — every workflow declares its own permissions block
- dungeon-studio/genshin.dungeon.studio#1291 — devcontainer installs act from a pinned, retrying script instead of the act feature
- Adjacent existing ideas: #457, #190, #128