Shift Left fracasó: la seguridad debe moverse hacia abajo en la pila para lograr velocidad sin sacrificar control

Durante años hemos repetido un mantra: hay que "mover la seguridad hacia la izquierda" y pedir a los desarrolladores que asuman más responsabilidades de seguridad mientras escriben y prueban código. La idea era seductora: arreglar problemas temprano sale más barato, y si los equipos de desarrollo incorporan comprobaciones desde el principio todo irá más rápido y más seguro. Sin embargo, la realidad demuestra que esa apuesta por el "shift left" no resolvió el problema central. En muchos entornos la tensión entre velocidad y seguridad se ha intensificado y, sobre todo, los desarrolladores han acabado soportando una carga cognitiva insostenible.

El problema no es la pereza de los desarrolladores; es el modelo de incentivos y la presión por entregar rápido. Cuando el negocio exige funcionalidades, plazos cortos y resultados medibles, lo que prima es la entrega. Si una verificación de seguridad tarda horas y bloquea la build, la presión para sortearla aparece de forma natural. En ese caldo de cultivo, soluciones pragmáticas como tirar de imágenes públicas desde registries facilitan avanzar, pero también introducen riesgos difíciles de controlar.

Un buen ejemplo de lo que puede fallar viene del propio análisis de la industria. El equipo de investigación de Qualys examinó decenas de miles de imágenes de contenedores públicas y encontró resultados alarmantes: de una muestra muy amplia, miles de imágenes presentaban comportamiento malicioso o contenido sensible incrustado. Entre esos hallazgos había criptominería integrada en una gran parte de las muestras maliciosas y secretos (claves de AWS, tokens de GitHub, credenciales de bases de datos) preservados dentro de las capas de imagen. Puedes leer el informe y los detalles técnicos en el blog de Qualys sobre este estudio aquí.

El error conceptual es tratar los repositorios públicos como bibliotecas curadas y confiables por defecto. Plataformas como Docker Hub, registries de proveedores cloud y otros servicios públicos facilitan la distribución, pero la mera presencia de una imagen en esos espacios no garantiza que sea segura. Descargar una imagen abierta es, en esencia, una decisión de confianza; y esa confianza puede estar mal colocada.

Entonces, ¿qué hacer? La respuesta pasa por mover la seguridad en otra dirección: no más "shift left" exclusivamente sobre el hombro del desarrollador, sino una estrategia que baje responsabilidad y controles hacia la capa de infraestructura y plataforma. En vez de pedir a cada ingeniero que recuerde escanear, endurecer y auditar manualmente, hay que ofrecer caminos seguros que sean simples y rápidos de seguir.

Una pieza clave es la creación de un repositorio interno que actúe como cuarentena de artefactos externos. Todas las imágenes externas deberían pasar por un proxy o un registry interno que inspeccione, firme y apruebe artefactos antes de que entren en los pipelines. Herramientas de gestión de artefactos como Harbor pueden ayudar a construir este tipo de capa intermedia y automatizar políticas de aceptación; ver más en el proyecto de Harbor.

En la práctica también vale la pena definir una "ruta dorada" (golden path) para los desarrolladores: plantillas estándar, imágenes base aprobadas y pipelines oficiales que garantizan seguridad por defecto. Si los equipos siguen ese camino, la seguridad se convierte en algo transparente para ellos. Si alguien necesita salirse del patrón, entonces exige revisiones adicionales y procesos manuales que justifiquen ese riesgo ante el negocio.

Las herramientas de política y control en la infraestructura son parte de la solución. Políticas declarativas aplicadas con módulos de Terraform, composiciones de Crossplane o reglas en Open Policy Agent evitan que ocurran errores humanos repetitivos: por ejemplo, impedir que exista un bucket S3 sin versionado o denegar despliegues con imágenes que no cumplan requisitos mínimos. Open Policy Agent ofrece un marco para codificar este tipo de restricciones y puede integrarse en pipelines y controladores de admisión; consulta Open Policy Agent para más información.

Del mismo modo, la automatización debe abarcar tanto la detección como la respuesta. Los escaneos de contenedores tienen que ejecutarse dentro del CI/CD y los controladores de admisión de Kubernetes deberían impedir que contenedores con vulnerabilidades críticas lleguen al clúster. En tiempo de ejecución, las herramientas no deben limitarse a generar alertas; ante comportamiento malicioso comprobado, el sistema debería ser capaz de aislar y matar cargas comprometidas, e incluso marcar nodos para contención automática. La documentación oficial sobre controladores de admisión en Kubernetes explica cómo funcionan estos mecanismos: Kubernetes admission controllers.

También es inteligente adoptar enfoques que automaticen la corrección: si se detecta una vulnerabilidad en una imagen base, la plataforma puede generar un Pull Request para actualizarla automáticamente y, tras validaciones, promover la versión segura. Este tipo de flujos reduce el tiempo de exposición y aligera la carga sobre equipos que no deben dedicar su tiempo a tareas repetitivas de mantenimiento.

Esto no significa que la seguridad deje de colaborar con el desarrollo; al contrario: requiere una relación más estrecha y proactiva. Seguridad y plataforma deben entender los requisitos del negocio y trabajar para que la entrega segura sea la opción más rápida y económica. Así se evita el conflicto entre cumplir objetivos de negocio y respetar controles de seguridad, porque ambos se alinean en la misma infraestructura.

El cambio cultural también es relevante: dejar de culpar a los desarrolladores por atajos y empezar a diseñar sistemas que prevengan esos atajos. Modelos como DevSecOps siguen siendo válidos, pero su implementación tiene que orientarse hacia la simplificación y la automatización efectiva. Recursos de organismos como OWASP o NIST aportan guías y marcos para entender riesgos en la cadena de suministro de software y cómo mitigarlos; ver por ejemplo el proyecto OWASP SAMM y las publicaciones de NIST sobre seguridad de la cadena de suministro: OWASP SAMM y NIST - Software Supply Chain Security.

La conclusión es clara: si seguimos cargando la responsabilidad sobre los hombros de desarrolladores ya sobrecargados, obtendremos evasiones y exposición. En lugar de eso, necesitamos plataformas que hagan la opción segura también la opción fácil. La seguridad debe "moverse hacia abajo" en la pila, incorporándose en la infraestructura y automatizándose, de modo que el negocio obtenga velocidad sin sacrificar control ni protección. Para quien quiera profundizar en análisis y recomendaciones específicas, el estudio de Qualys es un buen punto de partida y está disponible en su blog técnico aquí, y si se está evaluando soluciones para entornos cloud-native, el informe de Forrester sobre CNAPP es otra referencia útil disponible mediante Qualys.