Third party actions are pinned inconsistently across the fleet. Some repositories reference every action by commit hash, others reference mutable tags, and most sit somewhere in between. A tag is a mutable pointer: whoever controls the action repository can move v7 to a different commit at any time, and every workflow referencing that tag executes the new code on the next run, with whatever permissions the job holds. Pinning by commit hash removes that possibility.
Measured on 2026-08-07:
| Repository |
Pinned by commit hash |
On a mutable tag |
| flaps |
48 |
0 |
| lightshuttle |
21 |
17 |
| isochron |
7 |
8 |
| egide |
3 |
16 |
| eidosdb |
1 |
15 |
| nubster-cli |
1 |
21 |
| aerogram |
1 |
24 |
flaps already applies the target state and can serve as the reference: every reference is a full commit hash followed by a # vX.Y.Z comment, so the human readable version stays visible and automated upgrade proposals keep working, since they update both the hash and the comment.
Two practical notes for whoever picks this up. First, a repository wide policy is only enforceable if a job checks it, otherwise it decays silently with each new workflow. Second, the check must tolerate reusable workflow references and local ./.github/actions/... paths, which cannot be pinned the same way.
Scope
- State the policy: every third party action reference is a full commit hash followed by a version comment.
- Convert the remaining mutable tag references, starting with
aerogram, nubster-cli and eidosdb, which carry the largest gap.
- Add a job that fails when a workflow references an action by tag, and place it in the shared workflow template.
- Confirm that automated dependency proposals still upgrade hash pinned references correctly, comment included.
Acceptance criteria
Third party actions are pinned inconsistently across the fleet. Some repositories reference every action by commit hash, others reference mutable tags, and most sit somewhere in between. A tag is a mutable pointer: whoever controls the action repository can move
v7to a different commit at any time, and every workflow referencing that tag executes the new code on the next run, with whatever permissions the job holds. Pinning by commit hash removes that possibility.Measured on 2026-08-07:
flapsalready applies the target state and can serve as the reference: every reference is a full commit hash followed by a# vX.Y.Zcomment, so the human readable version stays visible and automated upgrade proposals keep working, since they update both the hash and the comment.Two practical notes for whoever picks this up. First, a repository wide policy is only enforceable if a job checks it, otherwise it decays silently with each new workflow. Second, the check must tolerate reusable workflow references and local
./.github/actions/...paths, which cannot be pinned the same way.Scope
aerogram,nubster-cliandeidosdb, which carry the largest gap.Acceptance criteria