Buildpacks: el control de seguridad de contenedores se mueve a la plataforma

El parcheo de imágenes base falla menos por falta de estándares y escáneres que por dispersión: cada servicio trae su Dockerfile, su etiqueta de imagen base, su ciclo de reconstrucción y su propia definición de lo que es seguro. La tesis que se defiende para entornos grandes es mover esas decisiones fuera del repositorio de aplicación y llevarlas a un camino de build gobernado por el equipo de plataforma, con los buildpacks como pieza central.

El parche que no llega

El caso se repite. Se corrige una vulnerabilidad crítica en la imagen base aprobada por la organización. En teoría, esa imagen se detecta de forma centralizada, se reconstruye, se prueba, se publica y se propaga a cada aplicación afectada. Una semana después, hay cargas de producción corriendo todavía sobre la base vulnerable. Los motivos son de operación diaria: Dockerfiles con etiquetas, versiones de Linux y runtimes distintos, así que cuesta saber qué servicio está afectado; imágenes que arrancan de una base parcheada y reinstalan dependencias vulnerables porque alguien las mete a mano; equipos que solo reconstruyen cuando tocan el código de la aplicación, de modo que un servicio sin cambios recientes puede llevar meses con una imagen vieja; y ausencia de inventario, SBOM y metadatos desplegados para medir si el parche llegó.

Un control de seguridad no vale por sí solo. Tiene que aplicarse siempre igual, verse en lo que está corriendo y seguir siendo mantenible cuando cambian las imágenes, las dependencias y las vulnerabilidades. Ahí se encalla la mayoría.

Buildpacks: mover la decisión, no el Dockerfile

Conviene decirlo: el Dockerfile no es el enemigo. Uno bien escrito produce una imagen mínima y endurecida. El problema es pedirle a cada desarrollador que tenga el criterio de un especialista en contenedores para hacerlo igual en cientos de repositorios.

Los buildpacks atacan eso. Cloud Native Buildpacks, proyecto graduado de la CNCF, convierte código fuente en una imagen OCI lista para producción sin Dockerfile: detecta el tipo de aplicación, elige los buildpacks necesarios y aporta runtime y dependencias. Para seguridad, el valor no está en quitar el fichero, sino en tener un punto donde imponer controles: qué builders se usan en CI, qué imagen de runtime, cómo se genera el SBOM y qué metadatos acompañan al artefacto. La documentación sobre builders de confianza describe cómo fijar esa cadena. El desarrollador sigue siendo dueño de su código y sus dependencias; producir una imagen conforme pasa a ser trabajo de plataforma.

Lo que no arregla: nadie obliga a reconstruir. Si el pipeline no se dispara cuando cambia la imagen base, el buildpack tampoco salva. Y la responsabilidad se concentra: el equipo de plataforma pasa a mantener builders, imágenes base y políticas para todos, lo que es una ventaja y también un punto único de fallo si esa función se descuida.

La discusión de fondo es organizativa más que técnica: si la plataforma asume ese trabajo o se queda a medias, y si los builders acaban tratándose como un artefacto versionado y auditado igual que cualquier otra dependencia.