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 11 hours ago | parent | next [-]

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 3 hours ago | parent [-]

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

	▲	AdrienPoupa 2 hours ago \| parent [-]
		Oh, I was referring to `aquasecurity/trivy-action` that was changed with a malicious entrypoint for affected tags. Pinned commits were not affected.

▲

NewJazz 12 hours ago | parent | prev [-]

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

▲

woodruffw 11 hours ago | parent [-]

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 11 hours ago \| parent [-]
		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.