Solución — Auditoría del pipeline de despliegue

Léelo después de haber intentado el recorrido guiado. Aquí está el detalle de cada hallazgo plantado, qué capa lo ve, por qué, y cómo se corrige.

Capa 1 — Composición (dependencias)

Deliberadamente no se listan aquí CVE concretas. Las diez dependencias fijadas de requirements.txt son versiones antiguas con vulnerabilidades conocidas, pero el conjunto exacto que reporte tu escáner depende del día: las bases de datos incorporan entradas nuevas cada semana y reclasifican severidades. Un solucionario con CVE fijas estaría obsoleto en meses y te enseñaría lo contrario de lo que importa.

Lo que sí debe aparecer siempre en tu análisis, y es lo evaluable:

La corrección de fondo no es "subir versiones", sino adoptar un lockfile con versiones y hashes (pip-compile, poetry.lock, uv.lock). Sin él, lo que instalas en producción no es necesariamente lo que escaneaste — y esa brecha es indefendible ante un auditor.

Capa 2 — SAST (código propio)

Los once patrones de app.py, con su corrección:

Cobertura esperada. Bandit y Semgrep no coinciden. Bandit es específico de Python y reconoce bien las llamadas peligrosas de la librería estándar (SAST-2 a SAST-8, SAST-11). Semgrep aporta reglas de la comunidad y suele ser más fuerte en patrones de framework y flujo de datos. La intersección no es el total: la unión tampoco. Documentar esa diferencia es el reto 1.

Falsos negativos que debes encontrar (reto 3). El más claro es SAST-9: muchos analizadores no siguen el flujo desde request.args hasta open() a través de os.path.join, porque exige análisis de propagación (taint analysis) y no un simple patrón sintáctico. También suele escaparse la ausencia total de autenticación y autorización en los endpoints: no hay ningún patrón inseguro que detectar — el fallo es lo que no está, y ninguna herramienta estática reporta ausencias de diseño. Eso es terreno de modelado de amenazas (clase 237).

Capa 3 — Secretos

config.py contiene varias credenciales, y no todas se detectan igual de bien:

Ese es el límite estructural de la capa: detecta lo que tiene forma de secreto conocido. Un token propio de tu empresa, sin prefijo ni formato distintivo, puede pasar desapercibido — y SECRET_KEY = "dev" no lo marca nadie, pese a ser un fallo grave en producción (firma de sesiones predecible). Encontrar ese último es trabajo de revisión humana, no de escáner.

Corrección, en orden:

1. Rotar todas las credenciales expuestas en el servicio emisor. Es el paso obligatorio.
2. Sacarlas del código: variables de entorno o gestor de secretos.
3. pre-commit con detección de secretos, para que no vuelva a ocurrir.
4. Opcionalmente, reescribir el historial — útil, pero nunca sustituye a rotar.

La capa que no controlas: protección del lado del servidor

Hay una defensa más, y este laboratorio se topó con ella al publicarse. La primera versión de config.py llevaba un webhook de Slack y una clave de Stripe con el formato exacto del proveedor. GitHub rechazó el push: su push protection analiza cada envío y bloquea los patrones de secreto de alta confianza.

Lo interesante es lo que ocurrió pese a que:

• los valores eran inventados y no autenticaban contra nada;
• el repositorio tiene una allowlist local (.gitleaks.toml) que excluye labs/ precisamente porque contiene material didáctico con secretos de ejemplo.

Nada de eso importó, y está bien que no importe: una protección que se puede desactivar desde el repositorio que protege no es una protección. De ahí tres conclusiones aplicables a tu trabajo:

1. Las capas se acumulan, no se sustituyen. pre-commit (tu máquina) → escáner en CI (tu pipeline) → push protection (la plataforma). Cada una atrapa lo que la anterior dejó pasar, y cada una está bajo un control distinto.
2. Tu configuración local no es la última palabra. Si dependes de una allowlist para que tu pipeline pase, tienes un problema de diseño, no de configuración.
3. Los detectores de alta confianza van por formato de proveedor. Por eso Slack y Stripe se bloquearon y, en cambio, DB_PASSWORD, SECRET_KEY = "dev" e INTERNAL_API_TOKEN no: no encajan en ningún patrón conocido. El secreto propio de tu empresa es el que más fácil se escapa, y es tan peligroso como el de un proveedor famoso.

Los dos valores quedaron neutralizados en el archivo, con la explicación dentro. La versión "realista" de ese fallo la puedes reproducir en un repositorio local tuyo, sin publicar.

Capa 4 — Dockerfile

La clasificación en tres cajas —seguridad, reproducibilidad, estilo— es el ejercicio. Un informe que presenta DKR-10 con la misma urgencia que DKR-7 pierde credibilidad ante quien tiene que arreglarlo.

Capa 5 — Contenedor

Trivy reporta las CVE de los paquetes del sistema operativo base. Con python:latest la lista suele ser larga, y la conclusión útil casi nunca es "parchear cada una":

• La mayoría no se arregla desde tu repositorio: vienen en la imagen base.
• La acción correcta es cambiar de imagen base — a una versión fija y reciente, a una variante -slim, o a una imagen mínima (distroless) que ni siquiera incluya shell.
• Reducir la imagen elimina vulnerabilidades por eliminación de superficie, no por parcheo. Es la remediación más eficiente y la menos aplicada.

Comprueba también cuántos de esos paquetes usa realmente tu aplicación. Casi siempre: ninguno.

Capa 6 — CI/CD

El fallo con más impacto real es CI-5 combinado con CI-2: la inyección permite ejecutar comandos y los permisos totales determinan hasta dónde llega esa ejecución. Por separado son graves; juntos son un compromiso completo del repositorio.

Ejemplo de la corrección de CI-5:

      - name: Registrar el cambio
        env:
          PR_TITLE: ${{ github.event.pull_request.title }}
        run: |
          echo "Desplegando: $PR_TITLE"

La diferencia es sutil y decisiva: en la versión insegura, el título se sustituye en el texto del script antes de ejecutarlo, así que su contenido se interpreta como comandos. En la versión corregida, llega como valor de una variable y el shell lo trata como dato.

Capa 7 — Suplantación de paquetes

requirements.txt termina con dos nombres que no existen en PyPI:

Lo decisivo: la capa 1 no reporta ninguno de los dos. No son versiones vulnerables de nada, así que no hay CVE que encontrar. Un escáner de composición te devuelve "sin hallazgos" para ellos, y técnicamente es cierto — y completamente engañoso.

Límite de la heurística, que hay que declarar en el informe: solo compara contra una lista de paquetes populares. Un paquete malicioso con nombre propio no lo detecta nadie por esta vía; para eso hacen falta catálogos de paquetes retirados o maliciosos (OSS Index, avisos del propio índice) y revisión de reputación —fecha de publicación, descargas, repositorio de origen—.

La corrección estructural no es "quitar estos dos": es fijar dependencias con lockfile y hashes y usar un registro interno con lista blanca. Con hashes, un paquete que no es el que esperabas ni siquiera se instala.

Capa 8 — Inteligencia y priorización

priorizar.py implementa la regla KEV → EPSS → CVSS ajustado. Con los datos de ejemplo, el orden que produce es la lección entera:

Una vulnerabilidad de 7.5 por encima de una de 9.8. Quien ordena por CVSS trabaja primero en la que nadie explota y que además no puede alcanzar, mientras deja abierta la que se está explotando hoy. Ese es el coste de priorizar con una sola señal.

Comprobaciones que debes saber justificar:

• KEV es binario y manda. No admite matices: o hay explotación documentada o no la hay.
• EPSS es probabilístico. Describe el ecosistema, no tu entorno. Por eso va después de KEV y antes de CVSS.
• La exposición la pones tú. Es el único dato que ninguna API entrega, y el que más mueve el orden. Si no la declaras, el script aplica el factor conservador (0.8), nunca el mejor caso.
• Sin red, el plan es provisional. El informe lo encabeza. Una señal no consultada no vale cero.

Mapa completo hallazgo → capa

Este es el entregable del reto 1. Las casillas que importan son las que tienen una sola marca: prueban por qué hacen falta las ocho capas.

Dos filas concentran la moraleja:

• requets solo lo marca la capa 7. Es el hallazgo más grave de la lista —ejecución de código arbitrario en tu máquina y en tu pipeline— y las seis primeras capas son ciegas a él.
• La falta de autenticación no la marca ninguna. La automatización cubre los fallos que tienen forma reconocible; los fallos de diseño siguen siendo tuyos.