Comment by woodruffw
5 days ago
Frustratingly, hash pinning isn’t good enough here: that makes the action immutable, but the action itself can still make mutable decisions (like pulling the “latest” version of a binary from somewhere on the internet). That’s what trivy’s official action appears to do.
(IOW You definitely should still hash-pin actions, but doing so isn’t sufficient in all circumstances.)
That's true. This specific attack was mitigated by hash pinning, but some actions like https://github.com/1Password/load-secrets-action default to using the latest version of an underlying dependency.
This attack was not mitigated by hash pinning. The setup-trivy action installs the latest version of trivy unless you specify a version.
Oh, I was referring to `aquasecurity/trivy-action` that was changed with a malicious entrypoint for affected tags. Pinned commits were not affected.
I'm pretty sure the trivy action does not do that.
FWICT, it pulls the latest version of trivy by default. If that latest tag is a mutable pointer (and it typically is), then it exhibits the problem.
Then why do they hard code the trivy version and create PRs to bump it?
https://github.com/aquasecurity/trivy-action/blob/57a97c7e78...
https://github.com/aquasecurity/trivy-action/pull/519
Edit: ah, I see you are referring to the setup-trivy action rather than the trivy-action. Yeah, that looks like a bad default, although to be fair it is a setting that they document quite prominently, and direct usage of the setup-trivy action is a bit atypical as-is.