SCA: Análisis de Dependencias con Docker Scout

SCA (Software Composition Analysis) es el proceso de analizar las dependencias de terceros (librerías, paquetes, frameworks) para encontrar vulnerabilidades de seguridad conocidas (CVEs).

En HERA, nuestra herramienta principal para SCA es Docker Scout, que se integra directamente en nuestro pipeline para analizar las imágenes de contenedor.

¿Por qué SCA es Crítico?

En una aplicación moderna, más del 80% del código proviene de dependencias de código abierto. Si bien esto acelera el desarrollo, también significa que heredamos las vulnerabilidades de esos paquetes. SCA analiza ese 80% que SAST no puede cubrir.

---

¿Cómo funciona Docker Scout en HERA?

Docker Scout se ejecuta en la etapa de package de nuestro pipeline, justo después de que la imagen de tu aplicación ha sido construida y subida a nuestro registro.

1. Construcción de Imagen: El pipeline construye tu Dockerfile.
2. Análisis de Capas: Docker Scout descompone la imagen en sus capas y genera un SBOM (Software Bill of Materials), que es un inventario completo de todo el software dentro de la imagen. Esto incluye:
   • El sistema operativo base (ej. Alpine, Debian).
   • Paquetes del sistema instalados (ej. curl, openssl).
   • El runtime del lenguaje (ej. Node.js, Python, JRE).
   • Las dependencias de tu aplicación (ej. paquetes de npm, pip, maven).
3. Cruce con Bases de Datos de CVEs: Compara cada componente del SBOM con múltiples bases de datos de vulnerabilidades.
4. Reporte y Quality Gate: Genera un reporte y, lo más importante, hace fallar el pipeline si se encuentran vulnerabilidades que violan nuestra política de seguridad.

---

Integración en el Pipeline

El job sca-docker-scout es un paso mandatorio del Golden Pipeline y corre después del build de la imagen. El equipo de producto no escribe este job a mano — se hereda del template vía include:.

Contrato del job sca-docker-scout

Atributo	Valor
Stage	package (o security post-package, según versión del template)
Imagen base	Docker CLI con Docker-in-Docker (dind)
Dependencia	needs: docker-build — la imagen debe estar construida antes
Comando	docker scout cves <imagen>:<tag> --exit-code --only-severity critical,high
Variables inyectadas	IMAGE_NAME, CI_COMMIT_SHA (ambas provistas por el template y GitLab)
allow_failure	false — bloqueante
Quality Gate	Pipeline falla si se detectan 1+ vulnerabilidades critical o high

El Quality Gate en detalle

Flag	Efecto
--exit-code	El comando termina con código de error si hay vulnerabilidades → el job de GitLab CI falla
--only-severity critical,high	Solo Critical y High bloquean; Medium y Low se reportan pero no rompen el pipeline

Política de Bloqueo HERA

Un pipeline fallará automáticamente y el despliegue será bloqueado si Docker Scout detecta una o más vulnerabilidades de severidad Crítica o Alta en la imagen del contenedor.

Implementación canónica en el Golden Pipeline

La definición exacta del job (imagen Docker con versión pineada, services:, rules:, manejo de tags vs. SHA) vive en grupo-herdez/platform/pipelines/gitlab-ci/ bajo el stage package/security. El portal documenta el contrato observable; el código canónico vive en el template para evitar drift.

---

Flujo de Remediación

Si tu pipeline falla en el paso de sca-docker-scout, sigue el flujo de remediación:

Flujo de Remediación — Docker Scout

Ejemplo de reporte en el pipeline

2

CRITICAL

5

HIGH

12

MEDIUM

CRITICAL CVE-2023-4567 lodash@4.17.20 → Fix: lodash@4.17.21

HIGH CVE-2023-8901 openssl@3.0.1 → Fix: actualizar imagen base

1

Identifica la fuente

Dependencia de la App package.json, requirements.txt, pom.xml…

Paquete del Sistema Imagen base en tu Dockerfile

2

Aplica la corrección

Para dependencias de la app

npm install lodash@4.17.21

Para paquetes del sistema

FROM node:20.11.1-alpine # ← versión parcheada

3

Haz commit y push — el pipeline se re-ejecuta

Si la corrección fue exitosa, el job sca-docker-scout pasará automáticamente.

Mensaje clave Vulnerabilidad detectada → pipeline falla → equipo notificado → fix → re-scan → deploy.

---

¿Por qué Docker Scout y no Trivy o Snyk?

La elección de Docker Scout como herramienta SCA estándar de HERA fue una decisión arquitectónica deliberada. El mercado ofrece alternativas válidas — Trivy (open source de Aqua Security) y Snyk (SaaS comercial) son las más populares. Esta sección explica el razonamiento.

Comparativa de las 3 herramientas

Criterio	Docker Scout	Trivy	Snyk
Modelo	SaaS integrado a Docker Hub + CLI	Open source (binario standalone)	SaaS comercial
Costo	Incluido en Docker Business / Pro	Gratuito	Subscription por desarrollador
Setup en pipeline	Trivial — viene con Docker CLI	Trivial — descargar binario	Requiere cuenta + token
Cobertura SCA	Vulns OS + dependencias de aplicación	Vulns OS + deps + IaC + secrets	Vulns OS + deps + licenses + IaC
Cobertura SAST	No	Limitado	Sí (Snyk Code)
Bases de datos CVE	NVD + GitHub Advisory + propietarias	NVD + GitHub Advisory + Aqua	NVD + Snyk DB propietaria
SBOM nativo	Sí (SPDX, CycloneDX)	Sí (SPDX, CycloneDX)	Sí (CycloneDX)
Integración con Docker Hub	Nativa	Manual	Manual
Integración con GCP	Compatible (no nativa)	Compatible (no nativa)	Compatible (no nativa)
Velocidad de escaneo	Rápida	Muy rápida	Rápida
Reporting / Dashboard	Docker Scout web UI	CLI (sin dashboard nativo)	Snyk web UI completo
Vendor lock-in	Bajo (genera SBOM portable)	Ninguno	Medio-alto
Precio enterprise	Incluido en suscripción Docker	$0 (open source)	$$$ por usuario

Razones de la decisión HERA

Razón	Detalle
1. Integración nativa con Docker	HERA ya usa Docker en todo el pipeline. Docker Scout no requiere herramientas adicionales — docker scout cves funciona out-of-the-box.
2. Costo predecible	Incluido en la suscripción de Docker que la organización ya tiene. No hay licencia adicional por desarrollador como Snyk.
3. SBOM portable	Docker Scout genera SBOMs en formato estándar (SPDX, CycloneDX), evitando vendor lock-in. Si migramos a Trivy mañana, los SBOMs siguen siendo válidos.
4. Calidad de la base de CVEs	Combina NVD + GitHub Advisory + bases propietarias, comparable a Snyk en cobertura.
5. Operación simple	Un solo comando, una sola herramienta para mantener. Trivy es excelente pero requiere gestionar binarios y actualizaciones.
6. Curva de aprendizaje	Docker es lenguaje universal en HERA. Cualquier dev entiende docker scout sin documentación adicional.

Cuándo evaluaríamos cambiar de herramienta

Estas son las señales que dispararían una revisión de la decisión:

Trigger	Acción
Docker Scout deja de soportar SBOM CycloneDX o SPDX	Evaluar Trivy
Costos de Docker suscripción aumentan significativamente	Evaluar Trivy (open source)
Necesitamos SAST + SCA en una sola herramienta	Evaluar Snyk Code
Compliance requiere análisis de licencias avanzado	Evaluar Snyk Open Source o FOSSA
Necesidades de IaC scanning crecen	Trivy ya cubre IaC; sería complemento

Compatibilidad con el ecosistema HERA

Docker Scout se integra naturalmente con el resto de la cadena DevSecOps de HERA:

Herramienta	Función	Conexión con Docker Scout
SonarQube	SAST (código fuente)	Complementario — Docker Scout no hace SAST
TruffleHog	Detección de secretos	Complementario — diferentes capas
OWASP ZAP	DAST (runtime)	Complementario — diferentes momentos del SDLC
Cosign	Image signing	Docker Scout SBOM + Cosign attestation = supply chain completa
Syft + Grype	Generación y análisis de SBOMs	Funciona junto, no compite

La decisión es revisable

La decisión de usar Docker Scout es revisable — cada año el equipo de Plataforma evalúa el ecosistema. Si Trivy o Snyk evolucionan a un punto donde aportan valor superior con costo justificable, se hace la migración. Hoy (2026), Docker Scout es la mejor relación valor/costo para HERA.