lots of questions here regarding what this product is. I guess i can provide some information for the context, from a perspective of an outside contributor.
Chainguard Images is a set of hardened container images.
1. distroless were based on Debian - which in turn, limited to Debian's release cadence for fixing CVE.
2. distroless is using bazelbuild, which is not exactly easy to contrib, customize, etc...
3. distroless images are hard to extend.
Chainguard built a new "undistro" OS for container workload, named Wolfi, using their OSS projects like melange (for packaging pkgs) and apko (for building images).
The idea is (from my understanding) is that
1. You don't have to rely on upstream to cut a release. Chainguard will be doing that, with lots of automation & guardrails in placed. This allow them to fix vulnerabilties extremely fast.
Why go through all the analysis, etc.. where you can patch it very quickly.
2. The OS is glibc-based. Which is a lot more friendly than Alpine.
3. It's pretty much YAML which is kinda easy to package software into APK packages & then images (with apko)
4. SBOM
and a lot more. But that's stuff on top of my head.
I read the blog, then I clicked on the big "back" button at the top labeled "Unchained" and read that, then I went to your homepage and read that, then I clicked "get started" and read that page too.
I still have no idea what Chainguard is, or what those images do. All I know is those images are "hardened", is that the only thing they're for? Is that Chainguard's product?
In a nutshell we produce minimal container images with a low CVE count. In many cases they should be drop in replacements for the containers you are currently using.
This is particularly useful if your team uses a scanner like trivy/snyk/grype/Docker Scout and spends time investigating CVEs. Less CVES == less time investigating. It can also be critical in regulated environments.
I think this comes down to audience. To a lot of engineers it's just like ... "OK, that's nice. What else?"
But for security teams in large enterprises, Chainguard is like manna from heaven. They immediately understand what is really being sold: the elimination of enormous amounts of compulsory toil due to upgrading vulnerable software -- or having to nag other teams to do it.
It's a bit like visiting the site of a medical devices manufacturer. I probably don't know what the device does, but the target audience sure do.
I just heard of this today and I was like OMG this will save me so. much. time. chasing engineers and teams and creating work around for dumb stuff that the base images refuse to fix because it's a "false positive". I unfortunately HAVE to fix all high CVEs, regardless of peoples opinions.
> But for security teams in large enterprises, Chainguard is like manna from heaven. They immediately understand what is really being sold: the elimination of enormous amounts of compulsory toil due to upgrading vulnerable software -- or having to nag other teams to do it.
Explain to me how Chainguard helps with this. Everywhere I've worked, this process has very specific needs depending on the companies internal and regulatory requirements. Chainguard may help with proof of origin/base imaging, but it doesn't do much beyond what container registries and tools like dependabot/snyk/dependency track already provide (not saying they're directly related), which doesn't really reduce that much toil.
The big ones that help are SBOMs, STIGs, FIPS, and CVE reduction. The images and the paperwork we provide make it so they can be dropped in to even the most regulated environments without toil.
Most of our customers use them for FedRAMP or IL 5/6 stuff out of the box.
As someone who has been watching Chainguard since they were "spun out" of Google, they started out trying to be the defacto container supply chain security company, realized everyone else was already doing that and well ahead of them, and have done a few pivots trying to find PMF. I think they've found more success being consultants, which is probably not what they hoped for.
Many organizations pay people (or entire teams) to maintain a suite of hardened images, either for device/firmware applications, or because they use many languages in-house, etc. This is definitely one of those business models I thought "oh, of course" as soon as I saw it.
EDIT: upon using dockerhub’s organization page for a bit, and realizing there’s no search on the organization page (I swear there was?), I now understand.
Why does the article present this bizarre set of instructions for grabbing the image instead of linking directly? You could just link your organization no?
> Getting started with Chainguard Developer Images in Docker Hub is easy. Follow these simple steps:
> Look up the Image you want.
> Select ‘Recently Updated’ from the dropdown menu on the right.
> Filter out the community images by selecting the filter ‘Verified Publisher.’
> Copy the pull command, paste it into your terminal, and you are all set.
If a primary goal of a consumer of the images is security, how can we trust the images not to have backdoors or virusesesses [extra s added for comedy]?
Great question! We take hardening of our build infrastructure very seriously, and helped build many of the OSS technologies in this space like the SLSA framework and the Sigstore project.
We produce SBOMs during the build process, and cryptographically sign SLSA-formatted provenance artifacts depicting the entire build process so you can trace a built container all the way back to the sources it was built from.
We also try to make as much of our build system reproducible as possible (but we're not all the way there yet), so you can audit or rebuild the process yourself.
The second is this blog post which highlights trust and again Docker Hub features (e.g. rate limit removal, metrics, badging) and links back to [2] for more details.
The third link is [1].
So, I'm still left curious about the grandparent comment's questions. It seems these pages are sparse on what the verification process looks like and if it might just be a "pay to play" relationship.
Lots of teams get thrashed trying to fix or bring down the count of CVEs so they can ship, so chainguard provide images with a guarantee of 0 CVEs. It saves folks a lot of time patching to bring down the count. However its a novel situation as most of the time these vulnerabilities are not even reachable in the first place, they are just noise. So its a solution more appeaseing to security theatre, than a real world threat. Once in a while a nasty thing comes along like log4shell, heartbleed, but most of its just noise. They do cut down image size significantly though, which is something I personally like and has value for saving ingress costs. Think Alpine.
Chainguard is proof that modern CI/CD is still a luxury product for most of the industry. They have a fantastic amount of automation behind image production, including some tools they rolled themselves (like apko).
Disclosure: I am friends with / have worked with some Chainguard folks.
Declarative image builds, nightly rebuilds of the whole ecosystem, and they bake the SBOM into the images. It is a really good offering. It's a shame we had to use the competing offering from RedHat for contractual reasons.
I work at Chainguard, hoping this helps answer your question. Chainguard has free and paid images. You can find all the free images in the Chainguard Images Directory: https://images.chainguard.dev/directory?category=all
I was expecting an answer to my question to then build myself an answer to his original question. I was trying to showcase what Chianguard Images are in a nutshell. But you are right: overly complicated.
What images do you usually use and where do you pull them from? ;-)
Might be worthwhile restating the companies business model in announcements like this, especially for people unfamiliar with the area. This sounded like some wireguard thing from the name, only to discover it's just an org delivering statically linked binaries in a scratch docker image to defeat scanners...
- we don't use scratch. Our base image is chainguard/static which includes certs and a few other things typically needed by apps.
- we have our own Linux distribution called Wolfi
- we don't "defeat scanners". We work with scanners and publish security advisories. They recognise Wolfi. You can definitely find some images of ours that have CVEs (especially if you have an old image lying around).
There's no defeating of scanners or even static linking. It's all automation, dynamic linking and patching to make the scanners happy. We go to great lengths to make sure that the scanners actually find everything so the results are accurate.
I'm excited to see this. One of my reservations on using chain guard images previously was how they only hosted them on their own registry, which had previously yanked access behind a pay wall for using any tag other then latest. At least with this wolfi images (nominally an oss project) won't be locked in a commercial registry vs a defacto public registry.
It would be awesome if the Wolfi base image integrated nicely with Clair at some point too! I think someone was working on that last year but seems like it stalled.
Chainguard Images is a set of hardened container images.
They were built by the original team that brought you Google's Distroless (https://github.com/GoogleContainerTools/distroless)
However, there were few problems with Distroless:
1. distroless were based on Debian - which in turn, limited to Debian's release cadence for fixing CVE.
2. distroless is using bazelbuild, which is not exactly easy to contrib, customize, etc...
3. distroless images are hard to extend.
Chainguard built a new "undistro" OS for container workload, named Wolfi, using their OSS projects like melange (for packaging pkgs) and apko (for building images).
The idea is (from my understanding) is that
1. You don't have to rely on upstream to cut a release. Chainguard will be doing that, with lots of automation & guardrails in placed. This allow them to fix vulnerabilties extremely fast. Why go through all the analysis, etc.. where you can patch it very quickly.
2. The OS is glibc-based. Which is a lot more friendly than Alpine.
3. It's pretty much YAML which is kinda easy to package software into APK packages & then images (with apko)
4. SBOM
and a lot more. But that's stuff on top of my head.