"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.
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.
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.
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...
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 )
This pattern keeps recurring because the root cause isn't really about Trivy specifically — it's that GitHub Actions has no native concept of content-addressed references at the UX layer.
The SHA pinning workaround works, but it shifts the maintenance burden to the consumer. Every upstream patch now requires a manual (or bot-assisted) SHA update. Most teams don't have that automation in place, so they either accept the security risk or fall behind on patches.
The interesting design question is: what would a CI/CD system look like if it managed its own Action versions rather than delegating that to workflow YAML? You'd get immutability by default without the maintenance overhead.
(I've been exploring this problem with FlowEasy — generating and managing the YAML means you can enforce SHA pinning and Dependabot-style updates without asking teams to maintain it manually. Happy to discuss the tradeoffs if anyone's interested.)
This has always been my big "WTH?" whenever I see people using github actions. "You're literally taking someone else's script and ruining it against your codebase"
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?
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.
"This is a good reminder for any bot or automation service using GitHub Actions for deployment. Trade-only API keys with no withdrawal permissions become even more critical when your CI/CD pipeline could be compromised. Separation of concerns saves accounts."
> 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.
Trivy under attack again: Widespread GitHub Actions tag compromise secrets
(socket.dev)239 points by jicea 22 March 2026 | 80 comments
Comments
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.
> 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.
Trivy ecosystem supply chain temporarily compromised - https://news.ycombinator.com/item?id=47450142 - March 2026 (35 comments)
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.
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...
The SHA pinning workaround works, but it shifts the maintenance burden to the consumer. Every upstream patch now requires a manual (or bot-assisted) SHA update. Most teams don't have that automation in place, so they either accept the security risk or fall behind on patches.
The interesting design question is: what would a CI/CD system look like if it managed its own Action versions rather than delegating that to workflow YAML? You'd get immutability by default without the maintenance overhead.
(I've been exploring this problem with FlowEasy — generating and managing the YAML means you can enforce SHA pinning and Dependabot-style updates without asking teams to maintain it manually. Happy to discuss the tradeoffs if anyone's interested.)
Please don’t scare people like this!
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.