CI security: hash-pin all action references?

[woodruffw]

Problem:

I'm opening this up pro forma, since the PR template expects an issue. It doesn't quite fit into the existing issue templates, so apologies 🙂

(I'm opening a PR to accompany this issue shortly after.)

Relevant details

aws-lc-rc's GitHub Actions workflows currently make extensive use of third-party actions via mutable pointers, i.e. tags and branches. This represents a supply chain risk, as a compromise of any of these third-party actions (via their repo) can allow an attacker to update these pointers to malicious contents.

The solution is to hash-pin all action references. This in effect replaces a mutable reference (a symbolic Git ref) with an immutable one (a sha ref). GitHub's own tooling (Dependabot, etc.) can maintain these hash-references and keep them updated, along with their sidecar comments.

For more information/context:

• The recent Trivy hack
• zizmor's unpinned-uses audit

Separately, the "why" behind this issue is that I'm an employee of Astral, and I'm looking to eliminate risks (even very minor) ones in our downstream dependencies for tools like uv. aws-lc-rs is one such dependency 🙂

[justsmth]

Thanks for the PR and for thinking about supply chain security for aws-lc-rs!

One concern we have is the operational burden of maintaining the precise hash for every CI actions -- we have a dozen workflows and about 100 jobs, with collectively 100's of steps. However, the supply chain concern is valid, especially for our workflows that produce artifacts we use. For our test and analysis workflows, a compromised action could produce a false pass or false failure in CI, but there's no clear mechanism for that to affect what we ship.

We've opened #1091, as an alternative to #1090, which takes a more targeted approach:

• Hash-pins all action references in our sys-bindings-generator and fips-bindings-generator workflows.
• Configures Dependabot for the github-actions ecosystem to keep the pins current.
• Updates actions/checkout from v3 to v4 across all workflows.
• Replaces the archived actions-rs/cargo action with direct cargo commands.
• Bumps seanmiddleditch/gha-setup-ninja (was a mix of v4 and v5) to v6.
• Bumps actions/dependency-review-action from v3 to v4.

Thanks again for drawing our attention to this. Feel free to let us know your thoughts.

[woodruffw]

Thank you for your response!

I think your concern is a real and serious one -- moving from symbolic references to hashes makes performing action updates much more complicated. Tools like Dependabot and Renovate can mediate some of that complexity by managing the hashes automatically, but at the end of the day they're still fundamentally opaque identifiers compared to tags or branch names.

For our test and analysis workflows, a compromised action could produce a false pass or false failure in CI, but there's no clear mechanism for that to affect what we ship.

Unfortunately, this isn't guaranteed to be true in terms of GitHub's own security model: a compromised action that runs on a trusted reference (such as main or another first-party branch) has the ability to manipulate GitHub's cache entries, which release and other sensitive workflows may rely on (intentionally or unintentionally). Attackers have successfully used this to pivot into release compromises even when all workflows have minimal permissions, since the cache tokens aren't controlled/restricted by the permissions block.

With that said, FWICT you all don't do any releases via CI, so this might be a non-issue for you 🙂 -- it's worth keeping in mind for any future decisions to move releases into GitHub Actions, however.

Either way, I really appreciate you opening #1091 for this! I'll close #1090.