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

Trivy under attack again: Widespread GitHub Actions tag compromise secrets

socket.dev

Post reply on HN
Print view View original

51–60 of 97 posts

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#51

Post by mburns »

staticassertion wrote: post #46
tkzed49 wrote: post #38

"GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action" Why doesn't GitHub just enforce immutable versioning for actions? If you don't want immutable releases, you don't get to publish an Action. They could decide to enforce this and mitigate this class of issue.

I assume this is because it is modeled after git tags, and at this point it would be a major change to move away from this. But it should probably get started at some point.

GitHub has an opt-in option to enforce immutable tags as part of immutable releases.

https://docs.github.com/en/code-security/concepts/supply-cha...

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#52

Post by woodruffw »

deathanatos wrote: post #44
tkzed49 wrote: post #38

"GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action" Why doesn't GitHub just enforce immutable versioning for actions? If you don't want immutable releases, you don't get to publish an Action. They could decide to enforce this and mitigate this class of issue.

> Why doesn't GitHub just enforce immutable versioning for actions? I always wish these arguments came with a requirement to include a response to "well, what about the other side of the coin?", otherwise, you've now forced me to ask: well? The two sides of the coin: Security wants pinned versions, like you have, so that compromises aren't pulled in. Security does not want¹ pinned versions, so that security updates a…

> it might not be so explicitly state, but a desire to have constant updated-ness w/ security patches amounts to an argument against pinning

When you want to update, you update the hashes too. This isn’t an issue in any other packaging ecosystem, where locking (including hashing) is a baseline expectation. The main issue is developer ergonomics, which comes back to GitHub Actions providing very poor package management primitives out of the box.

(This is the key distinction between updating and passively being updated because you have mutable pointers to package state. The latter gets confused for the former, but you almost always want the former.)

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#53

Post by staticassertion »

mburns wrote: post #51
staticassertion wrote: post #46

Earlier quoted context omitted.

I assume this is because it is modeled after git tags, and at this point it would be a major change to move away from this. But it should probably get started at some point.

GitHub has an opt-in option to enforce immutable tags as part of immutable releases. https://docs.github.com/en/code-security/concepts/supply-cha...

Nice, yeah I think they should start to migrate to that behavior by default.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#54

Post by tgrowazay »

dist-epoch wrote: post #28
deathanatos wrote: post #25

My initial thought is that if this isn't a new compromise, Trivy must not have rotated the old credentials. They claim, however, > We rotated secrets and tokens, but the process wasn't atomic and attackers may have been privy to refreshed tokens … does anyone know what exactly they're talking about, here? To my knowledge, GH does not divulge new tokens after they're issued, but it depends on the exact auth type we're…

OpenClaw creator made some related claims, that as soon as he created a GitHub organization with a new name, somehow it was stolen from him, and he had to ask Github people to do it for him atomically.

It is a bit different. What happened to openclaw:

He created a new org “openclaw” to reserve the name. Then he wanted to swap it with “moltbot” org.

So he opened two browser windows, one with “moltbot” repo settings another with “openclaw” repo settings.

Then he renamed “openclaw” to whatever, and quickly tried to rename “moltbot” to now available “openclaw”.

But in a second when “openclaw” was available, a bot snatched the repo.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#55

Post by 0xbadcafebee »

> This allowed the threat actor to perform authenticated operations, including force-updating tags

Hey look, infrastructure underpinning the security of thousands of products, being compromised in a way a simple setting could have prevented (Do not allow overriding tags is an old GH setting). Yet another reason we need a Software Building Code. I wonder how many more of these reasons we'll find in 2026.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#56

Post by 0xbadcafebee »

huslage wrote: post #20

How the heck are credential compromises still a thing with 2FA and refresh tokens???

Since there is no requirement for anyone to use them... people don't use them. If people aren't forced to do the right thing, they do the lazy thing.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#57

Post by patmorgan23 »

deathanatos wrote: post #44
tkzed49 wrote: post #38

"GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action" Why doesn't GitHub just enforce immutable versioning for actions? If you don't want immutable releases, you don't get to publish an Action. They could decide to enforce this and mitigate this class of issue.

> Why doesn't GitHub just enforce immutable versioning for actions? I always wish these arguments came with a requirement to include a response to "well, what about the other side of the coin?", otherwise, you've now forced me to ask: well? The two sides of the coin: Security wants pinned versions, like you have, so that compromises aren't pulled in. Security does not want¹ pinned versions, so that security updates a…

Version tags should obviously be immutable, and if you want to be automatically updated you can select 1.0.*, if you don't you just pick the version tag.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#58

Post by woodruffw »

This is a good wake-up call (or reminder) that many “supply chain security” products are no more secure or responsibly engineered than the stacks they’re intended to protect. This is a characteristic of security software in general, but the rise of these kinds of “run us everywhere” tools/products invite new and exciting ways for an attacker to compromise large numbers of users in a single campaign.

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#59

Post by NewJazz »

woodruffw wrote: post #52
deathanatos wrote: post #44

Earlier quoted context omitted.

> Why doesn't GitHub just enforce immutable versioning for actions? I always wish these arguments came with a requirement to include a response to "well, what about the other side of the coin?", otherwise, you've now forced me to ask: well? The two sides of the coin: Security wants pinned versions, like you have, so that compromises aren't pulled in. Security does not want¹ pinned versions, so that security updates a…

> it might not be so explicitly state, but a desire to have constant updated-ness w/ security patches amounts to an argument against pinning When you want to update, you update the hashes too. This isn’t an issue in any other packaging ecosystem, where locking (including hashing) is a baseline expectation. The main issue is developer ergonomics, which comes back to GitHub Actions providing very poor package managemen…

Honestly what I really want is the latter (mutable references), but pointing to aliases that I own and update manually (the former).

Re: Trivy under attack again: Widespread GitHub Actions tag compromise secrets

#60

Post by nulltrace »

cedws wrote: post #15
progbits wrote: post #4

Friendly reminder that just because someone is building security software it doesn't mean they are competent and won't cause more harm than good. Every month the security team wants me to give full code or cloud access to some new scanner they want to trial. They love the fancy dashboards and lengthy reports but if I allowed just 10% of what they wanted we would be pwned on the regular...

I audited Trivy's GitHub Actions a while back and found some worrying things, the most worrying bit was in the setup-trivy Action where it was doing a clone of main of the trivy repo and executing a shell script in there. There was no ref pinning until somebody raised a PR a few months ago. So a security company gave themselves arbitrary code execution in everyone's CI workflows. Aqua were breached earlier this month…

The ref pinning part is almost worse than no pinning. You can pin the action itself to a commit SHA, sure. But half the actions out there clone other repos, curl binaries, or run install scripts internally. Basically none of that is covered by your pin. You're trusting that the action author didn't stick a `curl | bash` somewhere in their own infra.

Audited our CI a few months back and found two actions doing exactly that. Pinned to SHA on our end, completely unpinned fetches happening inside.

Post reply on HN