Módulo 5: Scanning Iac And Dependencies

2. El panorama de escáneres: Trivy, Checkov y `tfsec`, con honestidad de mercado

Descripción

Si buscas "escanear Terraform en busca de errores de seguridad" vas a encontrar, casi siempre, tres nombres: Trivy, Checkov, y tfsec. Esta lección explica qué es cada uno, por qué esta guía usa los primeros dos, y por qué el tercero — a pesar de aparecer en casi todos los tutoriales que vas a encontrar en internet — no se instala nunca por separado en este módulo. No es una omisión. Es una decisión de mercado, verificada, con fecha y fuente.

Conexión con el módulo

La lección 1 estableció que este módulo trata sobre reglas de la comunidad, no propias. Esta lección responde la pregunta obvia que sigue: ¿de qué comunidad, exactamente, vienen esas reglas? Las lecciones 3 a 8 de este módulo instalan y corren dos herramientas concretas — esta lección es la que justifica por qué son esas dos, y no una tercera que quizás ya conocías.


Analogía: dos casas de inspección, y una tercera que se fusionó con la primera

Vuelve a la analogía de los dos inspectores de la lección 1. Ahora imagina que, hace un par de años, existía un tercer inspector independiente, especializado exclusivamente en casas construidas con un tipo de plano específico (Terraform). Ese tercer inspector desarrolló, durante años, una lista de verificación muy buena, específica para ese tipo de plano. Y entonces, en 2024, la empresa que fabricaba el primer inspector compró al tercero, y fusionó toda su lista de verificación dentro de su propio inspector — mismos puntos de revisión, mismos códigos de referencia, ahora bajo una sola marca. El tercer inspector, como entidad independiente, sigue técnicamente disponible, pero nadie contrata una versión que dejó de actualizarse cuando puedes contratar la versión fusionada, que sí sigue creciendo.

Eso es exactamente lo que pasó con tfsec.


Las tres herramientas, una por una

Trivy (aquasecurity/trivy)

Desarrollado por Aqua Security, Trivy empezó como un escáner de vulnerabilidades de imágenes de contenedor y creció hasta cubrir, en un solo binario, escaneo de configuración de infraestructura como código (trivy config), sistema de archivos con detección de secretos (trivy fs), generación de SBOM (Módulo 6 de esta guía), y escaneo de dependencias de software. Es, de las tres herramientas de este panorama, la que ya conoces — la usaste en el Módulo 3, lección 7, para escanear secretos filtrados, y confirmaste entonces que tu versión es 0.74.0.

Checkov (bridgecrewio/checkov)

Desarrollado originalmente por Bridgecrew (adquirida por Palo Alto Networks, la misma empresa detrás de Prisma Cloud), Checkov es un escáner de infraestructura como código escrito en Python, con más de mil políticas integradas y un motor de grafo que entiende relaciones entre recursos — no solo si un recurso individual está mal configurado, sino si la combinación de dos recursos relacionados crea un riesgo que ninguno de los dos, visto por separado, revelaría. Cubre Terraform, CloudFormation, Kubernetes, y varios formatos más.

tfsec (aquasecurity/tfsec)

Desarrollado también por Aqua Security, tfsec fue, durante años, el escáner de Terraform de referencia — rápido, con una biblioteca de reglas específicas para AWS, Azure y GCP, y una sintaxis de salida que muchos otros escáneres terminaron imitando. Y en 2024, Aqua Security tomó una decisión de producto: fusionar el motor completo de tfsec dentro de Trivy, en vez de mantener dos productos separados que hacían, en gran medida, lo mismo.


Ejemplo trabajado: el mismo ID de chequeo, verificado en ambos lados de la fusión

La prueba concreta de que la fusión es real, no solo un anuncio de marketing, está en los identificadores de chequeo. Antes de la fusión, tfsec tenía reglas con IDs como AVD-AWS-0086 (bloqueo de acceso público de S3). Después de la fusión, ese mismo chequeo sigue existiendo dentro de Trivy — lo viste tú mismo en la lección 1 de este módulo, en el adelanto del hallazgo sobre andes-cargo-shipment-docs:

AWS-0086 (HIGH): No public access block so not blocking public acls

Qué esperar (verificado contra la documentación oficial de Trivy y contra la salida real de la herramienta, agosto de 2026): el ID que produce Trivy 0.74.0 en su salida de tabla y JSON es AWS-0086 — la forma corta. La documentación de Trivy y la base de datos pública de vulnerabilidades (avd.aquasec.com/misconfig/aws-0086) siguen usando el linaje de nombre AVD-AWS-XXXX para referirse a la misma familia de reglas heredadas de tfsecAVD es el nombre del catálogo (Aqua Vulnerability Database), no un prefijo que aparezca literal en cada ID de la salida de la CLI. Vas a ver el ID exacto, sin adivinar, en la lección 4.


Por qué esta guía usa Trivy + Checkov, y no tfsec standalone

Tres razones concretas, no una preferencia arbitraria:

Primera: tfsec standalone dejó de recibir reglas nuevas. El último release independiente del proyecto fue v1.28.14, publicado en mayo de 2025. Desde entonces, cualquier atributo de un proveedor de AWS liberado después de mediados de 2025 no tiene cobertura en tfsec standalone — porque nadie está escribiendo reglas nuevas para él. Trivy, en cambio, sigue publicando versiones nuevas (la 0.74.0 que usa esta guía es del 14 de agosto de 2026) con reglas que sí cubren atributos y servicios recientes.

Segunda: instalar tfsec por separado, hoy, sería instalar un motor congelado dentro de un motor que ya lo absorbió y lo sigue actualizando. No hay ninguna ventaja funcional en correr el binario tfsec viejo cuando trivy config ejecuta, literalmente, el mismo motor, con las mismas reglas heredadas, más todo lo que se agregó después. La migración documentada por la propia comunidad es mecánica: donde antes escribías tfsec ., ahora escribes trivy config . — mismos IDs de chequeo, mismo comportamiento, sin que tengas que reescribir nada.

Tercera: Checkov aporta una cobertura que Trivy, por diseño, no tiene — el grafo de dependencias entre recursos. Es la razón por la que esta guía no se conforma con "Trivy es suficiente porque ya absorbió a tfsec" — Checkov, con su motor de grafo, encuentra clases de problemas (como una combinación insegura entre dos recursos relacionados) que un escáner que evalúa cada recurso de forma aislada no puede ver. La lección 5 de este módulo te va a mostrar, con evidencia real, casos concretos donde las dos herramientas no coinciden — y por qué eso es exactamente lo esperado, no un defecto de ninguna de las dos.

   LÍNEA DE TIEMPO DE tfsec Y SU FUSIÓN EN TRIVY

   2019 ─────────────────────────────► 2024 ──────► 2025 ──────► 2026 (hoy)
   tfsec nace como escáner             Aqua funde    último       Trivy 0.74.0
   independiente de Terraform          tfsec dentro  release      sigue
                                        de Trivy      standalone   actualizándose,
                                                       tfsec        con reglas AWS-XXXX
                                                       v1.28.14     heredadas de tfsec
                                                       (may-2025)   + reglas nuevas

Sentinel: nombrado por contraste, no construido

Vale la pena nombrar, aunque sea brevemente, un cuarto motor que probablemente vas a escuchar mencionar en contextos de policy-as-code: Sentinel, de HashiCorp. Es el motor de políticas comercial, nativo de HCP Terraform (antes Terraform Cloud/Enterprise) — la alternativa que un equipo con una suscripción de pago a HCP Terraform usaría en lugar de OPA/conftest para evaluar políticas sobre un plan. Ya lo nombró el Módulo 4, lección 2, por contraste con conftest; se nombra otra vez aquí porque, igual que conftest, cumple un rol distinto al de Trivy/Checkov — evalúa políticas, no escanea configuración contra un catálogo de errores comunes. No existe una vía $0 para probarlo en el laboratorio de esta guía, así que se queda nombrado, nunca construido, la misma decisión de diseño que el Módulo 4 ya tomó.


Errores comunes

Intentar instalar tfsec por separado "para tener las dos herramientas" (de desconocimiento del mercado). Qué pasa: alguien, leyendo un tutorial de hace dos o tres años, instala tfsec además de Trivy, esperando cobertura adicional. Cómo detectarlo: si tu tfsec --version muestra v1.28.14 o anterior, y tu proyecto usa algún recurso o atributo introducido después de mediados de 2025. Cómo corregirlo: no hay ninguna cobertura adicional real que ganes — trivy config ya incluye el motor completo de tfsec, actualizado. Instalar el binario viejo por separado solo agrega una herramienta más que mantener, sin beneficio.

Asumir que el ID AVD-AWS-XXXX que aparece en tutoriales antiguos es el que vas a ver en la terminal (de expectativa desactualizada). Qué pasa: alguien busca un hallazgo específico por AVD-AWS-0086 en la salida real de trivy config y no lo encuentra, porque la salida real dice AWS-0086, sin el prefijo AVD-. Cómo detectarlo: si tu búsqueda con grep "AVD-AWS" sobre la salida de Trivy 0.74.0 no encuentra nada, aunque el hallazgo sí está ahí. Cómo corregirlo: la lección 4 de este módulo confirma, con salida literal, el formato exacto que produce esta versión — usa AWS-XXXX para buscar en la salida de la CLI, y reserva AVD-AWS-XXXX para cuando busques la documentación en avd.aquasec.com.

Pensar que Checkov es "el mismo motor que Trivy, con otro nombre" (de confusión entre proyectos). Qué pasa: alguien, viendo que ambas herramientas producen resultados parecidos sobre el mismo HCL, asume que son el mismo software con dos interfaces. Cómo detectarlo: si esperas que instalar Checkov sea redundante con tener Trivy instalado. Cómo corregirlo: son dos proyectos completamente independientes, de dos empresas distintas (Aqua Security y Palo Alto Networks/Bridgecrew), con motores de evaluación distintos — uno de los dos usa un grafo de dependencias entre recursos, el otro no. La lección 5 te muestra la diferencia real, con hallazgos que uno encuentra y el otro no.


Ejercicios

Ejercicio 1 — Traduce un comando de tfsec a Trivy. Un colega te muestra un script antiguo de CI que corre tfsec --format json --out results.json .. Sin buscar documentación, escribe el comando equivalente con trivy config.

Ver solución
trivy config --format json --output results.json .

La migración es mecánica: tfsectrivy config, --out--output (el nombre completo del flag cambia levemente, pero el propósito es idéntico), y el resto de los argumentos —--format json, el directorio objetivo— se mantienen. Los IDs de chequeo dentro del results.json van a seguir siendo reconocibles, porque son, literalmente, las mismas reglas heredadas.

Ejercicio 2 — Explica, a alguien que solo conoce tfsec, por qué "está obsoleto" no es del todo preciso. Un compañero dice "tfsec está muerto, no lo uses". ¿Es esa la forma más precisa de decirlo? ¿Qué matiz le agregarías?

Ver solución

No está "muerto" en el sentido de haber desaparecido — el motor sigue vivo, pero dentro de Trivy, no como proyecto independiente. La forma más precisa es: "tfsec standalone dejó de recibir actualizaciones después de mayo de 2025, pero su motor completo — reglas, IDs de chequeo incluidos — sigue activo y actualizándose dentro de Trivy, bajo el comando trivy config. No perdiste ninguna cobertura al migrar; la ganaste, porque Trivy sigue agregando reglas nuevas que tfsec standalone ya no recibiría." Decir "está muerto" sin ese matiz podría hacer pensar, incorrectamente, que hay que buscar una alternativa completamente distinta.

Ejercicio 3 — Decide si instalarías Sentinel para este módulo. Basándote en lo que esta lección explicó sobre Sentinel, ¿tendría sentido intentar instalarlo y correrlo contra andes-cargo-infra/ en este laboratorio $0? Justifica.

Ver solución

No — y por la misma razón exacta que el Módulo 4 ya estableció para conftest frente a Sentinel: es un motor comercial, nativo de HCP Terraform de pago, sin una vía de ejecución gratuita equivalente a la de OPA/conftest. Este laboratorio corre completamente contra LocalStack y herramientas $0; no hay forma honesta de "simular" Sentinel sin una cuenta de HCP Terraform real. Se nombra para que sepas que existe y cuándo un equipo lo elegiría (cuando ya paga por HCP Terraform de todos modos), pero no se construye — la misma frontera declarada que gobierna toda esta guía.


Resumen y siguiente paso

Esta lección completó el panorama de herramientas: Trivy (Aqua Security, escaneo de IaC + secretos + SBOM en un solo binario), Checkov (Palo Alto Networks/Bridgecrew, más de mil políticas con motor de grafo), y tfsec (fusionado dentro de Trivy desde 2024, último release independiente en mayo de 2025, sin reglas nuevas desde entonces). Confirmaste, con el ejemplo del hallazgo AWS-0086, que el motor de tfsec sigue vivo dentro de Trivy con sus mismos identificadores de chequeo — y que el formato real que vas a ver en la terminal es AWS-XXXX, no AVD-AWS-XXXX.

Antes de avanzar deberías poder: explicar por qué tfsec no se instala por separado en este módulo; traducir un comando tfsec a su equivalente trivy config; y distinguir Trivy de Checkov como dos proyectos completamente independientes, no dos caras del mismo motor.

La lección 3 confirma tu instalación de Trivy — ya presente desde el Módulo 3 — y documenta el método de instalación completo, para que esta lección sea reproducible incluso si llegaste directo a este módulo.

Recursos

  1. trivy.dev — Terraform coverage — documentación oficial de la cobertura de Terraform de Trivy, incluidos los IDs de chequeo heredados de tfsec.
  2. GitHub — aquasecurity/tfsec — repositorio del proyecto original, con el anuncio oficial de la fusión dentro de Trivy y el historial de releases hasta v1.28.14.
  3. www.checkov.io — Terraform Scanning — documentación oficial de Checkov sobre escaneo de Terraform.
  4. avd.aquasec.com — la base de datos pública de vulnerabilidades de Aqua Security, donde vive la documentación completa de cada regla AWS-XXXX.
  5. Este curso, Módulo 4, lección 2 — donde Sentinel se nombró por primera vez, por contraste con conftest.