Módulo 8: Capstone The Andes Cargo Pipeline
6. La seguridad que esta guía no construyó
Descripción
La lección 5 trazó la frontera de lo que esta guía mostró pero no pudo ejecutar por una limitación técnica concreta de act. Esta lección traza una frontera distinta y deliberadamente más amplia: lo que esta guía, por diseño, nunca se propuso construir, porque pertenece a un dominio completo con su propia guía dedicada en este ecosistema. No es una lista de pendientes ni una admisión de que faltó tiempo — es la misma disciplina de frontera declarada que ya viste, puntualmente, con OIDC en el Módulo 4 y con conftest en el Módulo 6, consolidada aquí en un solo lugar antes de cerrar la guía completa.
Conexión con el módulo
Esta lección no ejecuta nada — es, junto con la lección 7, el mapa de honestidad que cierra la guía completa. Retoma, con más profundidad y sin repetirlas palabra por palabra, las fronteras que el Módulo 4 (OIDC) y el Módulo 6 (conftest, branch protection) ya nombraron, y agrega tres piezas que esta guía nunca mencionó en detalle porque están completamente fuera de su alcance: SAST/DAST, la cadena de suministro de software (SBOM, firma de imágenes, escaneo de vulnerabilidades), y políticas como sistema.
Analogía: la caseta de seguridad del edificio, frente al sistema de seguridad completo
El guardrail del Módulo 6 es, con precisión, una caseta de seguridad con una sola instrucción muy específica: revisa si alguien intenta sacar un objeto exacto por una puerta exacta. Un sistema de seguridad de un edificio real tiene, además de esa caseta, cámaras en cada pasillo, control de acceso en cada puerta, un protocolo de verificación de identidad para cada persona que entra, y una auditoría periódica de quién tuvo acceso a qué. Esta lección no construye ninguna cámara nueva — nombra, con precisión, cada pieza del sistema completo que un edificio de producción real necesitaría, y dónde se instala cada una.
Las cuatro piezas, en orden de qué tan lejos están de lo que ya construiste
1. OIDC de punta a punta, contra una cuenta AWS real
Ya la nombró completa el Módulo 4, lección 5: el YAML completo, la trust policy de IAM, el Identity Provider, explicados paso a paso, sin ejecutar por dos razones técnicas citadas (act no emite tokens OIDC; LocalStack no los valida). Esta es la pieza más cercana a lo que ya construiste — el mecanismo de secretos (secrets.AWS_ACCESS_KEY_ID) que sí migraste de verdad en el Módulo 4, lección 7, es el escalón intermedio hacia esto, no una alternativa permanente.
2. SAST y DAST
SAST (Static Application Security Testing, análisis estático) escanea el código fuente —o, en el caso de esta guía, el HCL— buscando patrones de configuración insegura antes de que se aplique: un bucket S3 sin cifrado, una política IAM demasiado permisiva, un grupo de seguridad abierto a 0.0.0.0/0. Herramientas como tfsec o checkov (nombradas, no instaladas en esta guía) hacen exactamente esto sobre archivos .tf, como un step adicional de ci.yml que correría junto a terraform validate. DAST (Dynamic Application Security Testing) prueba un sistema ya desplegado, en ejecución, buscando vulnerabilidades explotables desde afuera — tiene mucho más sentido para una aplicación con una API expuesta que para infraestructura declarativa como la de Andes Cargo, pero se nombra aquí por completitud, porque aparece junto a SAST en cualquier discusión seria de seguridad de pipeline.
Ninguna de las dos corrió en esta guía. El guardrail del Módulo 6 es, en espíritu, un primo minúsculo y artesanal de un escáner SAST —revisa un patrón específico sobre un plan—, pero no reemplaza la cobertura amplia y mantenida que da una herramienta dedicada.
3. Cadena de suministro de software: SBOM, firma de imágenes, escaneo de vulnerabilidades
Esta pieza no aplica directamente a Andes Cargo tal como esta guía la dejó —no hay ninguna imagen de contenedor ni ningún artefacto binario que el pipeline construya y despliegue—, pero es una de las piezas de seguridad de CI/CD más citadas en el mercado real, y vale la pena nombrarla con precisión, ya que cloud-security-and-guardrails-guide sí la construye:
- SBOM (Software Bill of Materials, inventario de dependencias): un documento generado automáticamente que lista cada librería y su versión exacta dentro de un artefacto —el equivalente, para software, de la lista de ingredientes de un producto empaquetado—.
- Firma de imágenes con
cosign/Sigstore: garantiza criptográficamente que una imagen de contenedor que corre en producción es, bit a bit, la que el pipeline construyó — no una sustituida en el camino. - Escaneo de vulnerabilidades con Trivy (u otra herramienta equivalente): revisa cada capa de una imagen de contenedor contra bases de datos públicas de vulnerabilidades conocidas (CVEs), antes de que esa imagen llegue a producción.
4. Políticas como sistema: Sentinel/OPA, más allá de conftest
El Módulo 6, lección 6, ya nombró conftest como el sistema real que reemplaza al grep artesanal del guardrail — una política Rego, evaluada contra la estructura de datos completa del plan, sin depender de dónde cae cada carácter dentro de una línea de texto. Esta lección agrega el nombre de dos sistemas de nivel empresarial que resuelven el mismo problema a mayor escala: Sentinel (el motor de políticas propio de HashiCorp, integrado nativamente en Terraform Cloud/Enterprise) y OPA (Open Policy Agent, el motor de políticas de código abierto sobre el que conftest está construido). La diferencia frente a conftest no es el lenguaje de política —Rego, en ambos casos— sino la escala: un sistema real de políticas gestiona docenas de reglas, versionadas, con su propio ciclo de pruebas, aplicadas de forma centralizada sobre múltiples repositorios — no un único guardrail artesanal, escrito para proteger un solo recurso.
La tabla de frontera, completa
| Pieza | Esta guía | cloud-security-and-guardrails-guide |
|---|---|---|
| Credenciales | secrets.AWS_ACCESS_KEY_ID (Módulo 4) | OIDC completo, de punta a punta, contra una cuenta real |
| Análisis de configuración | Un grep artesanal (Módulo 6) | SAST (tfsec/checkov) integrado como step estándar |
| Aplicación en ejecución | No aplica (sin API expuesta) | DAST |
| Artefactos de contenedor | No aplica (sin imágenes) | SBOM, firma con cosign, escaneo con Trivy |
| Políticas | Un grep sobre un único recurso | conftest/OPA/Sentinel como sistema, con múltiples reglas versionadas |
Cada fila de la columna derecha es, literalmente, el contenido de una guía completa y dedicada — no una lección suelta. Esta tabla no es una crítica a lo que construiste: es la prueba de que la frontera de esta guía fue una decisión de diseño consciente, documentada desde DISENO.md antes de escribir la primera lección, no un límite descubierto sobre la marcha.
Por qué esta frontera no es una laguna
Vale la pena decirlo con la misma claridad que ya usó el Módulo 4 sobre OIDC: cada pieza de esta lección requiere, como mínimo, una de estas tres cosas que esta guía deliberadamente no tiene — una cuenta AWS real (OIDC, SAST/DAST contra infraestructura viva), un registro de contenedores real (SBOM, cosign, Trivy), o un sistema de gestión de políticas centralizado, normalmente de pago o con su propia infraestructura (Sentinel, OPA a escala). Construir cualquiera de las tres habría roto el compromiso de $0 y reproducibilidad local que sostuvo cada lección de esta guía desde el Módulo 1 — el mismo compromiso que hizo posible que corrieras cada workflow, sin excepción, en tu propia máquina, sin gastar un centavo ni depender de una cuenta externa.
Errores comunes
Concluir que Andes Cargo, tal como quedó al cerrar esta guía, "no es seguro" (conceptual, el error más común de leer esta lección apurado). Qué pasa: alguien, después de ver la tabla completa de piezas faltantes, describe el pipeline construido en esta guía como inseguro o incompleto en una entrevista real. Cómo corregirlo: el pipeline construido aquí es genuinamente más seguro que el punto de partida del Módulo 1 —sin ningún pipeline, con un apply manual desde una laptop personal, con credenciales potencialmente de larga vida y sin ningún registro de quién aprobó qué—. "Le falta OIDC de punta a punta y SAST" no es lo mismo que "no tiene ninguna seguridad" — es la diferencia entre un sistema con una base sólida y controles explícitos, y uno con el nivel de madurez completo de un equipo de seguridad dedicado.
Intentar construir alguna de estas cuatro piezas dentro de andes-cargo-infra/, "para completar la guía" (de alcance). Qué pasa: alguien, motivado por esta lección, instala tfsec o checkov como un step nuevo de ci.yml, fuera del flujo de esta guía. Cómo corregirlo: no hay nada técnicamente incorrecto en experimentar con estas herramientas por tu cuenta —de hecho, es una buena forma de anticipar cloud-security-and-guardrails-guide—, pero esta guía, tal como está diseñada, no asume que lo hiciste, y ninguna lección posterior depende de ello. Si quieres profundizar de verdad, con el mismo rigor de ejecución que ya conoces, la vía correcta es esa guía hermana, no una extensión improvisada de esta.
Confundir SAST con el guardrail del Módulo 6, tratándolos como lo mismo (conceptual). Qué pasa: alguien, en una conversación técnica, describe el guardrail de esta guía como "un SAST casero" sin matizar la diferencia. Cómo corregirlo: el guardrail revisa un único patrón, sobre un único recurso, dentro del plan calculado — SAST revisa el código fuente completo (o el HCL completo) contra una base amplia y mantenida de reglas de configuración insegura, típicamente docenas o cientos de chequeos, actualizados por un equipo dedicado a seguir nuevas vulnerabilidades. Es una diferencia de escala tan grande como la que ya nombró el Módulo 6 entre el grep y conftest — vale la pena poder explicarla con precisión.
Ejercicios
Ejercicio 1 — Clasifica las cuatro piezas por cercanía a lo ya construido. Sin mirar esta lección, ordena las cuatro piezas (OIDC, SAST/DAST, cadena de suministro, políticas como sistema) de la más cercana a la más lejana de lo que ya construiste, y justifica el orden.
Ver solución
Un orden razonable, de más cercana a más lejana: (1) OIDC — ya tienes el escalón intermedio (secrets.*) funcionando de verdad, y el YAML completo mostrado; solo falta una cuenta real. (2) Políticas como sistema — ya tienes un guardrail artesanal funcionando, con la misma lógica exacta que conftest formalizaría; falta escalar el mecanismo, no inventarlo. (3) SAST/DAST — el guardrail es, en espíritu, un primo minúsculo de SAST, pero SAST cubre un dominio mucho más amplio que esta guía nunca tocó. (4) Cadena de suministro — no aplica en absoluto a Andes Cargo tal como esta guía la dejó, porque no hay ningún artefacto de contenedor que firmar o escanear; es la pieza más distante de las cuatro.
Ejercicio 2 — Explica por qué la cadena de suministro "no aplica" a este proyecto específico. Un colega pregunta por qué esta lección dedica menos espacio a SBOM/cosign/Trivy que a las otras tres piezas. Respóndele con precisión.
Ver solución
Andes Cargo, tal como quedó al cerrar esta guía, no construye ni despliega ninguna imagen de contenedor — su único artefacto de cómputo es una función Lambda empaquetada como un .zip (process-shipment-manifest), no una imagen Docker. SBOM, firma con cosign y escaneo con Trivy son piezas diseñadas específicamente para asegurar la cadena de construcción de imágenes de contenedor — tienen mucho más sentido para un proyecto que use kubernetes-and-eks-in-production-guide o aws-serverless-and-containers-guide, donde sí existen contenedores que construir y desplegar. Se nombran aquí por completitud del panorama de seguridad de CI/CD, no porque Andes Cargo las necesite hoy.
Ejercicio 3 — Diseña el primer paso concreto si tuvieras que agregar SAST a ci.yml mañana. Sin instalar nada, describe en dos o tres frases dónde exactamente, dentro del ci.yml que construiste, agregarías un step de tfsec o checkov, y por qué ese orden específico.
Ver solución
Una respuesta razonable: el step iría después de Terraform validate y antes de Terraform plan —la misma lógica de "barato antes de caro" que ya organizó el orden de ci.yml desde el Módulo 3—, porque un escaneo de configuración insegura no necesita ningún plan calculado ni ninguna conexión a LocalStack, solo el HCL válido. Colocarlo ahí significa que un problema de seguridad de configuración —como un bucket sin cifrado— se detecta y bloquea el job antes de gastar tiempo calculando un plan completo, exactamente el mismo principio de eficiencia que ya aplicaste a fmt/validate corriendo antes que cualquier verificación de red.
Resumen y siguiente paso
En esta lección consolidaste la frontera de seguridad completa de esta guía: OIDC de punta a punta contra una cuenta real, SAST/DAST, la cadena de suministro de software (SBOM, cosign, Trivy), y políticas como sistema (Sentinel/OPA más allá de conftest) — cuatro piezas, cada una perteneciente por completo a cloud-security-and-guardrails-guide, ninguna construida aquí por una decisión de diseño consciente, no por falta de tiempo. Viste la tabla completa de qué tiene esta guía frente a qué tendría un pipeline de producción con seguridad madura, y por qué esa distancia no invalida lo que sí construiste.
Antes de avanzar deberías poder: nombrar las cuatro piezas de esta lección sin ayuda, ordenadas por cercanía a lo que ya construiste; explicar por qué la cadena de suministro no aplica directamente a Andes Cargo hoy; y describir, con precisión, dónde agregarías un step de SAST si tuvieras que hacerlo mañana.
La lección 7 cierra el mapa de frontera con una vista distinta: no la seguridad que falta, sino el resto del ciclo de vida operacional que Andes Cargo todavía necesita —cómputo a escala, observabilidad de incidentes, y control de costos.
Recursos
- OWASP — SAST vs. DAST — panorama general de análisis estático y dinámico de seguridad, referencia neutral no ligada a ninguna herramienta comercial.
- Sigstore — cosign — documentación oficial de la firma de imágenes de contenedor, la pieza de cadena de suministro más citada del mercado actual.
- Open Policy Agent — Documentation — el motor de políticas de código abierto sobre el que
conftestestá construido, ya nombrado en el Módulo 6. cloud-security-and-guardrails-guide(NIEVA) — la guía que construye, de punta a punta, cada una de las cuatro piezas nombradas en esta lección.