I got frustrated with how GitHub Actions lets workflows with read-only permissions poison the cache of read/write workflows (!!??!?), so yesterday night I put together an Action that runs commands in a gVisor sandbox.

I am using it to test our Go modules against the latest versions of their dependencies (with "go get -u") on a schedule, to be notified early of compatibility issues, but without the supply chain attack risk or the Dependabot churn.

https://github.com/geomys/sandboxed-step

GitHub - geomys/sandboxed-step: A GitHub Action that runs a command in a gVisor sandbox

A GitHub Action that runs a command in a gVisor sandbox - geomys/sandboxed-step

GitHub
@filippo Thanks for that! Will give it a test this weekend and hopefully adopt it in my CIs.

@filippo You might be able to use "docker image save [...]" instead of having to create a container just for exporting it.

Also, in case you aren't aware, GitHub has arm64 runners available now: https://github.blog/changelog/2025-08-07-arm64-hosted-runners-for-public-repositories-are-now-generally-available/.

arm64 hosted runners for public repositories are now generally available - GitHub Changelog

Starting today, Linux and Windows arm64 standard hosted runners in public repositories are generally available. Developers can take advantage of the performance benefits of using arm64 processors or run their…

The GitHub Blog
@filippo "Why don't we just run all of our CI in gVisor" is a thing I ask myself frequently.
@filippo Does GitHub allow to have pipeline definitions in a separate repository like GitLab does? Thought that concept was interesting, but obviously brings other challenges regarding compatibility with changes of time and release branches with long-term support.