> 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 are pulled in.

The trick, of course, is some solution that allows the latter without the former, that doesn't just destroy dev productivity. And remember, …there is no evil bit.

(… I need to name this Law. "The Paradox of Pinning"?)

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

You can pin a GitHub Action to a SHA, but the GitHub Action can be a Docker one pointing to a mutable Docker image label.

Example:

https://github.com/github-community-projects/issue-metrics/b...

> Why doesn't GitHub just enforce immutable versioning for actions?

You can't. They can execute arbitrary code. They can download another bash file via Curl and execute that.

This recommendation is currently broken. Even when you pin the full commit SHA for an action, that action may still pull in transitive dependencies (other actions) that aren't pinned.

A better question perhaps is why we’ve allowed ourselves to be so vulnerable by a single provider (GitHub). Supply chain attacks would have a significantly smaller blast radius if people start using their own forges. GitHub as a social network is no longer a good idea

Even then, that's only immutable for the workflow config. Many workflows then go on to pull in mutable inputs downstream (eg: default to "latest" version).

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.

what if you pin it to a version that is compromised for years before finding out?

Allowing it to be updated can also fix security problems.

It’s basically all the same arguments as static vs dynamic linking.

Plus, I believe I saw that the one action was getting the latest version of trivy anyway.

Because the true name of the feature is VisualSourceSafe actions. It's all over the code of the runner if you take a second to look, and the runner, like the rest of the feature, is of typical early 2000s Microsoft quality, which is to say, none at all.

[dead]

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.

temporarily might be a bit of an euphemism here

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.

When you stare into the vuln, the vuln stares back at you.

a security scanner that cant secure its own credentials. at this point the irony writes itself

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.

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.

My hypothesis is that generally, there's no quality floor at which security departments are "allowed" to say "actually, none of the options on the market in this category are good enough; we're not going to use any of them". The norm is to reflexively accept extreme invasiveness and always say yes to adding more software to the pile. When these norms run deeply enough in a department, it's effectively institutionally incapable of avoiding shitty security software.

Fwiw w/r/t Trivy in particular,I don't think Trivy is bad software and I use it at work. We're unaffected by this breach because we use Nix to provide our code scanning tools and we write our own Actions workflows. Our Trivy version is pinned by Nix and periodically updated manually, so we've skipped these bad releases.

From having worked at and consulted with security software producing companies as well as security software consuming ones, I would say the security companies are worse than average at security.

And their security teams more cynical.

Sometimes they deliberately hire lower aptitude candidates to run internal security to prevent them from getting distracted by the product.

In other cases they are getting high on their own supply, more or less.

Jack Welch style management seems to take a deeper toll in this sector.

[dead]

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.

Usually through service accounts. Those are single factor.

How bugs are still possible now when we all write everything in Rust?

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

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

No, the actor reappeared. This article is not fully updated. On March 22nd, the actor compromised their DockerHub account and published new Docker images.

What if we just rebuild everything from scratch with AI? No more supply chain attacks!

No one has ever said that supply chain attacks are limited to npm.

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.

People should really just move away from pip/requirements.txt and move to poetry or uv. They tend to solve this problem more elegantly and through their normal default workflows.

They warned you!