--- title: CD (Entrega Continua) — Parte 2: Image Scan y Service Tests url: https://jarroba.com/cd-entrega-continua-parte-2-image-scan-y-service-tests/ 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 2: Image Scan y Service Tests", Ramón Invarato, jarroba.com categories: Ingeniería del Software, Inteligencia Artificial tags: ci-cd, devops, docker, seguridad, service-tests, testing series: CI/CD y la IA: De la teoría a la práctica (part 7 of 11) --- # CD (Entrega Continua) — Parte 2: Image Scan y Service Tests > Escaneo de vulnerabilidades en la imagen de contenedor y validación del servicio con pruebas de contrato, endpoints y dependencias. > Esta parte cubre el escaneo de vulnerabilidades de la imagen de contenedor y las pruebas de servicio (service tests) que validan que el servicio funciona correctamente antes de los despliegues. ## Image Scan Sirve para detectar vulnerabilidades, errores de configuración y secretos en la imagen de contenedor antes de que llegue a entornos ejecutables. El escaneo extrae un inventario de paquetes (similar a un SBOM) y lo cruza con bases de datos de vulnerabilidades (NVD, OSV, repositorios de distribuciones) para identificar CVE y problemas de configuración. [![](https://jarroba.com/wp-content/uploads/2026/04/1-CD-Entrega-Continua-—-Parte-2-Image-Scan-y-Service-Tests-Image-Scan-www.jarroba.com_-990x1024.png)](https://jarroba.com/wp-content/uploads/2026/04/1-CD-Entrega-Continua-—-Parte-2-Image-Scan-y-Service-Tests-Image-Scan-www.jarroba.com_.png) ### Pasos que incluyen en esta etapa del pipeline 1. **Obtener la imagen**: usar la imagen recién construida o descargar la imagen publicada en el registry. 2. **Ejecutar el escáner** contra la imagen local o el tar exportado ([Trivy](https://trivy.dev/), [Grype](https://github.com/anchore/grype), [Snyk](https://docs.snyk.io/scan-with-snyk/snyk-container/scan-container-images), [Docker Scout](https://docs.docker.com/scout/)). 3. **Configurar umbrales y exit codes** para que el job falle si aparecen vulnerabilidades de severidad alta/critical según la política. 4. **Generar salida estructurada** (JSON, SARIF) para ingestión por otras herramientas y para crear tickets automáticos. 5. **Correlacionar con SBOM** para reducir falsos positivos y priorizar remediación (el SBOM permite saber si un paquete realmente está en la imagen y en qué capa). 6. **Actuar según resultados**: continuar pipeline, crear ticket de remediación o bloquear despliegue según severidad y política. ### Buenas prácticas - **Escanear siempre la imagen final** que se va a publicar; no solo las capas base. - **Integrar el escaneo en CI** para que cada build/PR pase por el control antes del merge. - **Usar SBOM** para correlación y priorización; generar SBOM en el mismo job de build para garantizar consistencia. - **Definir políticas claras** (qué severidades fallan el pipeline, qué se crea como ticket). - **Escanear imágenes en el registry periódicamente**, porque las bases de datos de CVE se actualizan continuamente. ### Ventajas - **Prevención temprana**: evita que imágenes vulnerables lleguen a entornos productivos. - **Automatización**: integración CI/CD permite bloqueo automático y trazabilidad. - **Mejor priorización** con SBOM: reduce ruido y acelera respuesta. ### Desventajas - **Falsos positivos** si no se correlaciona con SBOM o contexto de ejecución. - **Coste en tiempo** en pipelines si no se optimiza (cachés, escaneo incremental). - **Mantenimiento de políticas**: definir umbrales adecuados requiere gobernanza y ajuste continuo. ### Herramientas y ejemplos de comandos Trivy: ```bash trivy image --format json --output trivy.json --severity HIGH,CRITICAL myapp:latest ``` Grype: ```bash grype myapp:latest -o json > grype.json ``` Escaneo desde archivo tar (útil en runners sin daemon): ```bash podman save -o /tmp/myapp.tar myapp:scan trivy image --input /tmp/myapp.tar --severity HIGH,CRITICAL --exit-code 1 ``` Generar SBOM con [Syft](https://github.com/anchore/syft) (salida SARIF/JSON para ingestión en dashboards o creación automática de issues): ```bash syft myapp:latest -o cyclonedx-json > sbom.json ``` ### IA **No sustituye** el escaneo técnico: la IA no puede ejecutar el análisis ni generar SBOMs reales. Actúa como asistente de decisión y automatización, no como reemplazo del escáner. **Sí mejora** el proceso en varias áreas: - **Priorizar findings** combinando contexto de negocio y explotación real. - **Sugerir remediaciones** (versiones seguras, parches, cambios en Dockerfile) y generar PRs automáticos. - **Reducir ruido** identificando falsos positivos y agrupando findings relacionados. - **Analizar tendencias** y predecir qué imágenes/paquetes son más propensos a generar problemas. ## Service Tests (pruebas de servicio / componente) El objetivo es verificar que el servicio funciona correctamente en condiciones reales o realistas: validar endpoints, contratos, serialización, autenticación, comportamiento frente a dependencias externas y respuestas ante errores. Los *service tests* se sitúan entre los tests de integración y las pruebas E2E (end-to-end): ejercitan el servicio desplegado (o en un entorno muy cercano al real) contra dependencias simuladas o reales para asegurar que la lógica del servicio y sus integraciones críticas se comportan como se espera. [![](https://jarroba.com/wp-content/uploads/2026/04/2-CD-Entrega-Continua-—-Parte-2-Image-Scan-y-Service-Tests-Service-Tests-www.jarroba.com_-1024x575.png)](https://jarroba.com/wp-content/uploads/2026/04/2-CD-Entrega-Continua-—-Parte-2-Image-Scan-y-Service-Tests-Service-Tests-www.jarroba.com_-scaled.png) ### Pasos de esta etapa 1. **Desplegar el servicio en un entorno efímero o usar un entorno Dev** con la misma configuración de runtime que producción. 2. **Validación de contratos**: comprobar que el servicio cumple su *API contract* (OpenAPI / gRPC) y que las respuestas respetan esquemas y tipos. 3. **Pruebas funcionales de endpoints**: llamadas a rutas críticas (autenticación, autorización, flujos de negocio) con datos reales o sintéticos. 4. **Pruebas de integración con dependencias**: bases de datos, colas, caches, servicios externos; usar test doubles (mocks/stubs) cuando sea necesario. 5. **Validación de serialización y compatibilidad**: comprobar formatos JSON, headers, códigos HTTP y manejo de errores. 6. **Medición de latencia y SLAs básicos**: comprobar que endpoints críticos cumplen latencias aceptables. 7. **Generación de reportes estructurados** (logs, JSON, SARIF) para trazabilidad y para alimentar gates posteriores. ### Buenas prácticas - **Validar contratos antes de la integración completa** para detectar pronto los breaking changes (cambios que rompen la compatibilidad). - **Usar entornos efímeros** que reproduzcan la configuración de producción (variables, secrets en modo seguro). - **Separar pruebas rápidas y exhaustivas**: en PRs ejecutar subset crítico; en pipeline de rama destino ejecutar suite completa. - **Aislar flakiness** (pruebas que a veces pasan y a veces fallan): retries controlados, timeouts razonables y limpieza de recursos. - **Medir y registrar SLAs** (latencia, errores) y fallos reproducibles con trazas y dumps. - **Integrar resultados con Quality Gates** para que fallos críticos bloqueen el despliegue. - **Automatizar contract verification** entre productores y consumidores para evitar regresiones en microservicios. ### Flakiness: pruebas inestables Una prueba *flaky* es aquella que presenta un comportamiento inconsistente: **a veces pasa y a veces falla**, sin que se haya realizado ningún cambio en el código o en el entorno. Es uno de los problemas más frustrantes en el desarrollo moderno porque rompe la confianza en el pipeline de automatización. > Es mejor tener una suite pequeña y 100% confiable que una suite gigante donde el 5% de las pruebas fallan de forma aleatoria. #### ¿Por qué ocurre? - **Condiciones de Carrera (Race Conditions)**: el resultado depende del orden en que se ejecutan hilos o procesos asíncronos. - **Problemas de Red**: microservicios o APIs externas que tardan en responder o fallan momentáneamente. - **Dependencia del Orden**: una prueba que solo pasa si se ejecuta después de otra (porque la anterior dejó datos en la base de datos). - **Falta de Aislamiento**: pruebas que comparten recursos como archivos o memoria y se interfieren entre sí. - **Timeouts Ajustados**: pruebas que fallan en el servidor de CI porque es más lento que la máquina local del desarrollador. #### El impacto en el pipeline - **Pérdida de Confianza**: los desarrolladores empiezan a ignorar los fallos, asumiendo que “es solo la prueba de siempre”, lo que permite que errores reales pasen a producción. - **Desperdicio de Tiempo**: se gasta tiempo valioso re-ejecutando builds manualmente para ver si “esta vez sí pasa”. - **Cuellos de Botella**: un pipeline bloqueado por una prueba flaky detiene el despliegue de características críticas. #### ¿Cómo gestionarlo? 1. **Cuarentena de Pruebas**: si se detecta que una prueba es flaky, se mueve a un grupo separado que no bloquea el despliegue hasta que sea reparada. 2. **Retries Automáticos**: configurar el CI para que re-ejecute una prueba fallida inmediatamente. Si pasa al segundo o tercer intento, se marca como flaky. 3. **Logs Detallados**: capturar capturas de pantalla (en pruebas de UI) o logs de red en el momento exacto del fallo para identificar la causa raíz. 4. **Aislamiento de Datos**: asegurar que cada prueba cree y destruya sus propios datos, evitando el estado compartido. ### Ventajas - **Detección temprana de fallos de integración** antes de entornos superiores. - **Mayor confianza en despliegues** porque el servicio se prueba en condiciones cercanas a producción. - **Reducción de regresiones entre servicios** cuando se combinan con contract testing. ### Desventajas - **Coste en tiempo y recursos**: levantar entornos y dependencias incrementa la duración del pipeline. - **Complejidad operativa**: mantener entornos efímeros, datos de prueba y flujos de limpieza. - **Flakiness** si las dependencias externas no están bien simuladas o si los tests dependen de datos volátiles. ### Herramientas y ejemplos prácticos - **Contract testing**: [Pact](https://docs.pact.io/), [Postman Contract Tests](https://www.postman.com/templates/collections/contract-testing/), o herramientas que validan [OpenAPI](https://www.openapis.org/)/[gRPC](https://grpc.io/); se usan para asegurar compatibilidad productor/consumidor. - **Frameworks de tests HTTP**: [JUnit](https://junit.org/) + [RestAssured](https://rest-assured.io/) (Java), [pytest](https://docs.pytest.org/en/stable/) + [requests](https://requests.readthedocs.io/en/latest/) (Python), [SuperTest](https://www.npmjs.com/package/supertest) (Node.js). - **Entornos efímeros**: [TestContainers](https://testcontainers.com/), [Docker Compose](https://docs.docker.com/compose/) para levantar dependencias reales en CI. - **Simulación de dependencias**: [WireMock](https://wiremock.org/), [MockServer](https://www.mock-server.com/), [mountebank](https://www.mbtest.dev/). - **Orquestación y ejecución**: jobs en GitHub Actions / GitLab CI que despliegan la imagen en un namespace efímero y ejecutan suites de service tests. **Ejemplo con TestContainers (Java):** ```java // Pseudocódigo: levantar DB y ejecutar tests contra el servicio PostgresContainer postgres = new PostgresContainer("postgres:15"); postgres.start(); // arrancar servicio con configuración apuntando a postgres.getJdbcUrl() // ejecutar tests de integración/servicio ``` ### IA **No sustituye** la ejecución real de pruebas ni la verificación determinista de contratos. Actúa como **asistente de productividad y priorización**, no como reemplazo del testeo real. **Sí mejora** el proceso en varias áreas: - **Generación de casos de prueba**: crear tests que cubran rutas no probadas y casos límite. - **Diagnóstico automático**: analizar fallos de tests, agrupar errores relacionados y proponer la causa raíz. - **Sugerencia de mocks y fixtures**: proponer datos de prueba realistas y configuraciones para entornos efímeros. - **Automatización de PRs de remediación**: generar cambios en código o en contratos cuando se detectan incompatibilidades. - **Priorización inteligente**: combinar impacto de negocio con frecuencia de fallo para ordenar remediaciones. [En el siguiente artículo, **“CD — Parte 3: Deploy a Dev y Smoke Tests”**, pasaremos del análisis a la acción: desplegaremos el servicio en el entorno de desarrollo y ejecutaremos smoke tests para validar que está vivo, responde y es apto para promoción.](https://jarroba.com/cd-entrega-continua-parte-3-deploy-a-dev-y-smoke-tests/) ## 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)