The Comforting Lie Of SHA Pinning

Summary

In March 2026, Trivy became the latest reminder that software supply chains are, at best, loosely held together with convention and trust.A typosquatting attack slipped malicious code into what looked like a legitimate dependency path. The post-mortems are worth reading, and they all converge on a single recommendation: pin your dependencies. In the GitHub Actions world, that usually translates to use commit SHAs, not tags.There’s a widely held belief that pinning a GitHub Action to a commit SHA gives you immutability, its what Microsoft/GitHub are recommending, and its what Aqua are recommending. After all, a SHA is content-addressed. It cannot be moved. It cannot be re-tagged. It is, in theory, the most stable reference you can use. The problem with that line of thinking is that the resolution of that SHA is not scoped the way most people assume. Specifically, GitHub Actions does not meaningfully validate that the commit SHA you reference belongs to the repository you think it does.Wait, what? No, thats not right&mldr;I set up a deliberately small example to test this behaviour.A “legitimate” action: avaines/blog_gh_sha_pinning_actionA consuming application: avaines/blog_gh_sha_pinning_appThe application references the action in the usual way:uses: avaines/blog_gh_sha_pinning_action@<some-sha> Working GitHub Action showing ‘Hello World’So far, so normal.Now introduce an attacker:Fork the action repository to aidenvaines-cgi/blog_gh_sha_pinning_actionAdd a malicious step (in my case, just printing output, but in reality this is where you exfiltrate all the fun stuff like secrets and personal data)Attacker changes to the GitHub Action in their fork adding malicious contentNext, create a pull request to the consuming application that appears to simply bump the pinned SHA:Attacker raises a PRThe SHA used in the PR comes from the attacker-controlled fork of the action, despite it still being referenced as avaines/blog_gh_sha_pinning_actionYou might reasonably assume on...