GitHub Actually Fixed SHA Pinning. I Wasn't Expecting That.

In March, writer Vaines published an article titled "The Comforting Lie of SHA Pinning" after investigating the supply-chain compromise of Trivy on GitHub Actions. They discovered that pinning a GitHub Action to a full commit SHA did not ensure that the executing code came from the intended repository. A malicious fork could be created, and GitHub would resolve and execute the malicious commit, even with organization allowlists and mandatory SHA pinning.

In October 2026, GitHub announced the general availability of workflow dependency lockfiles, which addressed Vaines' concern. The lockfile records the resolved commit alongside the repository identity, ensuring the code's provenance is validated. With this feature, GitHub can now check that a commit is reachable through the expected repository and reference, rather than merely accepting a Git object in its fork network.

GitHub's new .github/workflows/actions.lock file records the dependency alongside its repository identity. Workflows can reference the dependency using a readable format, while the lockfile records the actual dependency and its metadata, such as the repository ID and SHA. This prevents the execution of malicious code, even if an attacker replaces the legitimate reference with a malicious commit in a forked repository.

The new feature handles transitive Action dependencies, integrates with Dependabot, and supports policies requiring lockfiles. However, it does not make malicious dependencies trustworthy, and legitimate upstream releases can still be compromised. Additionally, external reusable workflows are not covered by the caller's lockfile.

Despite these limitations, the specific forked-commit substitution issue demonstrated in March is now prevented by workflow dependency locking. Vaines plans to discuss this improvement at Yorkshire DevOps on November 5th, emphasizing that the issue he has been raising has been addressed.