"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.
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.
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.
Well, not my best 2 weeks at work, now I have to fill out a dozen forms and sit trough a shitload of meeting, just because they got pwned (twice, or once, but really badly :D )
So the first incident was on March 19th and the second incident is March 22nd —- evidently the attackers maintained persistence through maybe two separate credential rotation efforts.
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, failed to contain it, got breached again last week, failed to contain it again, and now the attackers have breached their Docker Hub account. Shit happens but they're clearly not capable of handling this and should be enlisting outside help.
Granting broad access to "security" tools so some vendor can take another shot at your prod keys is not risk reduction.
Most of these things are just report printers that makes more noise than a legacy SIEM, and once an attacker is inside they don't do much besides dump findings into a dashboard nobody will read.
If you want less self-inflicted damage, stick new scanners in a tight sandbox, feed them read-only miror data, and keep them away from prod perms until they have earned trust with a boring review of exactly what they touch and where the data goes.
Otherwise you may as well wire your secrets to a public pastebin and call it testing.
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.
Most of corporate security nowadays involves "endpoint security solutions" installed on all devices, servers and VMs, piping everything into an AI-powered dashboard so we can move fast and break everything.
second breach in a month from the same initial credential compromise. the first rotation didn't fully revoke access. the attacker walked right back in. no persistence needed.
Wasn't this discovered already last week, on Friday, that the threat actor had replaced the legit images with malware images? And republished 75 out of 76 tags?
No, the actor reappeared. This article is not fully updated. On March 22nd, the actor compromised their DockerHub account and published new Docker images.
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.
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
"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.
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.
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.
You're supposed to scan for vulnerabilities, not become one!
When you stare into the vuln, the vuln stares back at you.
People have been warning about giant security holes in GitHub Actions dependency but MS did nothing.
Well, not my best 2 weeks at work, now I have to fill out a dozen forms and sit trough a shitload of meeting, just because they got pwned (twice, or once, but really badly :D )
> On March 22, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.5 and v0.69.6 DockerHub images. (https://github.com/aquasecurity/trivy/security/advisories/GH...)
So the first incident was on March 19th and the second incident is March 22nd —- evidently the attackers maintained persistence through maybe two separate credential rotation efforts.
As far as I understood it, their entire repo got pwnd in February, and this now is the third successful attack by the same actor.
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
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, failed to contain it, got breached again last week, failed to contain it again, and now the attackers have breached their Docker Hub account. Shit happens but they're clearly not capable of handling this and should be enlisting outside help.
It seems they did end up contracting with Sygnia
Granting broad access to "security" tools so some vendor can take another shot at your prod keys is not risk reduction. Most of these things are just report printers that makes more noise than a legacy SIEM, and once an attacker is inside they don't do much besides dump findings into a dashboard nobody will read.
If you want less self-inflicted damage, stick new scanners in a tight sandbox, feed them read-only miror data, and keep them away from prod perms until they have earned trust with a boring review of exactly what they touch and where the data goes. Otherwise you may as well wire your secrets to a public pastebin and call it testing.
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.
Most of corporate security nowadays involves "endpoint security solutions" installed on all devices, servers and VMs, piping everything into an AI-powered dashboard so we can move fast and break everything.
second breach in a month from the same initial credential compromise. the first rotation didn't fully revoke access. the attacker walked right back in. no persistence needed.
Wasn't this discovered already last week, on Friday, that the threat actor had replaced the legit images with malware images? And republished 75 out of 76 tags?
No, the actor reappeared. This article is not fully updated. On March 22nd, the actor compromised their DockerHub account and published new Docker images.
How the heck are credential compromises still a thing with 2FA and refresh tokens???
How bugs are still possible now when we all write everything in Rust?
/s But I thought npm was the issue, and all of this couldn't happen anywhere else?!
What if we just rebuild everything from scratch with AI? No more supply chain attacks!
Just use OpenClaw. Oh wait, I think Microslop already did...
Don't underestimate the prowess of Microslop to fuck up. I'm just glad I saw all of this coming and abandoned this hellscape long ago.
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
You only need internet access to grab the image, I don't think trivy requires internet access itself. All of my image scanning tools run in isolation.
> 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.
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
> I don't think it would help here, they were stealing credentials
So, stealing credentials in the current directory and in all other directories are the same thing?
fatiguing
GG