How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
To be clear, this is a supply chain attack on everyone that uses Trivy, not a supply chain attack on Trivy. It was a direct attack on Trivy, exploiting components that Aqua had full control and responsibility for. The term “supply chain attack” has a connotation of “it’s not really my fault, it was my dependencies that got compromised”.
Of course, every entity is ultimately accountable for its own security, including assigning a level of trust to any dependencies, so it’s ultimately no excuse, but getting hit by a supply chain attack does evoke a little more sympathy (“at least I did my bit right”), and I feel like the ambiguous wording of the title is trying to access some of that sympathy.
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.
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.
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.)
We ran into exactly this. The fix we landed on was vendoring the binary in the repo itself during CI setup, then using a SHA-verified copy. More annoying to update but at least it's deterministic.
The Go binary was also compromised, but there's almost no information what the compromised binary did. Did it drop a python script? Did it do direct scanning?
If trivy docker image was used, what's the scope (it does not include python).
The Go binary angle is concerning precisely because nobody seems to have diffed the compromised version against clean. Did it just exfiltrate scan results? That alone would be damaging for enterprise users scanning private registries.
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:
Yeah, the "plausibly real looking" part is the concerning bit. Account farming for supply chain attacks takes real investment — these aren't throwaway burners made yesterday.
We run Trivy in CI on every PR merge. The window between the two incidents is what gets me - whoever did this clearly had retained access and was just waiting.
Of course, every entity is ultimately accountable for its own security, including assigning a level of trust to any dependencies, so it’s ultimately no excuse, but getting hit by a supply chain attack does evoke a little more sympathy (“at least I did my bit right”), and I feel like the ambiguous wording of the title is trying to access some of that sympathy.