Pinning Github Actions Project Report

I woke up today to find that a particularly troublesome pull request was merged at last. My PR hardened build security by pinning Github Actions, using a hash to identify the version we intended to use rather than a tagged release.

The idea is that the maintainer of an action can easily inject malicious code into releases that have adoption already. It doesn't matter that the commit labeled v1.2.3 was originally benign if users of their Action are simply adopting any commit with that label. What users of the action must do instead is identify the version they want using the commit hash of the tagged release.

The need to pin actions is widely acknowledged in the security community. It is checked in OSSF Security Scorecards and documented in Github's own security suggestions.

A compromise of a single action within a workflow can be very significant, as that compromised action would have access to all secrets configured on your repository, and may be able to use the GITHUB_TOKEN to write to the repository. Consequently, there is significant risk in sourcing actions from third-party repositories on GitHub.

Despite the obvious need, I came to believe that it is more of a piety than a reality. There were obstacles for which there would be solutions if more people were doing it, and when I asked questions in social media I heard nothing but crickets. I even had to write documentation for Magma contributors.

There was a need for package management tools akin to Yarn, but targeted at Github Actions. I discovered only a single resource in the space, a CLI tool called pin-github-action. This is a modest project with 25 stars, one contributor, and 1090 lines of code, but it occupies a unique and valuable niche. Without it my own deliverable would have been even more work, so I stopped baking my own scripts and became a contributor. I have had 3 features merged and have 2 left to complete. In the long run this project needs a feature set comparable to lockfiles in NPM or the Golang package manager. In addition to new features for managing hashes, the hashes themselves shouldn't be exposed directly to developers. They should exist in a lockfile generated by tooling.

It was the need for tooling and documentation that made Action pinning in Magma so much work. It shouldn't be this way. In the future the open-source security community should converge to bring the infrastructure to maturity.