El riesgo de la cadena de suministro de la infraestructura como código surge cuando las definiciones de infraestructura (módulos de Terraform, charts de Helm, roles de Ansible, operadores de Kubernetes) se obtienen de registros públicos o repositorios comunitarios y se incorporan a la automatización de la infraestructura de una organización sin el mismo escrutinio de seguridad que se aplicaría a las dependencias del código de las aplicaciones. Terraform Registry, Helm Hub, Ansible Galaxy y otros repositorios comunitarios similares son el equivalente en automatización de infraestructura de npm o PyPI: grandes colecciones de módulos aportados por la comunidad que con frecuencia se usan tal cual, sin revisar sus implicaciones de seguridad ni su estado de mantenimiento.
El problema de la confianza en los módulos ascendentes es la falla específica de la cadena de suministro de IaC. Cuando el código de infraestructura llama a un módulo de terceros (por ejemplo, terraform-aws-modules/security-group), el código del módulo se ejecuta con las credenciales de la automatización de la infraestructura y determina la configuración de la infraestructura resultante. Un módulo mal configurado o desactualizado produce infraestructura mal configurada. Un módulo malicioso, el equivalente en IaC de un paquete con typosquatting, podría producir infraestructura diseñada específicamente para ser explotable o para exfiltrar datos de configuración. El ingeniero de infraestructura que revisa su propio código de Terraform no está revisando el módulo ascendente al que llama su código.
Por qué es importante
El riesgo de la cadena de suministro de IaC es relevante para TPRM porque los proveedores que usan automatización de infraestructura, cada vez más la norma en entornos nativos de la nube, construyen su infraestructura sobre cadenas de dependencias que incluyen módulos de registros públicos. La seguridad de esa infraestructura depende no solo de las prácticas de revisión del código de infraestructura del propio proveedor, sino también de la seguridad y la vigencia de los módulos ascendentes de los que depende su automatización. Un proveedor con procesos rigurosos de revisión de IaC que usa módulos de terceros desactualizados está construyendo sobre una base que su revisión no examinó.
- Seguridad de IaC evaluada sin revisar los módulos ascendentes
- Vigencia de los módulos de terceros sin seguimiento: módulos desactualizados con configuraciones obsoletas
- Origen y responsables del mantenimiento de los módulos sin evaluar: módulos comunitarios usados tal cual
- Sin visibilidad de la cadena de suministro de IaC: módulos tratados como confiables sin verificación
- Configuraciones erróneas de la infraestructura provenientes de módulos fuera del alcance de la seguridad de IaC
Cómo se ve una buena práctica
Los programas maduros de cadena de suministro de IaC fijan las versiones de los módulos, analizan los módulos de terceros en busca de problemas de seguridad con herramientas de análisis de IaC, evalúan el estado y la vigencia del mantenimiento de los módulos y aplican a los módulos de infraestructura el mismo escrutinio de seguridad de la cadena de suministro que se aplica a las dependencias de las aplicaciones.
- Fijación de versiones de módulos: versiones específicas en lugar de referencias flotantes
- Análisis de seguridad de IaC que cubre el contenido de los módulos de terceros
- Evaluación del estado del mantenimiento de los módulos: vigencia y actividad de mantenimiento
- Revisión del código de los módulos recién adoptados
- Registro interno de módulos: módulos verificados disponibles internamente en lugar del consumo directo desde el registro
Herramientas
Seguridad de IaC: Checkov, tfsec, KICS para el análisis de seguridad de la infraestructura como código, incluidos los módulos de terceros
Las herramientas de análisis de seguridad de IaC analizan Terraform, CloudFormation, manifiestos de Kubernetes y otros formatos de IaC en busca de configuraciones de seguridad erróneas, incluso en los módulos de terceros que se incluyen como fuentes. Checkov y tfsec pueden analizar el contenido expandido de los módulos para identificar configuraciones erróneas en el código de los módulos ascendentes. Para los profesionales de TPRM, preguntar si los proveedores ejecutan análisis de seguridad de IaC sobre la definición completa de su infraestructura, incluido el contenido de los módulos de terceros, constituye una pregunta específica sobre la cadena de suministro de IaC.
Desafíos de gobernanza
El desafío de gobernanza del riesgo de la cadena de suministro de IaC es la complejidad de actualizar los módulos. Al igual que las dependencias de las aplicaciones, las actualizaciones de módulos de IaC pueden romper la infraestructura: una actualización de módulo que cambia las convenciones de nomenclatura de recursos puede exigir reemplazar la infraestructura en lugar de actualizarla. La solución de gobernanza es fijar las versiones de los módulos con una revisión de seguridad periódica de cada versión fijada, en lugar de usar referencias flotantes que incorporan actualizaciones automáticamente.
- Fijar las versiones de los módulos en la IaC: referencias a versiones específicas
- Ejecutar herramientas de análisis de IaC sobre la definición completa de la infraestructura, incluido el contenido de los módulos
- Evaluar la vigencia del mantenimiento de todos los módulos usados en producción
- Mantener un registro interno de módulos verificados para entornos de alta seguridad
- Incluir la cadena de suministro de módulos de IaC en la evaluación de seguridad de la infraestructura de los proveedores
Si usted forma parte de un equipo pequeño
Ejecute Checkov o tfsec sobre su código de Terraform o el de su proveedor con todo el contenido de los módulos incluido. Estas herramientas pueden analizar el código expandido de los módulos, no solo el envoltorio de Terraform que los llama. Los hallazgos en el contenido de los módulos son el riesgo de la cadena de suministro de IaC que se pasa por alto al revisar solo el código del envoltorio. Pregunte a su proveedor si su análisis de IaC cubre todo el contenido de los módulos o solo su propio código.
- Ejecutar Checkov o tfsec con expansión completa de los módulos sobre el código de IaC
- Revisar los hallazgos del contenido de los módulos de terceros
- Preguntar al proveedor si el análisis de IaC cubre el contenido de los módulos
- Evaluar la fijación de versiones de módulos y la vigencia de su mantenimiento
Qué exigir
Pregunte directamente:
«¿Su análisis de seguridad de la infraestructura como código cubre todo el contenido de los módulos de terceros que usa su automatización, y no solo su propio código? ¿Las referencias a módulos de Terraform están fijadas a versiones específicas con revisiones de seguridad periódicas?»
Evidencia que debe esperar
- Cobertura del análisis de IaC, incluido el contenido de los módulos
- Implementación de la fijación de versiones de módulos
- Evaluación de la vigencia del mantenimiento de los módulos
- Registro interno de módulos verificados o equivalente
A un proveedor que confirma prácticas de seguridad de IaC se le debe preguntar por la cobertura de la cadena de suministro de módulos. El análisis de seguridad de IaC de su propio código confirma el envoltorio. El análisis completo del contenido de los módulos cubre la cadena de suministro.
Cómo demostrarlo
- Análisis de IaC con cobertura completa de los módulos
- Registros de fijación de versiones de módulos
- Evaluación del estado del mantenimiento de los módulos
- Riesgo de la cadena de suministro de módulos de IaC en la evaluación de proveedores
Conclusión clave
IaC: revisado. Módulo de Terraform de terceros: 14 meses desactualizado, puertos de administración abiertos a 0.0.0.0/0. Revisión del código de infraestructura: completa. Revisión del código de los módulos: no realizada. La cadena de suministro de IaC tiene el mismo modelo de amenazas que la cadena de suministro de dependencias de aplicaciones: código de terceros ejecutado con credenciales de nivel de producción que configura o despliega infraestructura de producción. La fijación de versiones de los módulos controla qué versión se usa. El análisis de IaC con expansión completa de los módulos identifica qué hace esa versión. La evaluación del estado del mantenimiento identifica si es probable que esa versión se actualice si se encuentra una vulnerabilidad.