[woodruffw]

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.)

[AdrienPoupa]

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.

[cpuguy83]

This attack was not mitigated by hash pinning. The setup-trivy action installs the latest version of trivy unless you specify a version.

[AdrienPoupa]

Oh, I was referring to `aquasecurity/trivy-action` that was changed with a malicious entrypoint for affected tags. Pinned commits were not affected.

[NewJazz]

I'm pretty sure the trivy action does not do that.

[woodruffw]

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.

[NewJazz]

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.