[HN Gopher] Trivy ecosystem supply chain briefly compromised
___________________________________________________________________
Trivy ecosystem supply chain briefly compromised
Author : batch12
Score : 81 points
Date : 2026-03-20 03:30 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| snailmailman wrote:
| 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.
| bakugo wrote:
| 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...
| wswin wrote:
| what comments?
| snailmailman wrote:
| 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.
| MilnerRoute wrote:
| 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-...
| zach_vantio wrote:
| "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.
| brightball wrote:
| Seriously. All credentials compromised that it can see. It's
| active in CI/CD pipelines and follow on attacks are happening.
| RS-232 wrote:
| Pretty ironic that the security tool is insecure
| tptacek wrote:
| 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.
| CoderLuii wrote:
| 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.
| regularfry wrote:
| Similarly one of our biggest causes of power outages when I
| worked with a DC was the UPSes. And the biggest causes of
| data loss were the hardware RAID controllers. Feels like
| there's a fundamental law lurking under this stuff.
| snackbroken wrote:
| As the complexity of a system increases, the number of
| single points of failure also tends to increase. Sometimes
| you can make sure that several subsystems need to fail
| before the whole system fails. Often, the best you can do
| is swap one SPoF (e.g. unreliable power grid) for another,
| more robust SPoF (unreliable UPS).
| Shank wrote:
| 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.
| NewJazz wrote:
| They did a lot of what you describe, although perhaps not well
| enough.
| AdrienPoupa wrote:
| Don't forget to pin your GitHub Actions to SHAs instead of tags,
| that may or may not be immutable!
| woodruffw wrote:
| 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.)
| NewJazz wrote:
| I'm pretty sure the trivy action does not do that.
| woodruffw wrote:
| 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 wrote:
| 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.
| AdrienPoupa wrote:
| 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 wrote:
| This attack was _not_ mitigated by hash pinning. The setup-
| trivy action installs the latest version of trivy unless
| you specify a version.
| AdrienPoupa wrote:
| Oh, I was referring to `aquasecurity/trivy-action` that
| was changed with a malicious entrypoint for affected
| tags. Pinned commits were not affected.
| woodruffw wrote:
| 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.
| swq115 wrote:
| The irony of your vulnerability scanner being the vulnerability.
| real_joschi wrote:
| Ever heard of IBM QRadar SIEM?
| NewJazz wrote:
| Yes... Any more context? Were they leaking data?
| jl6 wrote:
| 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.
| 4riel wrote:
| yeah, we keep learning the same lesson: the tool that audits your
| supply chain is the single best target for compromising it
| duckmysick wrote:
| > credential rotation was performed but was not atomic (not all
| credentials were revoked simultaneously).
|
| How do you simultaneously revoke all credentials of all your
| accounts spanning multiple services/machines/users?
| feross wrote:
| Lots more technical research about the actual attack and how it
| worked here: https://socket.dev/blog/trivy-under-attack-again-
| github-acti...
|
| Disclosure: I'm the founder of Socket.
___________________________________________________________________
(page generated 2026-03-22 23:01 UTC)