This attack seems predicated on a prior security incident (https://socket.dev/blog/unauthorized-ai-agent-execution-code...) at Trivy where they failed to successfully remediate and contain the damage. I think at this time, Trivy should’ve undertaken a full reassessment of risks and clearly isolated credentials and reduced risk systemically. This did not happen, and the second compromise occurred.
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.
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.
I don’t think “briefly compromised” is accurate. The short span between this and the previous compromise of trivy suggests that the attacker was able to persist between their two periods of activity.
Some of them were likely already compromised before these incidents, here's one of the accounts near the top making malicious commits to its own repository before the first hack:
"Briefly" is doing a lot of work there. Pre-deploy scans are useless once a bad mutation is actually live. If you don't have a way to auto-revert the infrastructure state instantly, you're just watching the fire spread.
this is painfully accurate. ive worked in security for years and the tools we trust the most get the least scrutiny because everyone assumes "well its a security tool, it must be secure." the irony is these tools usually run with the highest privileges in the pipeline. trivy sits in CI with access to every secret in your environment and nobody questions it because its supposed to be the thing protecting you.
(IOW You definitely should still hash-pin actions, but doing so isn’t sufficient in all circumstances.)
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.
I only clicked on a handful of accounts but several of them have plausibly real looking profiles.
https://github.com/Hancie123/mero_hostel_backend/commit/4bcb...
There are hundreds of automated spam comments there from presumably compromised accounts. The new OP is much more clear regarding what has happened.
"Trivy Supply Chain Attack Spreads, Triggers Self-Spreading CanisterWorm Across 47 npm Packages"
https://it.slashdot.org/story/26/03/22/0039257/trivy-supply-...