Módulo 5: Scanning Iac And Dependencies
5. Manos a la obra: instalando y corriendo Checkov
Descripción
Esta lección instala el segundo inspector de la analogía de la lección 1, y lo pone a caminar por la misma casa que Trivy ya recorrió. Vas a instalar Checkov 3.3.11 — superior a la 3.2.529 mínima que fija el diseño de esta guía—, correrlo contra el mismo andes-cargo-infra/ de la lección 4, y comparar, hallazgo por hallazgo, qué encuentra cada herramienta. El resultado no va a ser una lista idéntica. Esa diferencia, documentada con evidencia real, es el contenido central de esta lección.
Conexión con el módulo
La lección 4 dejó once hallazgos de Trivy sobre la mesa. Esta lección corre un segundo escáner completamente independiente —otra empresa, otro motor, otro lenguaje de implementación— sobre el mismo HCL exacto, y confirma con evidencia por qué la lección 1 insistió en que dos inspectores, con dos listas distintas, encuentran cosas distintas en la misma casa.
Paso 1 — Instalando Checkov
Checkov es un paquete de Python, instalado con pip:
pip3 install --break-system-packages checkovQué esperar (resumen — la instalación real trae más de cuarenta dependencias, incluidas bc-python-hcl2 para parsear HCL y networkx/rustworkx para el motor de grafo mencionado en la lección 2):
Successfully installed ... checkov-3.3.11 ...
checkov --versionQué esperar (literal — ejecutado para escribir esta lección):
3.3.11
Versión confirmada: Checkov 3.3.11, por encima del mínimo 3.2.529 que fija el diseño de esta guía — Checkov, igual que Trivy, publica versiones con frecuencia; cualquier versión igual o superior a 3.2.529 trae la cobertura que necesitas para esta lección.
Analogía retomada: el segundo inspector, con una lista distinta
La lección 1 ya adelantó la idea: dos inspectores, dos listas, la misma casa. Ahora que Checkov está instalado, vale la pena una precisión más: los dos inspectores de esta analogía no solo tienen listas distintas — uno de ellos (Checkov) también sabe leer planos más allá de habitaciones individuales. Si una puerta de servicio en la cocina conecta directamente con la puerta trasera del jardín, sin pasar por ningún punto de control, un inspector que solo revisa habitación por habitación podría no notarlo — pero uno que además revisa cómo se conectan los planos entre sí, sí. Ese es, en términos de Checkov, su motor de grafo: evalúa relaciones entre recursos, no solo la configuración de cada uno por separado.
Paso 2 — Corriendo Checkov contra andes-cargo-infra/
checkov -d . --compact --quiet--compact suprime el detalle de código fuente por hallazgo (que ya viste en detalle con Trivy en la lección 4); --quiet reduce el ruido de logs de INFO. Aun así, vas a ver algo real que ninguno de los dos flags suprime — inténtalo tú mismo antes de seguir leyendo.
Qué esperar (literal — primeras líneas, ejecutado para escribir esta lección):
2026-08-14 10:39:25,205 [MainThread ] [WARNI] Failed to get the checkov mappings and guidelines from https://api0.prismacloud.io/bridgecrew/api/v2/guidelines. Skips using BC_* IDs will not work.
Traceback (most recent call last):
...
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='api0.prismacloud.io', port=443): Max retries exceeded with url: /bridgecrew/api/v2/guidelines (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1077)')))
Esto es real, y honesto de nombrar explícitamente: Checkov, por defecto, intenta contactar una API de Bridgecrew/Prisma Cloud para descargar mapeos de identificadores (BC_*, los IDs propios de la plataforma comercial de Bridgecrew) — un intento de red que, sin una cuenta ni una conexión saliente confiable, falla con un error de certificado TLS. No es un bloqueo: Checkov captura ese fallo y sigue corriendo el escaneo local completo con sus reglas CKV_* de código abierto, que no dependen de ninguna API externa. Es la razón por la que este comando termina con un reporte completo a pesar del error visible al principio de la salida.
Qué esperar (literal — el reporte, después del error de red):
terraform scan results:
Passed checks: 113, Failed checks: 15, Skipped checks: 0
Check: CKV_AWS_28: "Ensure DynamoDB point in time recovery (backup) is enabled"
FAILED for resource: aws_dynamodb_table.shipments
File: /dynamodb.tf:4-15
Check: CKV_AWS_119: "Ensure DynamoDB Tables are encrypted using a KMS Customer Managed CMK"
FAILED for resource: aws_dynamodb_table.shipments
File: /dynamodb.tf:4-15
Check: CKV_AWS_50: "X-Ray tracing is enabled for Lambda"
FAILED for resource: aws_lambda_function.process_shipment_manifest
File: /lambda.tf:10-23
Check: CKV_AWS_117: "Ensure that AWS Lambda function is configured inside a VPC"
FAILED for resource: aws_lambda_function.process_shipment_manifest
File: /lambda.tf:10-23
Check: CKV_AWS_116: "Ensure that AWS Lambda function is configured for a Dead Letter Queue(DLQ)"
FAILED for resource: aws_lambda_function.process_shipment_manifest
File: /lambda.tf:10-23
Check: CKV_AWS_272: "Ensure AWS Lambda function is configured to validate code-signing"
FAILED for resource: aws_lambda_function.process_shipment_manifest
File: /lambda.tf:10-23
Check: CKV_AWS_115: "Ensure that AWS Lambda function is configured for function-level concurrent execution limit"
FAILED for resource: aws_lambda_function.process_shipment_manifest
File: /lambda.tf:10-23
Check: CKV_AWS_337: "Ensure SSM parameters are using KMS CMK"
FAILED for resource: aws_ssm_parameter.customs_api_webhook_signing_key
File: /secrets.tf:4-13
Check: CKV_AWS_149: "Ensure that Secrets Manager secret is encrypted using KMS CMK"
FAILED for resource: aws_secretsmanager_secret.customs_api_credentials
File: /secrets.tf:15-18
Check: CKV2_AWS_61: "Ensure that an S3 bucket has a lifecycle configuration"
FAILED for resource: module.shipment_docs_bucket.aws_s3_bucket.this
File: /modules/s3-bucket/main.tf:1-4
Check: CKV2_AWS_6: "Ensure that S3 bucket has a Public Access block"
FAILED for resource: module.shipment_docs_bucket.aws_s3_bucket.this
File: /modules/s3-bucket/main.tf:1-4
Check: CKV2_AWS_57: "Ensure Secrets Manager secrets should have automatic rotation enabled"
FAILED for resource: aws_secretsmanager_secret.customs_api_credentials
File: /secrets.tf:15-18
Check: CKV_AWS_18: "Ensure the S3 bucket has access logging enabled"
FAILED for resource: module.shipment_docs_bucket.aws_s3_bucket.this
File: /modules/s3-bucket/main.tf:1-4
Check: CKV_AWS_145: "Ensure that S3 buckets are encrypted with KMS by default"
FAILED for resource: module.shipment_docs_bucket.aws_s3_bucket.this
File: /modules/s3-bucket/main.tf:1-4
Check: CKV_AWS_144: "Ensure that S3 bucket has cross-region replication enabled"
FAILED for resource: module.shipment_docs_bucket.aws_s3_bucket.this
File: /modules/s3-bucket/main.tf:1-4
Ciento trece controles pasados, quince fallidos, cero omitidos. Ciento trece es, por sí solo, un dato que vale la pena notar: es la cantidad de preguntas de seguridad de la lista de Checkov que este proyecto ya responde correctamente — el trabajo acumulado de los Módulos 1 a 3, visto desde el ángulo de un inspector distinto al de Trivy.
El solapamiento, hallazgo por hallazgo, con evidencia
Esta es la comparación central de la lección — no una afirmación general de que "las herramientas se solapan parcialmente", sino la lista exacta, construida cruzando los quince hallazgos de Checkov contra los once de Trivy (lección 4):
Checkov (CKV_AWS_*) | Trivy (AWS-*) | Relación |
|---|---|---|
CKV_AWS_28 (DynamoDB PITR) | AWS-0024 | Mismo hallazgo, distinto ID |
CKV_AWS_119 (DynamoDB KMS CMK) | AWS-0025 | Mismo hallazgo, distinto ID |
CKV_AWS_50 (Lambda X-Ray) | AWS-0066 | Mismo hallazgo, distinto ID |
CKV_AWS_149 (Secrets Manager KMS CMK) | AWS-0098 | Mismo hallazgo, distinto ID |
CKV_AWS_18 (S3 access logging) | AWS-0089 | Mismo hallazgo, distinto ID |
CKV_AWS_145 (S3 KMS default encryption) | AWS-0132 | Mismo hallazgo, distinto ID |
CKV2_AWS_6 (S3 Public Access block, un hallazgo) | AWS-0086/0087/0091/0093/0094 (cinco hallazgos) | Misma causa raíz, granularidad distinta — 1 a 5 |
CKV_AWS_117 (Lambda en VPC) | (ninguno) | Solo Checkov |
CKV_AWS_116 (Lambda DLQ) | (ninguno) | Solo Checkov |
CKV_AWS_272 (Lambda code-signing) | (ninguno) | Solo Checkov |
CKV_AWS_115 (Lambda límite de concurrencia) | (ninguno) | Solo Checkov |
CKV_AWS_337 (SSM Parameter KMS CMK) | (ninguno) | Solo Checkov |
CKV2_AWS_61 (S3 lifecycle) | (ninguno) | Solo Checkov |
CKV2_AWS_57 (Secrets Manager rotación) | (ninguno) | Solo Checkov |
CKV_AWS_144 (S3 replicación entre regiones) | (ninguno) | Solo Checkov |
Seis hallazgos coinciden 1 a 1 entre ambas herramientas, sobre el mismo recurso y el mismo problema, con IDs completamente distintos. Uno coincide, pero con granularidad distinta: donde Checkov hace una sola pregunta binaria ("¿tiene el bucket un bloqueo de acceso público?"), Trivy la descompone en las cuatro banderas reales de la API más la ausencia del recurso — cinco preguntas donde Checkov hace una. Y ocho hallazgos son exclusivos de Checkov en esta corrida — Trivy, con su conjunto de reglas actual, no los marcó en absoluto.
Fíjate en un patrón dentro de esos ocho: cinco de ellos son sobre la función Lambda (CKV_AWS_117, 116, 272, 115, además de CKV_AWS_50 que sí coincide) — Checkov trae, para este tipo de recurso específico, una cobertura notablemente más profunda que la única regla de Lambda que disparó Trivy (AWS-0066, tracing). CKV_AWS_272 —firma de código para Lambda— es, en particular, el hallazgo que anticipa exactamente el problema que el Módulo 6 de esta guía resuelve con cosign: el .zip de process-shipment-manifest no está firmado. Ningún escáner de infraestructura resuelve ese problema por sí solo —firmar un artefacto es una disciplina de cadena de suministro, no de configuración—, pero es notable que Checkov, sin saber nada del Módulo 6, ya esté señalando la dirección correcta.
SOLAPAMIENTO REAL, MEDIDO — no una cifra abstracta
Trivy (11 hallazgos) Checkov (15 hallazgos)
┌─────────────────────┐ ┌─────────────────────┐
│ 6 coinciden 1:1 │◄─────────►│ 6 coinciden 1:1 │
│ 5 son AWS-0086/87/ │◄────5:1──►│ 1 es CKV2_AWS_6 │
│ 91/93/94 │ │ │
└─────────────────────┘ │ 8 exclusivos de │
│ Checkov │
│ (5 sobre Lambda) │
└─────────────────────┘
Ningún hallazgo de Trivy quedó sin contraparte en Checkov en esta corrida —
pero Checkov encontró casi el doble de categorías distintas sobre el mismo HCL.Por qué el solapamiento parcial es normal, no un defecto
Es tentador leer esta comparación como un veredicto —"Checkov es mejor, encontró más"— pero esa lectura pierde el punto central de la lección 1: ninguna de las dos herramientas pretende ser exhaustiva por sí sola. Trivy prioriza velocidad y una superficie amplia de tipos de escaneo (IaC, secretos, SBOM, vulnerabilidades de contenedor, todo en un binario); Checkov prioriza profundidad de política y relaciones entre recursos vía su motor de grafo. Son proyectos de código abierto, mantenidos por comunidades distintas, con prioridades de cobertura distintas — el mismo tipo de diferencia que encontrarías entre dos auditores de seguridad humanos con formación distinta, revisando el mismo sistema.
La consecuencia práctica, no filosófica: un equipo que corre solo una de las dos herramientas tiene un punto ciego real, medible, como el que acabas de ver con los cinco hallazgos de Lambda que solo Checkov detectó en esta corrida. Correr ambas no es redundancia — es la misma lógica de "defensa en profundidad" que ya viste en el Módulo 4 con conftest y este módulo con los escáneres de la comunidad, aplicada ahora entre dos escáneres de la comunidad, no solo entre reglas propias y reglas de la comunidad.
Errores comunes
Interpretar el error SSL del principio de la salida como que Checkov falló por completo (de lectura incompleta). Qué pasa: alguien ve el Traceback y el SSLCertVerificationError al principio de la salida, y concluye que el comando no funcionó. Cómo detectarlo: si tu primer instinto es buscar cómo "arreglar" ese error de red antes de revisar si el reporte de escaneo local sí se generó. Cómo corregirlo: desplázate hasta el final de la salida — terraform scan results: con el conteo de Passed/Failed/Skipped confirma que el escaneo local, con las reglas CKV_* de código abierto, corrió completo. El error de red solo afecta la funcionalidad opcional de mapeo a IDs BC_* de la plataforma comercial, que esta guía nunca usa.
Buscar el mismo hallazgo con el mismo ID en ambas herramientas (de expectativa de nomenclatura compartida). Qué pasa: alguien busca AWS-0024 en la salida de Checkov, esperando encontrarlo con ese nombre exacto. Cómo detectarlo: si tu búsqueda de texto sobre la salida de Checkov, usando un ID de Trivy, no encuentra nada, a pesar de que el hallazgo equivalente sí está ahí. Cómo corregirlo: cada herramienta tiene su propio esquema de identificadores —AWS-XXXX para Trivy, CKV_AWS_XXX/CKV2_AWS_XXX para Checkov—, sin ninguna correspondencia automática entre ambos. La tabla de esta lección es, precisamente, el mapeo manual que tuviste que construir para cruzar ambos conjuntos.
Concluir que Checkov "encontró más" porque tiene más hallazgos en total, sin ajustar por la granularidad distinta del bucket. Qué pasa: alguien compara 15 (Checkov) contra 11 (Trivy) y concluye directamente que Checkov cubre más terreno. Cómo detectarlo: si tu comparación es solo aritmética, sin considerar que cinco de los once hallazgos de Trivy son, en realidad, una sola causa raíz que Checkov cuenta como uno. Cómo corregirlo: la comparación correcta no es de cantidad total, sino de categorías distintas de problema — ajustando por esa granularidad, Trivy cubrió siete categorías (seis + la del bucket) y Checkov cubrió catorce (seis + la del bucket + ocho exclusivas). La diferencia real está en las ocho categorías exclusivas de Checkov, no en el conteo bruto.
Ejercicios
Ejercicio 1 — Encuentra el hallazgo de Checkov que anticipa el Módulo 6 de esta guía. Sin volver a mirar la lección, busca en la tabla de solapamiento cuál de los quince hallazgos de Checkov está directamente relacionado con lo que cosign va a resolver más adelante en esta guía.
Ver solución
CKV_AWS_272: "Ensure AWS Lambda function is configured to validate code-signing" — Checkov está señalando, sin saber nada del Módulo 6, que process-shipment-manifest no tiene ninguna validación de firma de código configurada. Es, conceptualmente, el mismo problema que TM-02 de THREAT-MODEL.md documentó en el Módulo 1 ("deployment artifact has no signature"), ahora confirmado por un escáner de la comunidad — y resuelto, del lado de AWS Lambda Code Signing específicamente, fuera del alcance directo de esta guía (que usa cosign/Sigstore de forma independiente del artefacto, no la funcionalidad nativa de Lambda), pero apuntando a la misma dirección de riesgo.
Ejercicio 2 — Explica por qué CKV2_AWS_6 cuenta como un solo hallazgo, mientras Trivy usa cinco. A un compañero que pregunta si esto significa que Checkov es "menos estricto" con el bloqueo de acceso público, corrígelo con lo que aprendiste en esta lección.
Ver solución
No es menos estricto — es una decisión de diseño distinta sobre granularidad de reporte, no de rigor. CKV2_AWS_6 verifica la existencia y correcta configuración del recurso aws_s3_bucket_public_access_block como una sola pregunta compuesta (¿existe, y están las cuatro banderas correctas?); si falla cualquiera de las condiciones, todo el chequeo falla como una unidad. Trivy, en cambio, separa cada bandera de la API real en su propia regla independiente, permitiendo, en teoría, que un bucket pase cuatro de las cinco preguntas y falle solo una. Ambos enfoques llegan a la misma conclusión de fondo sobre el HCL de esta lección (el bucket no está protegido), solo que reportan esa conclusión con un nivel de detalle distinto.
Ejercicio 3 — Diseña la regla de decisión de tu equipo: ¿correr una herramienta o las dos? Basándote en la evidencia de esta lección —no en una opinión general sobre herramientas de seguridad—, escribe en dos o tres frases la recomendación que le darías a un equipo que te pregunta si vale la pena el costo operativo de mantener dos escáneres en su pipeline.
Ver solución
Una recomendación completa, basada en la evidencia de esta lección específica, suena así: "Sobre este proyecto concreto, correr solo Trivy habría dejado sin detectar ocho categorías de hallazgos —cinco de ellas sobre la única función Lambda del sistema—, incluida una que apunta directamente al problema de cadena de suministro que el Módulo 6 resuelve. El costo de correr ambas herramientas es tiempo de CI (segundos, no minutos, para un proyecto de este tamaño) y una tabla de correspondencia que hay que mantener a mano cuando ambas señalan el mismo problema. Para un proyecto con datos sensibles y sin presupuesto de un producto pago que unifique ambos catálogos, ese costo es bajo comparado con el punto ciego que dejaría correr solo una."
Resumen y siguiente paso
En esta lección instalaste Checkov 3.3.11 y lo corriste contra el mismo andes-cargo-infra/ de la lección 4: ciento trece controles pasados, quince fallidos, cero omitidos. Cruzaste, hallazgo por hallazgo, los quince resultados de Checkov contra los once de Trivy: seis coinciden exactamente, uno coincide con granularidad distinta (cinco reglas de Trivy contra una de Checkov, mismo bucket), y ocho son exclusivos de Checkov — cinco de ellos sobre la función Lambda, incluido un hallazgo que anticipa directamente el trabajo del Módulo 6. Confirmaste, con evidencia medida y no con una afirmación general, por qué el solapamiento parcial entre dos escáneres de la comunidad es la norma esperada, no un defecto de ninguno de los dos.
Antes de avanzar deberías poder: instalar y correr Checkov contra cualquier proyecto Terraform; explicar por qué un error de red al inicio de la salida no invalida el escaneo local; y construir, para cualquier par de escáneres, una tabla de correspondencia como la de esta lección.
La lección 6 toma estos veintiséis hallazgos combinados (once de Trivy, quince de Checkov, con el solapamiento ya mapeado) y decide, para tres casos concretos, si corresponde arreglar, suprimir con razón documentada, o aceptar el riesgo tal como está.
Recursos
- www.checkov.io — Terraform Scanning — documentación oficial de escaneo de Terraform con Checkov.
- GitHub — bridgecrewio/checkov — repositorio oficial, con el catálogo completo de chequeos
CKV_AWS_*/CKV2_AWS_*. - www.checkov.io — Suppressing and Skipping Policies — referencia oficial de supresión, la base de la lección 6.
- Este curso, Módulo 1,
THREAT-MODEL.md—TM-02, el hallazgo queCKV_AWS_272confirma de forma independiente en esta lección.