CD (Entrega Continua) — Parte 1: empaquetado, SBOM y remediación

Esta es la primera parte del bloque de CD. Cubre la transición desde el CI, la arquitectura general del CD, la construcción y firmado de la imagen de contenedor, la generación del SBOM y el concepto de remediación que atraviesa todo el ciclo.

De CI a CD: el merge como punto de partida

Una vez que el CI aprueba todos los gates, se permite el merge. A partir de ese momento, dependiendo de la rama destino, se lanza el CD:

• Merge a develop → CI en la rama destino y luego CD hacia Dev
• Merge a release/x.y → CI en la rama destino y luego CD hacia Preprod
• Merge a main → CI en la rama destino y luego CD hacia Producción

En la mayoría de los equipos se prescinde de ejecutar el CI completo en la rama previa al merge y solo se corre el CI/CD sobre las ramas principales (develop, release, main), para evitar duplicar ejecuciones idénticas.

Arquitectura general del CD

El CD (Continuous Delivery / Entrega Continua) toma el artefacto verificado por el CI y lo lleva, de forma progresiva y controlada, hasta producción.

Cada etapa es una compuerta de calidad: si algo falla, el pipeline se detiene, se crea un ticket de remediación y el cambio no avanza al siguiente entorno.

Docker Packaging y SBOM

Construye la imagen de contenedor de forma reproducible, mínima y verificable, y genera un SBOM (Software Bill of Materials) que documenta todos los componentes incluidos en la imagen. El SBOM es parte del control de la cadena de suministro y facilita la gestión de vulnerabilidades, la auditoría y el cumplimiento.

Da como resultado una imagen lista para ejecutarse en un contenedor (por ejemplo, en Kubernetes, Docker Swarm, Azure Container Instances, AWS Fargate, etc.).

Pasos que incluyen en esta etapa del pipeline

1. Construcción de la imagen usando Docker/BuildKit con multi-stage builds para separar fase de compilación y runtime (esto reduce el tamaño y la superficie de ataque).
2. Generación del SBOM inmediatamente tras la construcción (herramientas: Syft, Docker Scout → CycloneDX/SPDX). El SBOM debe reflejar capas, paquetes del sistema, dependencias de lenguaje y artefactos incluidos.
3. Firmado y almacenamiento del artefacto y del SBOM (cosign / Notation) para garantizar procedencia y no repudio.
4. Publicación en registry (imagen + SBOM como artefacto asociado) y registro del SBOM en el sistema de gestión de SBOMs de la organización.
5. Trigger de image scan (Trivy / Grype / Snyk) usando la imagen publicada y el SBOM para correlacionar vulnerabilidades y priorizar la remediación.

Nota: la remediación es el conjunto de acciones para corregir una vulnerabilidad, fallo de calidad o incumplimiento detectado. Se detalla en la sección siguiente.

Buenas prácticas

• Multi-stage builds para eliminar herramientas de compilación del runtime.
• Imágenes mínimas (distroless, scratch) para reducir superficie de ataque.
• SBOM en formatos estándar (CycloneDX, SPDX) y versionado junto a la imagen.
• SBOM firmado y almacenado en el registry o en un repositorio de SBOMs con trazabilidad.
• Determinismo: usar cachés controlados, versiones fijas y reproducible builds para que la imagen y su SBOM sean verificables.

Recomendaciones

• Genera SBOM en el mismo job que construye la imagen para garantizar consistencia.
• Firma imagen y SBOM antes de publicar.
• Almacena SBOM junto a la imagen en el registry o en un repositorio centralizado para auditoría.
• Correlaciona SBOM con scanners para reducir falsos positivos y priorizar la remediación.

Ventajas

• Transparencia de la cadena de suministro: permite identificar rápidamente componentes vulnerables.
• Cumplimiento y auditoría: facilita requisitos regulatorios y auditorías.
• Respuesta a incidentes más rápida: con SBOM puedes localizar rápidamente lo que ha sido afectado.

Desventajas / retos

• Ruido y mantenimiento: SBOMs grandes requieren procesos para mantenerlos útiles (filtrado, correlación).
• Coste operativo: generación, firma, almacenamiento y correlación con scanners añade pasos y tiempo.
• Falsos positivos en scanners si no se correlaciona correctamente con SBOM y contexto de ejecución.

Ejemplo: Docker multi-stage

Un flujo típico para una aplicación Spring Boot:

1. Build/Compilation — mvn -DskipTests package → genera target/app.jar
2. Docker multi-stage — copia el JAR ya generado:

FROM eclipse-temurin:17-jre
COPY app.jar /app/app.jar
CMD ["java", "-jar", "/app/app.jar"]

¿No se puede condensar en una sola etapa con multi-stage de Docker?

Sí, pero no es la opción más profesional. Ejemplo:

# Etapa de "Compilation / Build"
FROM maven:3.9 AS build
WORKDIR /app
COPY . .
RUN mvn package -DskipTests

# Etapa de "Empaquetado en una imagen"
FROM eclipse-temurin:17-jre
COPY --from=build /app/target/app.jar /app/app.jar
CMD ["java", "-jar", "/app/app.jar"]

Sus desventajas:

• Más lento: cada cambio en pom.xml invalida la cache.
• No puedes escanear el JAR antes de empaquetarlo.
• No puedes publicar el artefacto sin construir la imagen.
• SonarQube no puede analizar el código dentro del contenedor.
• Menos flexible para pipelines complejos.

Ejemplos de comandos

Generar SBOM con Syft (CycloneDX o SPDX):

syft <image>:<tag> -o cyclonedx-json > sbom-cyclonedx.json
syft <image>:<tag> -o spdx-json > sbom-spdx.json

Docker Scout (verificación):

docker scout sbom <image>:<tag>

Firmar imagen y SBOM con cosign:

cosign sign --key cosign.key <registry>/<image>:<tag>

IA

No sustituye la etapa: la IA no puede ejecutar builds, producir SBOMs reales ni firmar artefactos por sí sola.

Sí la mejora en varias áreas prácticas:

• Optimización de Dockerfile: sugerencias para reducir capas, eliminar paquetes innecesarios, sugerir mejores bases (distroless, alpine, slim), detectar malas prácticas (COPY . ., RUN apt-get update sin pinning) y proponer patrones multi-stage.
• Generación de SBOM enriquecida: correlación automática entre dependencias y vulnerabilidades históricas; priorización de remediación.
• Automatización de remediación: propuestas de versiones seguras o parches, generación de PRs con cambios en dependencias o Dockerfile.
• Análisis de procedencia: ayuda a identificar paquetes con baja trazabilidad o licencias problemáticas.

Anexo: La remediación

Es el conjunto de acciones necesarias para corregir una vulnerabilidad, fallo de calidad o incumplimiento detectado por el pipeline. Dicho de otra manera: remediar es arreglar lo que rompe algún Quality Gate.

Por ejemplo:

• Si Trivy detecta una CVE crítica → hay que remediarla.
• Si SonarQube detecta una vulnerabilidad o bug bloqueante → hay que remediarlo.
• Si el Coverage Gate falla → hay que remediar añadiendo tests.
• Si SCA detecta una dependencia vulnerable → hay que remediar actualizando la versión.

La remediación incluye

• Actualizar dependencias: subir versión de una librería vulnerable, cambiar a una alternativa segura, aplicar un parche recomendado.
• Modificar código: arreglar un bug, corregir una vulnerabilidad (SQLi, XSS, SSRF …), reducir complejidad, eliminar duplicación, añadir validaciones.
• Añadir o mejorar tests: aumentar cobertura, añadir tests de borde, añadir tests de integración.
• Cambiar configuración: ajustar permisos, endurecer contenedores, cambiar flags de compilación, ajustar políticas de seguridad.

Cuándo se crea un ticket automático

Cuando el pipeline detecta un problema que no se puede arreglar automáticamente o que no debe bloquear el flujo, se recomienda crear automáticamente un ticket en Jira, GitHub Issues, ServiceNow, etc. Ese ticket suele incluir:

• Descripción del problema y severidad
• Evidencia (logs, reportes, CVE, findings)
• Recomendación de remediación y prioridad
• SLA (tiempo máximo para arreglarlo)
• Enlace al commit o PR que lo introdujo
• Enlace al reporte del scanner (Trivy, Sonar, Snyk …)

¿Cuándo se crea?

• Cuando la vulnerabilidad es alta o crítica, pero no se quiere bloquear el pipeline (por ejemplo, en entornos no productivos).
• Cuando el problema requiere análisis humano.
• Cuando la remediación no es trivial.
• Cuando hay dependencias externas (proveedor, equipo de plataforma …).

IA

La IA no puede sustituir la remediación ni debe:

• Validar que el parche es seguro en producción.
• Sustituir el análisis humano en vulnerabilidades complejas.
• Tomar decisiones de riesgo corporativo.

La IA puede acelerar la remediación al:

• Generar el parche automáticamente.
• Explicar la vulnerabilidad.
• Proponer la versión segura de una dependencia.
• Crear el ticket con toda la información ya rellenada.
• Priorizar findings según impacto real.
• Detectar falsos positivos.
• Sugerir refactors para reducir complejidad.
• Generar tests para aumentar cobertura.
• Analizar el SBOM y proponer mitigaciones.

En el siguiente artículo, “CD — Parte 2: Image Scan y Service Tests”, veremos cómo se analiza la imagen construida en busca de vulnerabilidades y cómo se valida el servicio real mediante pruebas de contrato, endpoints y dependencias antes de cualquier despliegue.