«Shift left» se ha convertido en uno de los principios más ampliamente adoptados en DevSecOps. La idea es simple y atractiva: trasladar la seguridad a las fases más tempranas del ciclo de vida del desarrollo de software para detectar problemas antes, reducir costes y mejorar los resultados generales de seguridad.
Con el tiempo, «shift left» ha evolucionado de un concepto útil a un dogma casi incuestionable. El escaneo de seguridad, las pruebas y las verificaciones de políticas se adelantan lo máximo posible, a menudo al IDE del desarrollador o a las primeras etapas de CI.
Sin embargo, a pesar de años de «shift left,» los ataques a la cadena de suministro de software siguen teniendo éxito. Los sistemas de build se comprometen. Se distribuyen dependencias maliciosas. Se publican releases con puertas traseras a través de pipelines de confianza.
El problema no es que «shift left» sea incorrecto. El problema es que shift left por sí solo es insuficiente, y en muchos casos, fracasa precisamente porque ignora la seguridad de los propios pipelines CI/CD.
Este artículo explica dónde falla el modelo «shift left», por qué no aborda el compromiso de los pipelines, y cómo DevSecOps debe evolucionar para incluir la seguridad explícita de los pipelines.
El origen de «shift left»
El concepto de «shift left» surgió como respuesta a los fallos de seguridad en etapas tardías.
Históricamente, las revisiones de seguridad se realizaban al final del ciclo de vida del desarrollo: pruebas de penetración antes del lanzamiento, puertas de aprobación de seguridad y remediación de último momento de problemas críticos.
Este enfoque generaba problemas predecibles:
- Los hallazgos de seguridad llegaban demasiado tarde
- Las correcciones eran costosas y disruptivas
- Los desarrolladores veían la seguridad como un bloqueador externo
«Shift left» pretendía resolver esto introduciendo la seguridad más temprano:
- Análisis estático durante el desarrollo
- Escaneo de dependencias en tiempo de build
- Pruebas automatizadas en CI
Como principio, fue una mejora clara. La retroalimentación temprana es casi siempre mejor que la retroalimentación tardía.
Sin embargo, el modelo asumía algo que ya no es cierto:
Si el código es seguro desde el principio, el software entregado será seguro.
Qué asegura realmente «shift left»
En la práctica, «shift left» se centra en un conjunto específico de riesgos:
- Vulnerabilidades en el código de la aplicación
- Problemas conocidos en las dependencias
- Errores de configuración detectables mediante análisis estático
Estos controles responden a preguntas importantes:
- ¿Contiene este código vulnerabilidades obvias?
- ¿Estamos usando bibliotecas con vulnerabilidades conocidas?
- ¿Viola esta configuración políticas conocidas?
Lo que no responden es igualmente importante:
¿Podemos confiar en el sistema que construye y entrega este software?
Los controles shift-left se centran en qué se escribe. La seguridad de los pipelines se centra en cómo se transforma, empaqueta y distribuye.
Por qué «shift left» no cubre el pipeline
Los pipelines CI/CD se sitúan aguas abajo de la mayoría de las actividades shift-left.
Para cuando un pipeline se ejecuta, el código ya ha:
- Pasado el análisis estático
- Pasado las verificaciones de dependencias
- Pasado las pruebas unitarias y de integración
Sin embargo, es precisamente aquí donde ocurren muchos compromisos en el mundo real.
La razón es estructural: los controles shift-left asumen que el pipeline en sí es confiable.
Esa suposición a menudo es falsa.
Los pipelines ejecutan entradas no confiables por diseño
Los pipelines CI/CD ejecutan rutinariamente:
- Código de pull requests
- Scripts de build
- Acciones y plugins de terceros
- Dependencias descargadas en tiempo de build
Incluso si el código fuente es «seguro,» el pipeline está expuesto a comportamientos no confiables durante la ejecución.
El escaneo shift-left no protege contra comportamientos maliciosos introducidos en tiempo de build o empaquetado.
Los pipelines operan con privilegios elevados
Los pipelines a menudo tienen acceso a:
- Secrets y credenciales
- Repositorios de artefactos
- Claves de firma
- Permisos de despliegue
Si los atacantes comprometen el pipeline, no necesitan explotar los sistemas de producción en absoluto.
Simplemente pueden producir artefactos «legítimos» en los que los sistemas posteriores confían implícitamente.
Fallos reales de la mentalidad «shift left»
Los principales incidentes de cadena de suministro no ocurrieron porque los equipos no escanearon el código a tiempo.
Ocurrieron porque los atacantes explotaron mecanismos de build y entrega de confianza.
El compromiso del pipeline elude los controles a nivel de código
Cuando los atacantes inyectan comportamiento malicioso en:
- Pasos de build
- Herramientas de CI
- Procesos de resolución de dependencias
los artefactos resultantes pueden pasar todas las verificaciones shift-left.
Desde la perspectiva del pipeline, todo parece normal.
Desde la perspectiva de producción, el artefacto es legítimo.
Los controles shift-left no modelan los límites de confianza
Las herramientas shift-left se centran en detectar problemas conocidos.
No modelan:
- Quién controla la ejecución del pipeline
- Dónde se otorga la confianza
- Cómo los artefactos obtienen legitimidad
Por eso los atacantes apuntan a los pipelines: explotan relaciones de confianza, no vulnerabilidades.
Dónde deben aplicarse los controles de seguridad del pipeline
Si los controles shift-left son insuficientes, ¿dónde deben aplicarse los controles de seguridad del pipeline?
La respuesta no es «aún más temprano.»
La seguridad del pipeline requiere controles en transiciones de confianza específicas.
Antes de la ejecución: controlar las entradas no confiables
No todos los triggers del pipeline deben tratarse por igual.
Los controles deben distinguir entre:
- Ramas de confianza
- Pull requests no confiables
- Contribuciones externas
Los secrets, las acciones privilegiadas y los pasos de despliegue deben estar controlados en consecuencia.
Durante la ejecución: aislar los runners
Los runners son donde la confianza es más frágil.
Los controles efectivos incluyen:
- Runners efímeros
- Aislamiento fuerte
- Acceso de red mínimo
- Identidades de mínimo privilegio
El escaneo shift-left no protege contra el compromiso de runners. El aislamiento sí.
Después de la ejecución: verificar los artefactos
El control de pipeline más crítico es a menudo el último.
Antes del despliegue, los sistemas deben verificar:
- Quién construyó el artefacto
- Cómo fue construido
- Si ha sido modificado
Sin verificación, producción confía implícitamente en el pipeline.
Replanteando DevSecOps más allá de «shift left»
DevSecOps necesita un modelo mental más completo.
La seguridad debe ser:
- Temprana, para detectar defectos de forma económica
- Continua, para adaptarse al cambio
- Aplicable, para prevenir compromisos silenciosos
La seguridad del pipeline aborda el tercer punto.
Introduce garantías aplicables que el escaneo por sí solo no puede proporcionar.
Un modelo más preciso: asegurar el ciclo de vida de la confianza
En lugar de «shift left,» un mejor enfoque es:
Asegurar el ciclo de vida de la confianza.
Esto significa:
- Comprender dónde entra la confianza en el sistema
- Controlar cómo se propaga
- Verificarla antes de que llegue a producción
Los controles shift-left siguen siendo valiosos, pero solo como parte de un sistema más amplio que incluya la seguridad del pipeline.
Conclusión
«Shift left» no es incorrecto, pero es incompleto.
Mejora la calidad del código y detecta defectos tempranamente, pero no protege contra el compromiso de los pipelines ni contra los ataques a la cadena de suministro.
Los pipelines CI/CD son donde la confianza se transforma, amplifica y finalmente se otorga.
Ignorar la seguridad del pipeline significa confiar en los mismos sistemas que los atacantes apuntan cada vez más.
DevSecOps debe evolucionar más allá de los eslóganes y centrarse en la ingeniería de la confianza de extremo a extremo.
Sin seguridad en los pipelines CI/CD, «shift left» no es una estrategia, es una suposición.
