Módulo 5: Scanning Iac And Dependencies

1. Introducción: reglas propias (M4) frente a reglas de la comunidad (M5)

Descripción

El Módulo 4 te dejó con tres políticas Rego propias en policy/ — no-destroy-shipments.rego, least-privilege-iam.rego, no-public-buckets.rego — cada una escrita por ti, línea por línea, para un riesgo específico de THREAT-MODEL.md. Este módulo hace algo distinto: en vez de escribir tus propias reglas, vas a instalar dos herramientas que ya traen cientos de reglas escritas por la comunidad de seguridad de AWS — Trivy y Checkov — y correrlas contra el mismo andes-cargo-infra/ que el Módulo 4 ya evaluó. El trabajo de este módulo no es escribir reglas. Es leerlas, entender por qué existen, e integrarlas con criterio.

Conexión con el módulo

Este módulo retoma exactamente donde el Módulo 4 lo dejó — el mismo proyecto Terraform, el mismo THREAT-MODEL.md, los mismos siete hallazgos de RISK-MAP.md — pero mira la infraestructura con un instrumento distinto. conftest, en el Módulo 4, evaluó tres preguntas muy específicas, elegidas por ti a partir de un modelo de amenazas concreto. Trivy y Checkov, en este módulo, evalúan cientos de preguntas que ni siquiera se te ocurrió hacer — porque las escribió gente que pasa su carrera catalogando errores de configuración de AWS. Ninguna de las dos herramientas reemplaza a la otra. Esa es, de punta a punta, la tesis de este módulo.

Analogía: dos inspectores, dos listas, la misma casa

Imagina que terminaste de construir una casa siguiendo tu propio criterio de seguridad: pusiste una cerradura reforzada en la puerta principal porque sabías, específicamente, que en tu barrio habían forzado esa puerta en otras casas. Esa cerradura es tu política propia — resuelve un riesgo que tú identificaste, con evidencia concreta, para tu caso concreto.

Ahora imagina que contratas a un inspector de seguridad residencial. Ese inspector no sabe nada de tu barrio ni de tu cerradura reforzada — trae una lista de verificación de doscientos puntos que aplica a cualquier casa: ¿hay detector de humo en cada piso? ¿el garaje tiene salida de emergencia? ¿las ventanas del sótano tienen rejas? El inspector no está tratando de adivinar tu amenaza específica. Está aplicando el conocimiento acumulado de miles de casas inspeccionadas antes que la tuya, muchas de las cuales tuvieron problemas que nunca se te habría ocurrido buscar.

Trivy y Checkov son ese inspector — o, más precisamente, dos inspectores distintos, cada uno con su propia lista, revisando la misma casa. Uno puede notar que falta un detector de humo en el ático; el otro puede notar que la escalera del sótano no tiene pasamanos. Ambos tienen razón. Ninguno de los dos vio tu cerradura reforzada, porque esa no está en su lista — la pusiste tú, por una razón que solo tú conocías. Esa cerradura sigue siendo tuya, y sigue siendo necesaria. Los inspectores solo agregan lo que su lista, acumulada de miles de casas, ya sabe que vale la pena revisar.

Ejemplo trabajado: el mismo riesgo, visto por tres lentes distintas

Antes de instalar nada, vale la pena ver el contraste completo con un caso concreto que vas a encontrar de verdad en este módulo. El bucket andes-cargo-shipment-docs no tiene, todavía, un bloqueo de acceso público declarado — es el hallazgo TM-04 de THREAT-MODEL.md (Módulo 1), "Information disclosure: S3 bucket has no public-access block".

Lente 1 — Tu propio criterio (Módulo 1). Al mapear la superficie de ataque, notaste manualmente, leyendo el HCL, que modules/s3-bucket/ nunca declara aws_s3_bucket_public_access_block. Lo escribiste como hallazgo TM-04 porque tú lo viste, no porque una herramienta te lo señaló.

Lente 2 — Regla propia (Módulo 4). no-public-buckets.rego es la política que tú mismo escribiste para que esto nunca vuelva a pasar en un plan futuro: evalúa cada cambio antes de que se aplique, y falla si un bucket S3 nuevo o modificado no bloquea acceso público. Es preventiva, y es tuya.

Lente 3 — Regla de la comunidad (este módulo). Cuando corras trivy config por primera vez en la lección 4, vas a ver cinco hallazgos distintos sobre este mismo bucket — no uno, cinco —, cada uno con su propio ID (AWS-0086, AWS-0087, AWS-0091, AWS-0093, AWS-0094), porque Trivy no trata "bloqueo de acceso público" como una sola pregunta binaria: la descompone en las cuatro banderas reales de la API de AWS (block_public_acls, block_public_policy, ignore_public_acls, restrict_public_buckets) más la ausencia del recurso mismo, cada una evaluada por separado. Nadie en tu equipo tuvo que pensar en esa descomposición — ya viene en la lista del inspector.

Qué esperar (adelanto — la lección 4 corre este comando completo, con salida literal):

│ modules/s3-bucket/main.tf │ terraform │         7         │

Siete hallazgos en un solo archivo, cinco de ellos sobre esta única brecha. Ese es el tipo de profundidad que una lista de reglas acumulada durante años, sobre miles de proyectos reales, aporta y que ninguna política propia — por buena que sea — puede replicar sola.

Por qué esto es complementario, no redundante

Es tentador, la primera vez que ves la profundidad de Trivy y Checkov, preguntarte si el Módulo 4 fue trabajo perdido — ¿para qué escribir no-public-buckets.rego a mano si un escáner de la comunidad ya lo cubre? La respuesta tiene tres partes, y las tres importan:

Primera: el escáner de la comunidad no conoce tu negocio. Ni Trivy ni Checkov tienen ninguna regla que diga "nunca destruyas la tabla Shipments" — porque ninguna herramienta genérica puede saber que esa tabla, específicamente, es la fuente única de verdad del sistema de envíos de Andes Cargo. Eso solo lo sabe alguien que entiende el negocio, y por eso no-destroy-shipments.rego (Módulo 4, lección 6) sigue siendo, y va a seguir siendo, imprescindible.

Segunda: el momento en que corre cada una es distinto. conftest, en el Módulo 4, evalúa el terraform plan — el cambio que está por aplicarse, antes de que exista la posibilidad de que se aplique. Es preventivo por diseño, y por eso el Módulo 4 lo llama así. Trivy y Checkov, tal como los vas a usar en este módulo, evalúan el HCL declarado, sin importar si hay un cambio pendiente o no — puedes correrlos sobre un proyecto que no cambió en meses, y van a seguir encontrando lo que ya estaba mal desde el principio. Son complementarios en el tiempo: uno vigila el cambio, el otro audita el estado acumulado.

Tercera: nadie mantiene doscientas reglas propias. Escribir una política Rego para "todo bucket S3 debe bloquear acceso público" te tomó una lección completa en el Módulo 4. Escribir, y mantener actualizadas, las más de mil reglas que trae Checkov —cada una reaccionando a un nuevo tipo de recurso, un nuevo atributo, un nuevo vector descubierto por la comunidad de seguridad— no es un trabajo que ningún equipo pequeño pueda sostener solo. Ese es, literalmente, el valor que aporta un proyecto de código abierto con miles de contribuyentes: cobertura que ningún equipo individual replicaría a tiempo completo.

   REGLAS PROPIAS (M4)                    REGLAS DE LA COMUNIDAD (M5)
   ────────────────────                   ───────────────────────────
   conftest + Rego                        Trivy + Checkov
   3 políticas, escritas por ti           cientos/miles de reglas, ya escritas
   conoce el NEGOCIO de Andes Cargo       conoce el ERROR COMÚN de configuración
   corre sobre el PLAN (preventivo)       corre sobre el HCL declarado
   "nunca destruyas Shipments"            "todo bucket S3 bloquea acceso público"
   "AppServerRole sin s3:*"               "toda tabla DynamoDB tiene PITR"

              └──────────────┬──────────────┘
                             ▼
              ambas capas evalúan el MISMO andes-cargo-infra/
              ninguna reemplaza a la otra — se complementan

Qué vas a construir en este módulo

Ocho lecciones, todas ejecutadas de verdad, sobre el mismo andes-cargo-infra/ endurecido por los Módulos 1 a 3:

Esta introducción — el contraste reglas propias/reglas de la comunidad.
El panorama de escáneres — Trivy, Checkov, y por qué tfsec ya no se instala por separado (se fusionó dentro de Trivy en 2024).
Instalando Trivy — confirmando la versión 0.74.0, ya presente desde el Módulo 3.
Escaneando andes-cargo-infra/ con Trivy — trivy config, hallazgos reales, cada uno con su ID.
Instalando y corriendo Checkov — segundo escáner, comparado con la salida de Trivy.
Arreglar, suprimir o aceptar un hallazgo — un hallazgo real corregido en el HCL; otro suprimido con una razón documentada, nunca en silencio.
Agregando el escaneo al pipeline heredado — un step de Trivy en ci.yml, corrido con act.
Proyecto: el reporte de postura de seguridad de Andes Cargo — el cierre del módulo, con evidencia SARIF/JSON.

Al terminar, andes-cargo-infra/ no va a tener un solo hallazgo crítico o alto sin justificar — y vas a saber, para cada uno de los que queden, exactamente por qué queda y quién lo decidió así.

Errores comunes

Pensar que instalar Trivy o Checkov hace innecesario el Módulo 4 (de alcance). Qué pasa: alguien, después de ver la profundidad de hallazgos de este módulo, concluye que escribir políticas Rego propias fue esfuerzo desperdiciado. Cómo detectarlo: si tu razonamiento es "con un buen escáner de la comunidad, no hace falta escribir nada propio". Cómo corregirlo: ningún escáner genérico puede conocer que Shipments es la fuente única de verdad de Andes Cargo, ni que AppServerRole solo debería leer photos/*. Esas reglas exigen contexto de negocio que ninguna lista genérica tiene — y por eso siguen viviendo en policy/, evaluadas con conftest, sin que este módulo las toque.

Esperar que Trivy y Checkov encuentren exactamente los mismos hallazgos (de expectativa sobre el mercado de herramientas). Qué pasa: alguien corre ambas herramientas, ve listas distintas, y asume que una de las dos está mal configurada o tiene un bug. Cómo detectarlo: si tu primera reacción ante una discrepancia es buscar qué hiciste mal, en vez de investigar si es una diferencia real de cobertura. Cómo corregirlo: la lección 5 de este módulo documenta, con evidencia real, exactamente qué se solapa entre ambas herramientas y qué no — el solapamiento parcial es la norma en esta industria, no una señal de error.

Confundir "preventivo" (Módulo 4) con "más importante" que "detectivo sobre el HCL declarado" (este módulo) — o viceversa (de jerarquía falsa). Qué pasa: alguien asume que, porque conftest corre antes de que un cambio se aplique, es automáticamente "mejor" que escanear el HCL ya declarado. Cómo detectarlo: si tratas cualquiera de las dos capas como opcional frente a la otra. Cómo corregirlo: son momentos distintos con propósitos distintos — conftest evita que un cambio malo entre; Trivy/Checkov auditan lo que ya está, incluido lo que entró antes de que existiera cualquier política. Un proyecto seguro necesita ambos momentos cubiertos, no solo uno.

Ejercicios

Ejercicio 1 — Clasifica cada control ya construido por esta guía como "regla propia" o "regla de la comunidad". Sin volver a mirar la lección, clasifica: (a) no-destroy-shipments.rego, (b) el escaneo de secretos con trivy fs --scanners secret del Módulo 3, (c) la trust policy OIDC del Módulo 2.

Ver solución

(a) Regla propia — nadie fuera de Andes Cargo sabría que la tabla Shipments no debe destruirse; la escribiste tú, en el Módulo 4, a partir de un hallazgo específico de THREAT-MODEL.md. (b) Regla de la comunidad — el escáner de secretos de Trivy trae reglas ya escritas para reconocer el formato de una clave de acceso de AWS, un token de GitHub, y decenas de otros patrones; tú no escribiste ninguna de esas reglas, solo corriste la herramienta que ya las trae. (c) Ninguna de las dos categorías de este módulo — es infraestructura construida, no una regla que evalúa infraestructura. La trust policy es el HCL que Trivy o Checkov evaluarían en este módulo, no una regla en sí misma.

Ejercicio 2 — Predice cuántos hallazgos esperarías de Trivy sobre un proyecto Terraform que nunca declaró ningún recurso de seguridad explícito. Si alguien te mostrara un proyecto Terraform que solo declara un bucket S3 con el mínimo indispensable (bucket = "mi-bucket", nada más), ¿esperarías cero hallazgos de Trivy, o varios? Justifica con lo que ya sabes de este módulo.

Ver solución

Varios, probablemente media docena o más — el ejemplo trabajado de esta lección ya mostró que un solo bucket S3, sin ningún endurecimiento explícito, dispara al menos siete hallazgos distintos en Trivy (bloqueo de acceso público en sus cuatro variantes, cifrado con clave administrada por el cliente, registro de acceso, y el bloqueo de acceso público a nivel de cuenta). Un proyecto con el mínimo indispensable no tiene ninguna de esas protecciones declaradas — el resultado esperado es una lista de hallazgos, no una lista vacía. Cero hallazgos, en un proyecto Terraform real, es la excepción que exige explicación, no la norma por defecto.

Ejercicio 3 — Explica, con tus propias palabras, por qué "complementario" es la palabra correcta y no "redundante" ni "sustituto". A un compañero que insiste en que solo hace falta una de las dos capas (reglas propias o reglas de la comunidad, nunca ambas), dale la explicación más corta y completa que puedas.

Ver solución

Una respuesta completa suena, más o menos, así: "No es redundante, porque cada capa encuentra cosas que la otra estructuralmente no puede ver — una conoce el negocio, la otra conoce el error común de configuración acumulado de miles de proyectos. Y no es sustituto, porque quitar cualquiera de las dos deja un hueco real: sin las reglas propias, nadie protege a Shipments de un destroy accidental; sin las reglas de la comunidad, nadie te avisa que tu tabla DynamoDB no tiene recuperación a un punto en el tiempo, porque a nadie en tu equipo se le ocurrió pensar en esa pregunta específica. Complementario significa que las dos capas juntas cubren más terreno que cualquiera de las dos solas — ese es, literalmente, el resultado que vas a medir en la lección 4 de este módulo."

Resumen y siguiente paso

Esta lección estableció la distinción central de todo el módulo: el Módulo 4 construyó reglas propias, escritas por ti para riesgos específicos de Andes Cargo, evaluadas de forma preventiva sobre el plan. Este módulo instala y corre reglas de la comunidad — cientos de verificaciones ya escritas, acumuladas de miles de proyectos reales, evaluadas sobre el HCL declarado. Viste, con el ejemplo del bucket sin bloqueo de acceso público, cómo la misma brecha se ve distinta según el lente: un hallazgo manual en el Módulo 1, una política propia en el Módulo 4, cinco hallazgos independientes de Trivy en este módulo.

Antes de avanzar deberías poder: explicar la diferencia entre una regla propia y una regla de la comunidad con un ejemplo concreto de esta guía; explicar por qué ambas capas son necesarias, no una alternativa a la otra; y anticipar que un proyecto sin endurecimiento explícito produce varios hallazgos de un escáner de la comunidad, no cero.

La lección 2 completa el panorama de herramientas: por qué esta guía usa Trivy y Checkov, y por qué tfsec — el tercer nombre que probablemente ya escuchaste — no se instala por separado.

Recursos

trivy.dev — sitio oficial de Trivy, la primera de las dos herramientas de este módulo.
www.checkov.io — sitio oficial de Checkov, la segunda.
Este curso, Módulo 4 completo — la fuente de las tres políticas propias con las que este módulo contrasta constantemente.
Este curso, Módulo 1, THREAT-MODEL.md — el hallazgo TM-04, usado como ejemplo trabajado de esta lección.

← Anterior8. Proyecto: la biblioteca de políticas de Andes Cargo Siguiente →2. El panorama de escáneres: Trivy, Checkov y `tfsec`, con honestidad de mercado