--- title: CD (Entrega Continua) — Parte 1: empaquetado, SBOM y remediación url: https://jarroba.com/cd-entrega-continua-parte-1-empaquetado-sbom-y-remediacion/ author: Ramón Invarato date: 2026-04-20 modified: 2026-10-21 language: es license: CC BY-NC-SA 3.0 (https://creativecommons.org/licenses/by-nc-sa/3.0/) — attribution: "CD (Entrega Continua) — Parte 1: empaquetado, SBOM y remediación", Ramón Invarato, jarroba.com categories: Ingeniería del Software, Inteligencia Artificial tags: arquitectura, ci-cd, devops, docker, sbom, seguridad series: CI/CD y la IA: De la teoría a la práctica (part 6 of 11) --- # CD (Entrega Continua) — Parte 1: empaquetado, SBOM y remediación > Inicio del ciclo de entrega continua: Docker packaging, generación de SBOM, firmado de imagen y el concepto de 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. [![](https://jarroba.com/wp-content/uploads/2026/04/1-CD-Entrega-Continua-—-Parte-1-empaquetado-SBOM-y-remediacion-arquitectura-CD-completa-www.jarroba.com_-1-215x1024.png)](https://jarroba.com/wp-content/uploads/2026/04/1-CD-Entrega-Continua-—-Parte-1-empaquetado-SBOM-y-remediacion-arquitectura-CD-completa-www.jarroba.com_-1-scaled.png) 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](https://kubernetes.io/), [Docker Swarm](https://docs.docker.com/engine/swarm/), [Azure Container Instances](https://azure.microsoft.com/en-us/products/container-instances), [AWS Fargate](https://aws.amazon.com/es/fargate/), etc.). [![](https://jarroba.com/wp-content/uploads/2026/04/2-CD-Entrega-Continua-—-Parte-1-empaquetado-SBOM-y-remediacion-Docker-packaging-y-SBOM-www.jarroba.com_-490x1024.png)](https://jarroba.com/wp-content/uploads/2026/04/2-CD-Entrega-Continua-—-Parte-1-empaquetado-SBOM-y-remediacion-Docker-packaging-y-SBOM-www.jarroba.com_.png) ### Pasos que incluyen en esta etapa del pipeline 1. **Construcción de la imagen** usando [Docker/BuildKit](https://docs.docker.com/build/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](https://www.syftanalytics.com/), [Docker Scout](https://docs.docker.com/scout/) → [CycloneDX/SPDX](https://cyclonedx.org/tool-center/)). El SBOM debe reflejar capas, paquetes del sistema, dependencias de lenguaje y artefactos incluidos. 3. **Firmado y almacenamiento** del artefacto y del SBOM ([cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/) / [Notation](https://github.com/notaryproject/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](https://trivy.dev/) / [Grype](https://github.com/anchore/grype) / [Snyk](https://docs.snyk.io/scan-with-snyk/snyk-container/scan-container-images)) 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](https://cyclonedx.org/), [SPDX](https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Classes/Sbom/)) 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: ```dockerfile 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: ```dockerfile # 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): ```bash syft : -o cyclonedx-json > sbom-cyclonedx.json syft : -o spdx-json > sbom-spdx.json ``` Docker Scout (verificación): ```bash docker scout sbom : ``` Firmar imagen y SBOM con cosign: ```bash cosign sign --key cosign.key /: ``` ### 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. [![](https://jarroba.com/wp-content/uploads/2026/04/3-CD-Entrega-Continua-—-Parte-1-empaquetado-SBOM-y-remediacion-remediacion-www.jarroba.com_-551x1024.png)](https://jarroba.com/wp-content/uploads/2026/04/3-CD-Entrega-Continua-—-Parte-1-empaquetado-SBOM-y-remediacion-remediacion-www.jarroba.com_.png) Por ejemplo: - Si Trivy detecta una CVE crítica → hay que remediarla. - Si [SonarQube](https://www.sonarsource.com/products/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](https://www.atlassian.com/es/software/jira), [GitHub Issues](https://github.com/features/issues), [ServiceNow](https://www.servicenow.com/), 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. ## Serie: CI/CD y la IA: De la teoría a la práctica 1. [CI/CD: Introducción — qué es, por qué importa y quién lo hace](https://jarroba.com/ci-cd-introduccion-que-es-por-que-importa-y-quien-lo-hace.md) 2. [CI/CD: Conceptos básicos — pipeline, job, stage, step y gates](https://jarroba.com/ci-cd-conceptos-basicos-pipeline-job-stage-step-y-gates.md) 3. [CI/CD: Branching, Git Flow y Pull Requests](https://jarroba.com/ci-cd-branching-git-flow-y-pull-requests.md) 4. [Pre-CI: Arquitectura general del pipeline CI/CD y comprobaciones previas](https://jarroba.com/pre-ci-arquitectura-general-del-pipeline-ci-cd-y-comprobaciones-previas.md) 5. [CI (Integración Continua): análisis, tests, calidad y seguridad](https://jarroba.com/ci-integracion-continua-analisis-tests-calidad-y-seguridad.md) 6. [CD (Entrega Continua) — Parte 1: empaquetado, SBOM y remediación](https://jarroba.com/cd-entrega-continua-parte-1-empaquetado-sbom-y-remediacion.md) 7. [CD (Entrega Continua) — Parte 2: Image Scan y Service Tests](https://jarroba.com/cd-entrega-continua-parte-2-image-scan-y-service-tests.md) 8. [CD (Entrega Continua) — Parte 3: Deploy a Dev y Smoke Tests](https://jarroba.com/cd-entrega-continua-parte-3-deploy-a-dev-y-smoke-tests.md) 9. [CD (Entrega Continua) — Parte 4: Deploy a Staging y Performance Smoke Tests](https://jarroba.com/cd-entrega-continua-parte-4-deploy-a-staging-y-performance-smoke-tests.md) 10. [CD (Entrega Continua) — Parte 5: LCA — Load, Stress y Chaos Engineering](https://jarroba.com/cd-entrega-continua-parte-5-lca-load-stress-y-chaos-engineering.md) 11. [CD (Entrega Continua) — Parte 6: Validaciones finales, Manual Approval y Deploy a Producción](https://jarroba.com/cd-entrega-continua-parte-6-validaciones-finales-manual-approval-y-deploy-a-produccion.md)