Ya tienes fmt y validate cazando errores básicos. Pero esos comandos comprueban que el código sea correcto, no que sea seguro. Un código perfectamente válido puede crear una infraestructura peligrosa: un bucket S3 abierto al mundo, una base de datos sin cifrar, un Security Group con SSH expuesto. Para detectar esto existe el análisis de seguridad estático, con herramientas como Checkov y tfsec.

validate (subcapítulo 21.1) te diría que este código está «bien»:

Sintácticamente es correcto. Pero estás creando un bucket con datos confidenciales abierto a internet (recuerda el peligro del subcapítulo 5.4). validate no detecta esto, porque no es un error de código: es un error de seguridad. Necesitas algo que conozca las buenas prácticas y te avise.

El análisis estático examina tu código sin ejecutarlo (sin crear nada en AWS) y lo compara con una base de reglas de seguridad y buenas prácticas. Si encuentra una configuración peligrosa, te avisa señalando exactamente qué está mal y por qué.

Analogía: es como un inspector de seguridad que revisa los planos de un edificio antes de construirlo. No espera a que el edificio esté hecho para descubrir que falta una salida de incendios: lo detecta en el plano y te obliga a corregirlo antes. El análisis estático revisa los «planos» (tu código) y caza los problemas de seguridad antes de desplegar.

Hay varias herramientas para esto; las dos más conocidas en el mundo Terraform son:

Checkov (de la empresa Prisma/Bridgecrew) es una herramienta muy popular y completa. Trae cientos de reglas predefinidas que comprueban buenas prácticas de seguridad y cumplimiento en AWS (y otras nubes). Detecta cosas como buckets públicos, recursos sin cifrar, puertos abiertos peligrosos, falta de logs, etc.

tfsec es otra herramienta muy usada, centrada específicamente en Terraform y enfocada en seguridad. Es rápida y fácil de integrar. (Conviene saber que tfsec se ha ido integrando con Trivy, otra herramienta del mismo ámbito; el ecosistema evoluciona, pero la idea es la misma.)

Ambas hacen un trabajo parecido: analizan tu código y te listan los problemas de seguridad encontrados. Muchos equipos usan una u otra (o ambas).

Estas herramientas cazan justamente los errores de seguridad que hemos ido mencionando a lo largo del libro:

Es como tener un experto en seguridad revisando cada cambio, que nunca se cansa ni se distrae, aplicando consistentemente cientos de reglas que una persona no podría recordar todas.

Igual que fmt y validate (subcapítulo 21.1), estas herramientas se ejecutan en CI, automáticamente, en cada Pull Request:

Así, ningún cambio inseguro puede llegar a producción sin que alguien lo apruebe conscientemente. Si un desarrollador, sin querer, escribe un bucket público, el CI lo detecta y bloquea el PR. Esto es «shift left»: detectar los problemas de seguridad lo más temprano posible (en el código), no cuando ya están en producción y un atacante los encuentra antes que tú.

Ejemplo del mundo real: un desarrollador, con prisa, configura una base de datos sin cifrado para una prueba y, sin darse cuenta, ese código acaba en un PR hacia producción. El CI ejecuta Checkov, que detecta «base de datos RDS sin cifrado en reposo» y bloquea el PR con un mensaje claro. El desarrollador añade el cifrado, vuelve a subir, y ahora sí pasa. El fallo de seguridad nunca llegó a producción, y todo de forma automática.

A veces estas herramientas marcan algo que, en tu caso concreto, es intencionado y aceptable (por ejemplo, un bucket que debe ser público porque sirve una web estática, subcapítulo 5.5). Para esos casos, puedes excluir reglas concretas de forma justificada (con anotaciones en el código o en la configuración de la herramienta). Pero hazlo conscientemente y documentándolo, no para silenciar avisos molestos sin pensar: cada excepción debe tener una razón clara.

• fmt y validate comprueban que el código sea correcto, pero no que sea seguro: un código válido puede crear infraestructura peligrosa (buckets públicos, BD sin cifrar, SSH abierto).
• El análisis estático de seguridad examina tu código sin ejecutarlo y lo compara con cientos de reglas de buenas prácticas, avisando de las configuraciones peligrosas. Como un inspector que revisa los planos antes de construir.
• Las herramientas principales son Checkov (muy completa, multi-nube) y tfsec (centrada en Terraform, ahora ligada a Trivy). Hacen un trabajo similar.
• Se integran en CI para bloquear automáticamente los cambios inseguros en cada PR: es el principio «shift left» (cazar los problemas lo antes posible).
• Gestiona los falsos positivos excluyendo reglas concretas de forma justificada y documentada, no silenciando avisos a la ligera.

En el siguiente subcapítulo daremos el salto a las pruebas más completas: los tests de integración con Terratest, que crean infraestructura real y verifican que funciona.