2. These are all built continuously from upstream source on a distroless base… this makes a significant difference in attack surface and CVE count re DHI images and you can easily check our word with a few scans
3. These are truly free… no auth wall, no signup, no trial, no limit on numbers of images or pulls or anything like that
4. We have really invested in making these agent ready… we have a CLI (minicli) designed for both humans and agents to easily discover, understand, migrate to, and build on them… for example, check out the AI migration prompts we provide for each image, we’ve refined these across many customer deployments such that you can copy paste into your agent of choice, point it at a Dockerfile and have it do all / nearly all the work to move to these images
2. Isn't there a slight risk of upstream attacks being amplified by this? With the recent number of software compromises providing a way for people to use images X days old may be useful.
3. This ties into 2, if someone downloads and uses an image that is later found to be compromised they mostly have no way of being notified that happened. Not a huge issue, but is something that should be risk assessed.
I think the argument would be that consuming Minimus' containers would have a less severe amplification (or even reduction), as all upstream attacks that rely on a combination of third-party vulnerabilities would be rendered infeasible (since they reduce the amount of third-party dependencies in an image).
> 3. This ties into 2, if someone downloads and uses an image that is later found to be compromised they mostly have no way of being notified that happened.
For this you need a consumption-aware scanner anyways (e.g. that lists images running in your Kubernetes). Anything else will be too spammy, as you can't notify for everything for you have at some point in time have used as a base image.
For example, with EE, you can create an action to automatically trigger a webhook or send a Slack message when an image you're using has a critical CVE that's likely to be exploited (we also integrate threat intel from EPSS, KEV, etc).
Definitely still value in having runtime scanning / visibility too, but EE makes it easy to do purely on the 'left' side of things too.
1 and 2 are not a reason
3. no X, no Y, also not a reason
4. `rg agents`. Right
The build from source on distroless approach provides a meaningful advantage re attack surface and CVEs versus DHI images. You don’t have to take our word for it, just pull some images and scan with Trivy or Grype or whatever you prefer.
It’s simple but pretty granular too… ‘if this python image gets a fix for a critical CVE that’s actively exploited, trigger a GitHub action to rebuild the app with the updated image
Check out the changelog tab in each image listing and you can see exactly when and why we build each time
I’m not personally familiar with exe.dev but if it can run normal OCI images it should be pretty simple to use ours. If you want a shell and package manager and some common busybox applets, -dev variants are the best option.
You can even do a multi step build if you want to use the fully minimalistic image at runtime. Details at https://docs.minimus.io/foundations/going-distroless
Do you have particular scenarios you’d like the Dockerfiles for or is it just for transparency/ trust (which is a totally valid reason of course)?
The latter. You or an attacker could tamper with the images - however even with the Dockerfiles I can't be sure that the provided images are built from the Dockerfiles, so in the end I'd have to trust you anyway. Also I'd be curious how you build the images.
Thanks for your answer!
Your feedback about Dockerfiles is good though and probably something we can easily add to image listings. I opened an issue for us to add.
Note that we also make our package manager freely available in Community Edition as well, which can make the Dockerfile availability more useful.
An easy comparison is wolfi, which is completely open source.
Oh how I wish that were true.
You may / may not be surprised how many enterprises still run long ago EOL'd versions of various stacks, frequently on full blown OS base layers of similar vintage
We believe there is sufficient value to enterprises in the SLAs and broader feature set to build a great business while making the core benefit available to everyone without friction.
Thanks for the feedback!
Curious how this plays into customizing images with creator, are you guys responsible for all the packaging?
Would my keester be on the line if say an upstream package got hit with an attack but I use it through creator?
2. For creator, you're basically taking any image from our public gallery and able to add whatever other packages from our universe to it, set env vars, upload files (customers typically use this for adding conf files and certificates). Then we maintain that image 'recipe' for you continuously, under the same SLAs we do all the public images. More details at https://docs.minimus.io/enterprise-edition/image-creator#ima...
3. Nope :) We are building every package across our universe continuously. Whenever there's a new version of any of them, we pull source, build package, compute what images (including creator ones) use that package, rebuild those images, test, sign.
currently reg.mini.dev does not have AAAA records. Did not check the blob storage endpoints.
reg.mini.dev is really a front end to Google Artifact Registry which already supports v6. I opened an issue for our devops team to enable it for us.
Thanks for the feedback!
This is our new Community Edition, which are all the exact same images as the Enterprise Edition product customers around the world already use, just without all the other features like image creator, self hosting, integrations, SSO, etc. Click the discover Enterprise Edition button on lower left and you can see a quick comparison table or go to minimus.io to see all the details.
EE also includes contractually backed CVE remediation and support SLAs. If you’d like to try EE and get pricing details, we’d be happy to help! Just click the button on the lower left to get started.
I believe that they will always supply the bleeding edge stable release, but it will always be your responsibility to monitor and manage issues like CVEs, rather than expecting them to do it for you.
By CVEs I mean the architectural stuff that was discovered after the original ingress-nginx repo was archived, so there is no "official" mitigation and it's not just a matter of bumping dependencies, the fixes are actual code.
Chainguard forked the repo and is maintaining their own distribution now, but it's not free.
Edit: honestly I'm flagging this post. This really looks like fishing for customers to make them vulnerable in future.
The point is that you can just use these images instead of what you already have and reduce your vulnerabilities by 97%+ on average.
Think Docker Hub, just without the vulnerabilities.
From my threat attack model, you're just yet another liability - one single service to hack all your "safe" images.
Respect your viewpoint and if these images aren't for you, that's totally fine of course. Many others find it useful to have someone else doing the commoditized but hard work of building thousands of components from source continuously, assembling them into ready to run images, signing, and being as open as possible about their state and configuration as possible.
- Chainguard Images
- Chainguard Libraries
- Chainguard VM
...
With Minimus Community Edition, you now have access to 1,000s of built from source, near 0 CVE images without cost or friction
They’re all normal, OCI compliant images. You can pull them, run them, and build on them like you would any other image.
arm64 and amd64 builds for everything
You surely mean "without known and reported vulnerabilities". I doubt you're proactively fixing the world across thousands of software packages /s
You can also review the different SBOMs for the amd64 and arm64 images, for example - https://images.minimus.io/gallery/images/python-fips/lines/3...
Moreover, even after switching to desktop mode on my phone, there's nothing I see that precludes you from employing a little bit of CSS to make those pages render more nicely on mobile screens.