Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trivy ecosystem supply chain temporarily compromised

github.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Trivy ecosystem supply chain temporarily compromised

#21

Post by NewJazz »

woodruffw wrote: post #20
NewJazz wrote: post #16

Earlier quoted context omitted.

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

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.

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.

Re: Trivy ecosystem supply chain temporarily compromised

#23

Post by regularfry »

tptacek wrote: post #11
RS-232 wrote: post #6

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.

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.

Re: Trivy ecosystem supply chain temporarily compromised

#24

Post by jl6 »

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.

Re: Trivy ecosystem supply chain temporarily compromised

#28

Post by snackbroken »

regularfry wrote: post #23
tptacek wrote: post #11

Earlier quoted context omitted.

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.

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.

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).

Re: Trivy ecosystem supply chain temporarily compromised

#29

Post by cpuguy83 »

AdrienPoupa wrote: post #19
woodruffw wrote: post #15

Earlier quoted context omitted.

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.

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

Re: Trivy ecosystem supply chain temporarily compromised

#30

Post by AdrienPoupa »

cpuguy83 wrote: post #29
AdrienPoupa wrote: post #19

Earlier quoted context omitted.

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.

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

Oh, I was referring to `aquasecurity/trivy-action` that was changed with a malicious entrypoint for affected tags. Pinned commits were not affected.
Post reply on HN