containers

ami/containers/commit/7651d48119a1f3f... but they must have a very interesting interpretation of what available means then.

that needs it due to their 11 release having compatibility issues with MySQL drivers; as well as PostgreSQL) * key value stores (Redis) * document stores (MongoDB) * message queues (RabbitMQ and NATS) * S3 compatible blob stores (MinIO and SeaweedFS) * utility containers (like Trivy) (either that, or I'll need to build them myself if the Dockerfiles remain available) I'll stay away from Broadcom as much as possible. Edit: > Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license. Hmmm: https://github.com/bitnami/containers/tree/main/bitnami/mari... and https://github.com/bitnami/containers/commit/7651d48119a1f3f...

g.kronis.dev/everything%20is%20broken/bitnami-mar... (title is tongue in cheek, but in short, the official MariaDB image uses "/var/lib/mysql" and Bitnami MariaDB image uses "/bitnami/mariadb" for persistence; that tripped me up because I glanced over it, as the environment variables were the same)

er scan on bitnami/redis returns a long scary list, including: Low severity vulnerability found in coreutils/coreutils Description: Race Condition Info: https://snyk.io/vuln/SNYK-DEBIAN11-COREUTILS-527269 Introduced through: coreutils/coreutils@8.32-4+b1 From: coreutils/coreutils@8.32-4+b1 The docker scan output on rapidfort/redis is empty, so great, we have no vulnerabilities, right? Tested rapidfort/redis for known vulnerabilities, no vulnerable paths found. This particular CVE is present in chown and chgrp, according to Synk's info link. The same version of chown that sync thinks is vulnerable in bitnami/redis is also present in the rapidfort image: docker run --entrypoint=/bin/chown rapidfort/redis --version chown (GNU coreutils) 8.32 docker run --entrypoint=/bin/chown bitnami/redis --version chown (GNU coreutils) 8.32 In this particular case, it looks like the original "vulnerability" is a false positive, but that doesn't change the wider point -- by trying to clean up an image by removing files, it's really easy to remove whatever signatures a CVE scanner is looking for without actually removing the vulnerable code. Here, it looks like you removed /var/lib/dpkg/info/coreutils*, so Synk doesn't think coreutils is installed, but some of the binaries are still present. In my mind, false negatives are far scarier than false positives. Finally, publishing an image modified like this without further cleanup is being a poor community participant. For example, Redis is distributed under the 3-clause BSD license, requiring the license conditions to be distributed alongside any binary distribution. Your image removes all of the license files, and your Dockerhub page simply says "free to use and has no license limitations". You're quite likely violating Redis' license, and that of other software still present in the image. You've also left Bitnami's welcome banner in place: docker run rapidfort/redis redis 12:06:41.40 redis 12:06:41.43 Welcome to the Bitnami redis container redis 12:06:41.44 Subscribe to project updates by watching https://github.com/bitnami/containers redis 12:06:41.46 Submit issues and feature requests at https://github.com/bitnami/containers/issues If a user does encounter an issue with your modified image, you're directing the support burden to Bitnami, who will then have to spend time in triage determining that a modified image was in use and that their code may not actually be at fault. I think trying to reduce attack surface by removing unnecessary parts of an image is a noble goal, but I don't think a mostly-automated approach is a safe way to do so. I would much prefer to see the output of the instrumented run being used by a human to guide slimming down a Dockerfile manually, which would produce safer images without the risks of automated post-processing.