Pinning github actions by commit SHA does not solve the supply chain problem if the pinned action itself is pulling in other dependencies which themselves could be compromised. An action can pull in a docker image as a dependency for example. It is effectively security theatre. The real fix is owning the code that runs in your CI pipelines. Or fork the action itself and maintain it as part of your infrastructure.

We do address this in the article! It's defense in depth, not theater.

We audit all of our actions, check if they pull in mutable dependencies, contribute upstream fixes, and migrate off using any action when we can.

(I work at Astral)

Do you fork them and have a team maintaining forks ?

If not you cant be sure of anything. Its just a security theater.

> It is effectively security theatre.

I disagree. Security is always a trade-off.

Owning, auditing, and maintaining your entire supply chain stack is more secure than pinning hashes, but it is not practical for most projects.

Pinning your hashes is more secure than not pinning, and is close to free.

At the end of the day, the line of trust is drawn somewhere (do you audit the actions provided by GitHub?). It is not possible to write and release software without trusting some third party at some stage.

The important part is recognizing where your "points of trust" are, and making a conscious decision about what is worth doing yourself.

Shouldn't you always read & double-check the 3rd-party GitHub actions you use, anyway? (Forking or copying their code alone doesn't solve the issue you mention any more than pinning a SHA does.)

Double checking Github actions does not mitigate threats from supply chain vulnerabilities. Forking an action moves the trust from a random developer to yourself. You still have to make sure the action is pulling in dependencies from trusted sources which can also be yourself depending on how far you want to go.

Coding agents are like asking a genie for code. They will give you the code you ask for alright but you never know what kind of curse has been crontabbed for you.

Or a monkey paw.

It should have been FastAPI instead.

Interesting blog post. For what it's worth, I count 7 em-dashes used.

What features related to distrobox? I use both ptyxis and distrobox and I don’t notice any integration between them. I do notice an integration between ptyxis and sudo however. It simply turns the title bar red.

> Ptyxis: Your Container-Oriented Terminal for GNOME

> A modern terminal emulator built for the container era. Seamlessly navigate between your host system and local containers like Podman, Toolbox, and Distrobox with intelligent detection and a beautiful, responsive GNOME interface.

https://gitlab.gnome.org/chergert/ptyxis/-/blob/main/README....

Ask the LLM to create for you a POC for the vulnerability you have in mind. Last time I did this I had to repeatedly make a promise to the LLM that it was for educational purposes as it assumed this information is "dangerous".

This is actually pretty interesting. I guess I knew you could do this offensively but it didn’t occur to me to use it OWASP style to test my own work.

I revived a once popular Youtube frontend called Cloudtube. All the Youtube media url deciphering is still done by Invidious and I use it more like a frontend for invidious.

https://github.com/rhee876527/clean-youtube/

Opensuse have been working on making secure boot/TPM FDE unlock easy to use for a while now. https://news.opensuse.org/2025/11/13/tw-grub2-bls/

Same with <svg> but Firefox's XML parser will not greenlight you.

Docker provides some host isolation which can be used effectively as a sandbox. It's not designed for security (and it does have some reasonable defaults) but it does give you options to layer on security modules like apparmor and seccomp very easily.