Hablemos claro y sin pelos en la lengua de esa gran mentira que se repite en las empresas: la "seguridad de la cadena de suministro de software". Se llenan la boca con políticas y memorandos, presumiendo de que "mitigan los riesgos activamente". ¡Puro cuento chino! Esa idea de que las organizaciones se toman la seguridad en serio es el autoengaño más peligroso de nuestra industria.

La prueba no está en sus papeles, está en sus acciones. Predican sobre confianza cero, pero a la primera de cambio, el desarrollador con la fecha de entrega pisándole los talones ejecuta un docker pull a la imagen más popular que encuentra. ¿Y por qué? Porque tiene millones de descargas. ¡Como si la popularidad fuera un protocolo de seguridad! Confiar en un contador de descargas es como decidir que un restaurante es bueno porque la cola es larga, mientras ignoras las ratas que bailan joropo en la cocina. Están apostando el futuro de su empresa a la sabiduría de una multitud que, como ustedes, solo busca el camino más fácil. Dejen de mentirse. No están asegurando nada, están tercerizando su seguridad a la tiranía de la conveniencia. Por eso necesitamos imágenes docker confiables, no simplemente populares.

El Cáncer de la Popularidad y la Pereza

El problema fundamental es que Docker Hub y otras alternativas a Docker Hub son como un mercado público gigante. Hay puestos excelentes y hay otros que venden veneno. La principal vulnerabilidad que encontramos en las imágenes públicas es la desactualización. Están repletas de paquetes y librerías con vulnerabilidades conocidas (CVEs) que nadie se ha molestado en parchear. Construir sobre una de estas es como levantar una casa con cabillas oxidadas.

Peor aún, muchas imágenes docker oficiales se construyen compilando el software desde el código fuente dentro de la propia imagen. Esto no solo las hace innecesariamente pesadas, sino que deja el sistema de paquetes de la imagen en un estado inconsistente y propenso a errores difíciles de depurar. La seguridad no es solo la ausencia de vulnerabilidades, es también la robustez y la previsibilidad. Como lo explica la guía de seguridad de imágenes de contenedores de Google Cloud, una imagen segura es aquella que es mínima y predecible.

¿Entonces, qué nos importa? Confianza, Consistencia y Pruebas

Una imagen segura no es un accidente, es el resultado de un diseño deliberado. Se considera "segura" cuando tiene la mínima superficie de ataque posible: construida sobre una base de confianza, con solo los binarios y librerías esenciales, y sin vulnerabilidades conocidas. Para entender más a fondo, la guía de seguridad de Docker de OWASP es una lectura obligatoria.

Pero la confianza va más allá. ¿Cómo verificamos la autenticidad de una imagen? Mecanismos como Docker Content Trust y la verificación de hashes SHA256 son fundamentales para asegurarnos de que la imagen que usamos no ha sido alterada. Es el equivalente digital a un sello de seguridad inviolable.

Harto de este panorama, de la necesidad de tener imágenes para mis proyectos que no fueran ni un fósil de Debian Stable ni una ruleta rusa de Ubuntu, decidí crear una solución. Así nació mi proyecto personal, Dockershelf.

Harto de la misma historia, nació Dockershelf

Dockershelf no es otro montón de recetas de Docker. Nació de la frustración y la previsión. Empecé a experimentar con la contenerización para automatizar despliegues allá por 2013, mucho antes de que fuera la norma. Para 2015, antes de que las imágenes Alpine se hicieran populares, ya estaba desarrollando mi propia colección de imágenes ligeras, automatizadas y probadas porque estaba harto de la necesidad de tener imágenes para mis proyectos que no fueran ni un fósil de Debian Stable ni una ruleta rusa de Ubuntu. Necesitaba consistencia, seguridad y velocidad.

Ese experimento personal se convirtió en lo que hoy es Dockershelf: una colección curada de imágenes Docker que yo mismo uso y mantengo. Empezó con dockershelf/debian y dockershelf/python para resolver mis propias necesidades, pero rápidamente creció para incluir dockershelf/node, dockershelf/go y hasta dockershelf/latex. No es un reemplazo de Docker Hub, sino más bien un análogo a un repositorio docker privado en términos de calidad y confianza, pero abierto a toda la comunidad.

Lo que hace a Dockershelf diferente (y mejor, pa' que negarlo)

Este proyecto no busca reinventar la rueda, sino ofrecer una rueda que no se te va a espichar a mitad de camino. Se diferencia por sus imágenes pequeñas y ligeras; las de Python y Node, por ejemplo, son hasta 4 veces más pequeñas que las oficiales, lo que reduce los tiempos de descarga y la superficie de ataque. Además, cada imagen es probada hasta el cansancio con una batería de tests de integración antes de publicarse. El proceso, automatizado con GitHub Actions, se ejecuta semanalmente para aplicar las últimas actualizaciones y escanea las imágenes con herramientas como Trivy para asegurar que estén limpias. Finalmente, la consistencia está por encima de todo: Dockershelf utiliza el sistema de paquetes de Debian (apt) para las dependencias, garantizando que no haya conflictos ni sistemas "rotos" y que las actualizaciones sean predecibles. Se acabaron las sorpresas.

Dockershelf es mi respuesta a la complacencia. Es la prueba de que se pueden tener imágenes que cumplan con altos estándares de imágenes OCI sin sacrificar la agilidad.

Dejen la Flojera y Únanse a la Causa

La seguridad de nuestra cadena de suministro de software es nuestra responsabilidad, no de un contador de descargas anónimo. Dejar de usar imágenes a ciegas es el primer paso. Proyectos como Dockershelf ofrecen una alternativa construida sobre los principios de transparencia, pruebas y consistencia.

Así que les pregunto, gente: ¿van a seguir confiando ciegamente en la popularidad o van a empezar a auditar y exigir más de las herramientas que usan todos los días?

¡Échenle un ojo a Dockershelf en GitHub y cuéntenme qué opinan en los comentarios