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.)
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.
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.
Don't forget to pin your GitHub Actions to SHAs instead of tags, that may or may not be immutable!
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.)
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.
Are the spam comments all from compromised accounts, presumably compromised due to this hack?
I only clicked on a handful of accounts but several of them have plausibly real looking profiles.
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:
https://github.com/Hancie123/mero_hostel_backend/commit/4bcb...
what comments?
Ah, I think the HN post was merged. My original comment was in response to this related github discussion: https://github.com/aquasecurity/trivy/discussions/10420
There are hundreds of automated spam comments there from presumably compromised accounts. The new OP is much more clear regarding what has happened.
Briefly?
"Trivy Supply Chain Attack Spreads, Triggers Self-Spreading CanisterWorm Across 47 npm Packages"
https://it.slashdot.org/story/26/03/22/0039257/trivy-supply-...
"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.
Seriously. All credentials compromised that it can see. It's active in CI/CD pipelines and follow on attacks are happening.
Pretty ironic that the security tool is insecure
You must be new to this. The median line of code in a security tool is materially less secure than the median line of code overall in the industry.