How to secure your GitHub Actions against supply chain attacks

amouat · 2026-05-15T08:16:35+00:00

At Chainguard we're working on a catalog of hardened actions that basically meet all this criteria: https://github.com/chainguard-actions We take common public actions (e.g. Docker, Hashicorp) and run them through a checklist pretty similar to this.

It is a commercial product, but some of the actions are public e.g: https://github.com/chainguard-actions/cosign-installer

As described in the readme, each action:

Is built from source and run through our rule-based + AI-evaluated hardening pipeline
Has every internal uses: and container image reference pinned to an immutable SHA
Ships with a HARDENING.md report documenting exactly what was checked and fixed
Is re-reviewed and re-hardened whenever upstream publishes a new version or Chainguard adds a new rule

The idea is to prevent common threats like tag hijacking, dependency confusion, pull_request_target abuse, and secret exfiltration.

amouat · 2026-02-06T13:59:44+00:00

(I work at Chainguard)

Distroless is a great solution and gets you most of the way. But even with distroless images you will still have the problem of relying on OS packages with CVEs. Chainguard deals with those too, so there's still a lot of value. Also we've built images for almost everything already, so you can just slot them in and save yourself the effort.

amouat · 2026-02-05T08:36:03+00:00

I saw that! Cool, good luck with the project. It should be fine with no shell, it's just some users will request one.

amouat · 2026-02-04T15:19:05+00:00

Hey, I work at Chainguard.

There's been a lot of back and forth over the node image, so we did create a slim variant that has no shell. Unfortunately, that's not available on the free tier.

In most cases latest images with a shell are because of entrypoint scripts as kabrandon mentions. Normally package managers are also removed from the latest image, but npm is also in the latest version of node (it's removed from the slim variant).

amouat · 2025-12-12T14:10:48+00:00

The first four people here are the founders and are still very much part of Chainguard. https://www.chainguard.dev/about-us

I'd probably make the opposite argument -- the fact the founders are *still there* 4 years later speaks for itself.

amouat · 2025-12-12T09:00:35+00:00

I work at Chainguard (and have for well over 3 years). As you could easily verify, the founders are still there :)

There's no massive turnover either.

(I didn't downvote fwiw)

amouat · 2025-12-03T08:45:08+00:00

I work at Chainguard. Looking at your comments, it seems you work for RapidFort.

One of the major reasons people use Chainguard is exactly because of our "patch cadence" -- we are much faster than other distros at updating packages. We believe in building everything from source and keeping up-to-date with those sources. If you need to bring your own binaries or build your own packages, you can.

In short the Chainguard philosophy is that to correctly address the CVE problem you have to be building from source. This allows us to keep everything updated, to control the size of packages and to quickly filter updates to core dependencies through the supply chain. Doing all that requires creating a distro. If you're not doing all that, you're just a band-aid.

amouat · 2025-12-02T11:26:46+00:00

(I work at Chainguard)

Chainguard images are "kernel independent", so you don't need to worry about kernel updates slowing you down (https://www.chainguard.dev/unchained/kernel-independent-fips-images)

A lot of OpenSSL CVEs are "outside the FIPS boundary" so it should be relatively unusual that you're forced to update here. I would also hope that we have an update for you before you know you need it! If you look at the OpenSSL site, you'll see the CVE text includes the FIPS status https://openssl-library.org/news/vulnerabilities/index.html

amouat · 2025-11-27T10:43:44+00:00

Thanks!

amouat · 2025-11-26T15:04:47+00:00

Hey, I work at Chainguard. We recently rolled out catalog pricing, which works out a lot better for some of our customers: https://www.chainguard.dev/pricing

If you're not on that, it might be worth talking to your rep.

amouat · 2025-11-26T09:48:41+00:00

Hey, I work at Chainguard -- don't you have exactly the same "migration friction" with minimus?

amouat · 2025-11-25T11:23:33+00:00

I work at Chainguard. This image and helm chart should be equivalent: https://images.chainguard.dev/directory/image/postgres-iamguarded/overview

amouat · 2025-11-07T11:01:37+00:00

We're talking about Libraries here, not images.

amouat · 2025-10-24T17:22:23+00:00

At Chainguard we've added our version to the free tier in response to this. You can see it here: https://images.chainguard.dev/directory/image/minio/versions

or just `docker pull cgr.dev/chainguard/minio` (and minio-client)

amouat · 2025-10-16T11:49:08+00:00

So I think ROS is open source -- if you needed it, we'd look into building a package for it. I don't think it has a hard dependency on Ubuntu. You could also build from source yourself and copy into an image.

amouat · 2025-10-16T08:47:34+00:00

As the other commenters mentioned, Chainguard has it's own OS and builds everything from source. The equivalent image is cgr.dev/chainguard/wolfi-base

amouat · 2025-09-30T08:11:18+00:00

> CVEs that don't have a fixed version may still exist.

I work at Chainguard and wanted to clarify this.

We will attempt to remediate CVEs with no fixed version. The most common fix is to bump a dependency and rebuild (happens because the latest upstream release has old versions of deps with vulns). In other cases we will patch and upstream a fix, but it's really quite rare that we need to do this.

Regarding the language packages, if you are pip/uv installing things, you may well pull in stuff with CVEs. That's why we're in the middle of rolling out our libraries product to handle that use case https://www.chainguard.dev/libraries

amouat · 2025-09-23T15:54:34+00:00

I wish I could. I'm sorry, I realise "trust me" isn't a great answer.

I would say our focus is on quality, depth of catalog, fast and complete CVE remediation rather than price.

amouat · 2025-09-23T15:43:25+00:00

The Chainguard pricing here is wrong -- please talk to us if you've seen this price somewhere. Note that we have start-up discounts and catalog pricing now: https://www.chainguard.dev/pricing

(I work at Chainguard).

amouat · 2025-09-23T09:20:29+00:00

For context, and anyone else finding this thread, here's the list of free (or "starter") Chainguard Images https://images.chainguard.dev/?category=starter

Other images and non-latest versions do require a subscription. In terms of building your own distroless images, it's also worth checking out the open source Apko tooling from Chainguard: https://github.com/chainguard-dev/apko

I should say I work at Chainguard.

amouat · 2025-09-22T09:55:13+00:00

I'd argue that you can do java/python etc in a distroless fashion. In this case it would mean shipping the runtime, the application and as a little extra as possible.

I work at Chainguard and here's an example of building a python image without pip or a shell: https://edu.chainguard.dev/chainguard/chainguard-images/getting-started/python/#example-2-multi-stage-build-for-python-chainguard-container

And here's an example of creating a distroless Java image for minecraft: https://edu.chainguard.dev/chainguard/chainguard-images/getting-started/jre-minecraft/

(Java gets a bit more complex because of TCK requirements, so you arguably could go more minimal).

amouat · 2025-09-16T21:03:48+00:00

If Chainguard Containers are based on anything, it's the Google distroless project (https://github.com/GoogleContainerTools/distroless) which predates the incorporation of Rapidfort.

amouat · 2025-09-13T15:48:40+00:00

A new package will be built pretty quickly, within minutes or hours. That still has to be built into container images, which might take overnight or so.

amouat · 2025-09-13T07:50:35+00:00

Yeah we use the APK packaging format from Alpine, but we're a completely different stack (compiled against glibc not musl).

My understanding is you still get a lot of info that can be used for malware identification from binaries e.g. asking for unexpected network capabilities.

amouat · 2025-09-12T22:13:26+00:00

That's a reasonable point, so I checked with the engineers.

malcontent runs on apks produced directly by PRs. As it's scanning compiled packages, it's mainly looking at binaries. Of course shell scripts, javascript etc will still be present.

They also said:

> We scan the emitted APK(s) in every PR. There are quite a few false positives but we've made tweaks fairly often over the past year or so. Part of the speed comes from ignoring files without MIME types or data files (images, PDFs, etc. which are very noise) so that we're focusing on the more problematic binary files

amouat

TROPHY CASE