El pipeline que compila y despliega su software tiene más privilegios que la mayoría de los administradores. Lee el código fuente, lleva las claves de firma y las credenciales de la nube y escribe en producción. Además, está formado por acciones, plugins y paquetes de terceros que cambian sin previo aviso.
Probamos este camino como lo haría un atacante: qué puede hacer un colaborador con permisos mínimos, a qué puede llegar una dependencia o un pull request malicioso y si el artefacto que se despliega es, de forma demostrable, el que se revisó.
01Alcance
Qué ponemos a prueba
Control de código fuente: protección de ramas, reglas de revisión, permisos, tokens de acceso
Definiciones de pipelines: inyección a través de entradas no fiables, disparadores inseguros, flujos de pull requests
Runners: aislamiento, estado que persiste entre trabajos, alcance de red, riesgos de los runners autoalojados
Secretos: alcance, exposición en los registros, credenciales de larga duración frente a federación de corta duración
Acciones, plugins y plantillas de terceros: fijación de versiones y procedencia
Dependencias: confusión de dependencias, typosquatting, archivos de bloqueo de versiones, scripts de instalación
Artefactos y registros: firma, procedencia, control de acceso
Despliegue: separación de funciones, aprobaciones, infraestructura como código
02Enfoque
Cómo se realiza el trabajo
01
Mapeo
Trazamos el camino que va de un commit a producción y enumeramos los sistemas, las identidades y los secretos que hay a lo largo de él.
02
Revisión de la configuración
Los repositorios, los pipelines y los registros se revisan frente al OWASP Top 10 CI/CD Security Risks y los requisitos de SLSA.
03
Simulación de ataques
Desde la posición de un colaborador externo, de un desarrollador interno y de una dependencia comprometida intentamos llegar a los secretos y alterar lo que se compila. El trabajo se hace en forks y proyectos de prueba siempre que eso baste para demostrarlo.
04
Plan de refuerzo
Los cambios se ordenan según las rutas de ataque que cierran. Cada uno incluye la configuración que lo implementa.
Clase de debilidad que hay detrás de cada hallazgo.
The MITRE Corporation
06Preguntas
Preguntas sobre este servicio
¿Van a ejecutar código malicioso en nuestros pipelines?
Ejecutamos código de demostración inofensivo que muestra a qué se podría llegar, por ejemplo, el nombre de un secreto y no su valor. Los pipelines de producción solo se tocan cuando las reglas de enfrentamiento lo permiten; la mayoría de las rutas se demuestran en un proyecto de prueba con la misma configuración.
Usamos un servicio de CI gestionado. ¿No se ocupa el proveedor de la seguridad?
El proveedor protege la plataforma. Lo que usted pone en ella es suyo: permisos, disparadores, secretos y componentes de terceros. Ahí es donde tienen éxito los ataques a los pipelines.
¿Incluye una lista de materiales de software?
Verificamos que la lista de materiales que genera su compilación está completa y corresponde al artefacto. Generarla y mantenerla forma parte de su compilación; le recomendamos cómo hacerlo.
Evaluación de entornos AWS, Azure, Google Cloud y Kubernetes: identidades, exposición de red, almacenes de datos y rutas desde un primer punto de apoyo hasta el control total.