Live data from Hacker News

Trivy under attack again: Widespread GitHub Actions tag compromise secrets

socket.dev

21–30 of 97 posts

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

#21
post #10

I always run such tools inside sandboxes to limit the blast radius.

The sandbox will need internet access (to update data) and you will need to send code to test into it; so compromise already equals leaking all your code, without even breaking the sandboxing

> The sandbox will need internet access (to update data) and you will need to send code to test into it; so compromise already equals leaking all your code, without even breaking the sandboxing

Compromising all code in one directory is bad. Compromising all my data in all other directories, including mounted cloud drives, is worse.

I restrict most dev tools to access only the current directory.

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

#22
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...

[flagged]

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

#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 talking about, and GH has an absurd number of different types of tokens/keys one can use.

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

#26
post #14
post #10

I always run such tools inside sandboxes to limit the blast radius.

I don't think it would help here, they were stealing credentials

Whenever possible, credentials shouldn't be inside the sandbox either. Credential proxying, or transparent credential injection, for example with Sandcat: https://github.com/VirtusLab/sandcat

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

#27
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...

[flagged]

Couldn't agree more.

Yet many of these tools have setup like: create a service account, give it about thousand permissions (if not outright full ownership) and send us the JSON private key.

At least they make the red flag nice and obvious.

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

#28

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.

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

#30
post #24
post #2

Recent and related: Trivy ecosystem supply chain temporarily compromised - https://news.ycombinator.com/item?id=47450142 - March 2026 (35 comments)

temporarily might be a bit of an euphemism here

temporally
Post reply on HN