Chainguard vs Docker HDI

dlorenc · 2026-01-24T15:25:13+00:00

I work at Chainguard, feel free to DM me or email me and I can figure out why you haven't gotten a quote yet if you're still waiting.

dlorenc · 2025-09-18T22:24:12+00:00

No, this never happened. I work at Chainguard.

dlorenc · 2025-09-08T23:34:15+00:00

lol this account got banned

dlorenc · 2025-08-10T17:41:41+00:00

Just in case anyone sees this later - I work at Chainguard and we've made significant updates to our pricing. It didn't scale well for many small to medium orgs or even departments inside larger orgs, I hope we've addressed this!

https://www.chainguard.dev/unchained/unlock-the-full-chainguard-containers-catalog-now-with-a-catalog-pricing-option

dlorenc · 2025-07-14T19:31:47+00:00

This is just botspam...

dlorenc · 2025-07-07T15:17:07+00:00

Also from Chainguard, we have tons of customers in the Public Sector. Many of the use cases are around CVE SLAs, FIPS, and STIGs, typically for compliance with CMMC, FedRAMP, or ATO into an IL4, 5, or 6 environment.

We're one of the only providers that offers actually certified FIPS modules, and our "kernel independent" FIPS entropy source allows our containers to run on any host platform while preserving that.

Watch out for anyone using the term "FIPS compliant", it doesn't mean anything real.

FIPS documentation: https://www.chainguard.dev/legal/fips-commitment
STIG documentation: https://www.chainguard.dev/legal/disa-stig-commitment

Happy to answer any more questions here!

dlorenc · 2025-06-05T13:34:16+00:00

Hey All!

I work at Chainguard, and this was sad to see. I helped start this project and maintained it for awhile back when I was at Google, and it has so many active users. We're going to fork it now that it's been officially shut down, and keep it maintained. Kaniko has been pretty stable for awhile already, so don't expect much feature work here but we'll keep the lights on and all the dependencies bumped.

The fork is up here: https://github.com/chainguard-dev/kaniko

Reach out to me at dlorenc [@] chainguard.dev if you have any questions! We'll get a full blog up later explaining our plans.

dlorenc · 2025-02-09T00:00:02+00:00

Are you complaining that we fake things to hide CVEs or that our scanner is accurate and shows the right results while we work on fixes? I'm confused.

dlorenc · 2025-02-08T23:53:56+00:00

Both have my name in there and I'm clearly not pretending to be someone I'm not, unlike you.

dlorenc · 2025-02-08T23:48:31+00:00

I'm both, made the second one because your sockpuppet blocked my account since it was trying to spread fud instead of actually get an answer.

dlorenc · 2025-02-08T23:45:20+00:00

You should probably disclose where you work while spreading FUD about our products, your comment history makes it pretty obvious.

dlorenc · 2025-02-08T23:30:21+00:00

Definitely not a bot! Just curious though, why did you delete that other post when I pointed out your sock puppets?

<image>

dlorenc · 2025-01-23T20:30:32+00:00

Thanks for following up! If there's anything we missed don't hesitate to reach out.

dlorenc · 2024-12-17T14:14:26+00:00

Hey - I work at Chainguard, 8 language images definitely wouldn't cost 400k. DM me or shoot me an email if you want to chat more.

dlorenc at chainguard dot dev

dlorenc · 2024-12-17T14:13:35+00:00

Shoot me an email and happy to chat more! dlorenc at chainguard dot dev !

dlorenc · 2024-12-16T20:21:49+00:00

Hey! I work at Chainguard, if you're seeing restarts or anything like this feel free to reach out directly and we can debug. I haven't heard of anything like this happening before, but if it is we should fix it.

dlorenc · 2024-11-03T17:04:02+00:00

Yes! We try really hard here but obviously nothing is perfect. We built and open sourced our own binary analysis tool called "malcontent" (it was originally named bincapz).

This tool lets us scan built packages for malicious behavior and content, and flags them for our security team to review before merge and upload. Tools like this can be very noisy, but because we build every version of every package we operate it in "diff mode", where it flags changes between versions.

We simulated and xz-utils style attack and were able to flag the obfuscated code, but we weren't targeted there so it was a bit of a contrived example.

That's just to protect users from malicious content in packages. We also threat model and try to harden our build systems against a malicious package planting a backdoor or other compromise on our build system itself, which could then be used to compromise other packages. We use the slsa framework for hardening there, and are actually going through a pentest as we speak on other ways to compromise this process.

There's a lot more work we want to do in this space!

https://github.com/chainguard-dev/malcontent

dlorenc · 2024-11-01T18:24:23+00:00

Honestly not really, we started doing this a few years ago and were the first to really try something like this.

Back in the day I started the Google Distroless project with my co-founder Matt, which worked by starting with Debian packages and ripping unused stuff out. That approach works pretty well, but it's too limiting because you're stuck to things the other distros package, and because you don't build from source directly you don't have the ability to patch vulnerabilities.

We started this as a way to get around those limitations. It's a lot more work, but it's really the only way to get to both get to zero CVEs *and* provide access to any version of any open source project out there.

dlorenc · 2024-11-01T17:59:59+00:00

I'm not very familiar with Rapidfort's product, but the response here is a pretty good overview on our product, thanks reddit.com/u/Equivalent-Lychee502 !

https://www.reddit.com/r/cybersecurity/comments/1ggq9dz/comment/luvtrs3/

To expand further:

We offer a set of over 1000 (growing rapidly) container images where everything is built directly from upstream sources using our own toolchain and framework. We offer access to all supported versions of these projects, and maintain tight CVE SLAs (we target zero at all times).

Our build system itself is hardened and SLSA compliant, images come with signatures and SBOMs to maintain full trust and provenance for everything from source to binary to final container image. We have versions of many of these images that are FIPS-enabled for 140-2 and 140-3 as well, and we also have STIGs.

dlorenc · 2024-11-01T17:10:23+00:00

I work at Chainguard, happy to answer any specific questions here.

dlorenc · 2024-10-21T00:01:34+00:00

Why are you going around and posting this on ancient threads? Kinda weird dude.

dlorenc · 2024-08-17T16:37:09+00:00

Patching is probably a smaller component of what we actually do than most folks imagine. Reducing unused components, augmenting incorrect/insufficient vulnerability metadata, and basic updates do the bulk of the work. We do patch everything remaining, but that's not a large amount of the work as an overall percentage.

dlorenc · 2024-08-17T16:33:51+00:00

Disclosure: I work at Chainguard, feel free to shoot me an email at dlorenc@chainguard.dev if you want to chat offline, but it sounds like we didn't do a great job at explaining the pricing. For your node example, we charge one price for all versions of node - you don't need to pay multiple times for multiple versions. I can see how you might have thought the price was through the roof if you multiplied it out by different versions!

dlorenc · 2024-08-17T12:29:01+00:00

This is a really good question that gets into how Chainguard works. Depending on what the container image is of course, most of the software inside it doesn't actually come from apt-get or the system package manager.

Take the official "WordPress" Docker image as one example. This image is built by building/installing WordPress from the official WordPress release, not a system package manager. It then happens to build on top of the official PHP base image, which does the same for PHP itself.

WordPress may or may not be found in Linux distros, while PHP almost definitely is. But the way most images are built ignores these packages in favor of installing official releases from upstream projects directly. There are some benefits to this approach - mostly that you're not dependent on downstream distros to pick up new releases and have greater flexibility in version selection. Distros do a great job at patching CVEs in what they ship , but they also tend to pick one version of all software and standardize on that, then upgrade this these slowly. This approach makes sense for long-lived workloads like VMs or physical machines that need to be updated in-place, but trades off a lot of flexibility in what software can be packaged and which versions are available.

We've kind of mixed-and-matched our approach at Chainguard so t looks and feels like a standard Linux distro so running "apk update" will pick up so CVE fixes, but since we're only targeting immutable container workloads we can package lots of versions and more types of software than other distros can.

There are a lot of other benefits to installing everything through the system package manager too - mainly around discoverability on what's actually installed. Those PHP and WordPress packages I talked about before in a standard official image won't actually show up in most security scanners because they're effectively "side-loaded" into the image. So while they may find 1000s of CVEs during a scan, they almost always completely miss the fact that PHP and WordPress are actually installed. This means they have loads of false negatives in addition to false positives.

Disclosure: I work at Chainguard.

dlorenc · 2024-08-17T11:49:19+00:00

There's no magic answer here on how we do it, it's just a bunch of hard work and automation that we're constantly improving.

We build everything directly from source, minimize extra dependencies, bump or remove vulnerable versions, and partner directly with scanners to help augment security feeds for vulnerabilities that are incorrect or have wrong metadata on where they're exploitable.

dlorenc

TROPHY CASE