Let me rewrite the comparison used in the "Example: Using Bitnami vs. Minimus" section of the blog post:
Using Bitnami Secure Images:
You pull a versioned PostgreSQL image built on a minimal-attack-surface OS (Photon). When a CVE is disclosed or a new upstream version is released, Bitnami’s automation takes care of everything: a new container image (and Helm chart, if applicable) is built, tested, and published to your registry within hours.
All you need to do is update to the latest version; no manual CVE monitoring, triage, or patching required.
Just to be crystal clear about the open source part: the code for all container images will continue to be maintained, kept up to date, and publicly accessible on GitHub (https://github.com/bitnami/containers) under the Apache 2 license.
What Bitnami is discontinuing is the publishing of prebuilt images to public registries. However, the build code remains available, so users can still build the images themselves and push them to their own registries by running a couple of commands.
That's what Bitnami Secure Images comes to solve. Bitnami regularly updates its images with the latest system packages; however, certain CVEs may persist until they are patched in the OS (Debian 12) or the application itself. Additionally, some CVEs remain unfixed due to the absence of available patches. In vulnerability scanners like Trivy, you can use the `--ignore-unfixed` flag to ignore such CVEs.
In the case of Bitnami Secure Image, the underlying distro is PhotonOS, which is oriented to have zero CVEs.
I mean I understand that's the goal, but in this specific CVE it looks like the issue was introduced in Bitnami's own scripts sitting on top of everything, so a ideally-zero-CVE underlying OS isn't going to solve that problem at all.
It also seems like this set of changes was made in this specific way to forcibly disrupt anyone using the existing images, many of which were made off the backs of previously existing non-bitnami open source projects, so I assume you can understand why people are annoyed.
But again, anyone with any knowledge or experience of Broadcom saw this coming, so...
This is exactly why so many of us have advocating for private registries and copies of every image you run in production. Pulling straight from Docker Hub was always a risk.
The complete history of Bitnami container images has been copied to the "bitnamilegacy" repository. New tags will continue to be synced there until August 28th. After that date, "bitnamilegacy" will no longer receive updates, and images in the mainline "bitnami" repository will begin to be removed over a period that may take up to two weeks.
Once the cleanup is complete, the mainline "bitnami" repository on DockerHub will contain only a limited subset of Bitnami Secure Images (at this moment available at "bitnamisecure"). These are hardened, security-enhanced containers intended for development or trial use, providing a preview of the full feature set available in the paid offering.
The source code for Bitnami containers and Helm charts remains publicly available on GitHub and continues to be licensed under Apache 2.
What’s changing is that Bitnami will no longer publish the full catalog of container images to DockerHub. If you need any image, you can still build/package it yourself from the open-source GitHub repositories.
What about the bitnami:minideb base image?
Or the stacksmith files necessary to build certain images?
Without access to these resources, it will not be possible to rebuild the images, will it?
Projects like Sealed Secrets and minideb remain unaffected by these changes. Container images for both projects will continue to be released on Docker Hub (docker.io/bitnami) as usual, without any modifications.
The source code will continue to be available for containers, allowing you to build them from source and future versions as well. The Stacksmith tarballs will also remain available.
The planned action is to stop providing the already built containers on Docker Hub.
Check out the all-new Tanzu OSS Health Assessment tool!
You can instantly get a comprehensive view of your OSS dependencies, potential risks from misconfigurations and vulnerabilities using our tool.
We've just added a new page to the Tanzu Application Catalog documentation detailing the various security frameworks and best practices applied within TAC.
On this page, you'll find information about essential frameworks like CIS, DISA, VEX, STIG, SLSA, and more.
Pipeless is a user-friendly, open-source multimedia framework that prioritizes AI integration. With Pipeless, you can swiftly create and launch applications for audio and video manipulation, enabling to focus on coding rather than the complexities of constructing and managing processing pipelines
Using Bitnami Secure Images: You pull a versioned PostgreSQL image built on a minimal-attack-surface OS (Photon). When a CVE is disclosed or a new upstream version is released, Bitnami’s automation takes care of everything: a new container image (and Helm chart, if applicable) is built, tested, and published to your registry within hours. All you need to do is update to the latest version; no manual CVE monitoring, triage, or patching required.