Follow-up from review of #501. Deferred there deliberately: this is security guidance, and it should not change as a side effect of a prose-compression PR.
Problem
CI-001 mandates pinning GitHub Actions by commit SHA. Review flagged that the guidance does not account for annotated tags.
GET /repos/{owner}/{repo}/git/ref/tags/{tag} returns the SHA of the tag object when the tag is annotated, not the commit it points at. Pinning that SHA pins the tag object. Many major actions publish annotated release tags, so following the ADR literally can produce a pin that is not the commit SHA the ADR intends — and the resulting value may not be what actions/checkout and friends resolve.
Dereferencing requires a second step: resolve the tag object to its target via GET /repos/{owner}/{repo}/git/tags/{tag_sha} and read .object.sha, or use a resolver that handles the peeled ref (^{}) form.
Why it matters here
The CI-001/no-unpinned-actions rule verifies that a SHA is present. It does not verify that the SHA is a commit. So a tag-object pin passes the automated check while not delivering the immutability guarantee the ADR is written to provide.
Suggested approach
- Confirm the behavior against a real annotated-tag action rather than from the API docs alone.
- Add the dereferencing step to CI-001's Do's (or its Implementation Pattern) with the concrete commands.
- Audit the existing pins in
.github/workflows/** for any that resolve to tag objects rather than commits.
- Consider whether the companion rule can assert commit-ness; if not, note the limitation explicitly the way ARCH-012 documents its synchronous-prelude gap.
The existing SLSA carve-out and its refs/tags/vX.Y.Z requirement must survive whatever wording changes here.
Review thread
#501 (comment)
Pre-existing guidance; #501 compressed the surrounding Context and Decision without touching the pinning mechanism.
Follow-up from review of #501. Deferred there deliberately: this is security guidance, and it should not change as a side effect of a prose-compression PR.
Problem
CI-001 mandates pinning GitHub Actions by commit SHA. Review flagged that the guidance does not account for annotated tags.
GET /repos/{owner}/{repo}/git/ref/tags/{tag}returns the SHA of the tag object when the tag is annotated, not the commit it points at. Pinning that SHA pins the tag object. Many major actions publish annotated release tags, so following the ADR literally can produce a pin that is not the commit SHA the ADR intends — and the resulting value may not be whatactions/checkoutand friends resolve.Dereferencing requires a second step: resolve the tag object to its target via
GET /repos/{owner}/{repo}/git/tags/{tag_sha}and read.object.sha, or use a resolver that handles the peeled ref (^{}) form.Why it matters here
The
CI-001/no-unpinned-actionsrule verifies that a SHA is present. It does not verify that the SHA is a commit. So a tag-object pin passes the automated check while not delivering the immutability guarantee the ADR is written to provide.Suggested approach
.github/workflows/**for any that resolve to tag objects rather than commits.The existing SLSA carve-out and its
refs/tags/vX.Y.Zrequirement must survive whatever wording changes here.Review thread
#501 (comment)
Pre-existing guidance; #501 compressed the surrounding Context and Decision without touching the pinning mechanism.