Cómo escanear vulnerabilidades Docker con Trivy: guía completa 2026

Escanear vulnerabilidades en Docker es uno de esos pasos que la mayoría de equipos ignora hasta que es demasiado tarde. Tu imagen puede tener 40 CVEs conocidos y tu no tienes ni idea — cada FROM ubuntu:22.04 que escribes arrastra un histórico de paquetes que nadie revisa. En esta guía vas a ver que herramientas usar, como escanear paso a paso y como automatizarlo en tu pipeline. Sin relleno.

Índice

1. Cómo escanear vulnerabilidades en tus contenedores Docker
2. Por que escanear vulnerabilidades en tus imagenes Docker
3. Herramientas para escanear vulnerabilidades en Docker
4. Como escanear una imagen Docker con Trivy paso a paso
5. Como integrar el escaneo en CI/CD
6. Buenas practicas para reducir vulnerabilidades en Docker
7. Trivy vs Grype vs Docker Scout vs Snyk
8. Preguntas frecuentes

Cómo escanear vulnerabilidades en tus contenedores Docker

Tu imagen de Docker puede tener 40 vulnerabilidades conocidas y tú no tienes ni idea. Así de simple. Cada FROM ubuntu:22.04 que escribes arrastra un histórico de paquetes con CVEs que nadie revisa hasta que es tarde.

Escanear tus imágenes antes de llevarlas a producción ya no es opcional — es el mínimo indispensable. En esta guía vas a ver qué herramientas usar, cómo escanear paso a paso y cómo automatizarlo en tu pipeline.

Por que escanear vulnerabilidades en tus imagenes Docker

Una imagen Docker no es solo tu código: es tu código + un sistema operativo base + todas sus dependencias. Cada capa que añades (apt install, pip install, npm install) suma superficie de ataque.

Los problemas más comunes que un escáner detecta:

• CVEs en el SO base (Debian, Alpine, Ubuntu) sin parchear
• Dependencias desactualizadas en tu package.json o requirements.txt
• Secretos hardcodeados (API keys, tokens) copiados por error en la imagen
• Configuraciones inseguras (usuario root, permisos excesivos)

Un solo CVE crítico sin parchear en una imagen expuesta es la diferencia entre un despliegue normal y un incidente de seguridad.

Herramientas para escanear vulnerabilidades en Docker

Trivy

La opción más popular por rapidez, cero configuración y soporte para imágenes, sistemas de archivos y repositorios Git. Open source y gratuito.

Docker Scout

Integrado directamente en Docker Desktop y Docker CLI desde 2023. Ideal si ya trabajas con Docker Hub, porque analiza automáticamente las imágenes que subes.

Grype

Alternativa a Trivy, muy usada en pipelines de CI/CD por su salida en JSON limpia y su integración con Syft para generar SBOMs (Software Bill of Materials).

Snyk

Más orientado a equipos que ya usan Snyk para código y dependencias; añade escaneo de contenedores como parte de la misma plataforma. De pago a partir de cierto volumen.

Como escanear una imagen Docker con Trivy paso a paso

Instalar Trivy

sudo apt-get install wget apt-transport-https gnupg

wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb generic main" | sudo tee -a /etc/apt/sources.list.d/trivy.list

sudo apt-get update

sudo apt-get install trivy

Escanea una imagen local o remota

trivy image nombre-imagen:tag

Filtra solo vulnerabilidades críticas y altas

trivy image --severity CRITICAL,HIGH nombre-imagen:tag

Genera un reporte en formato JSON (útil para CI/CD)

trivy image --format json --output reporte.json nombre-imagen:tag

Haz que el pipeline falle si hay vulnerabilidades críticas

trivy image --exit-code 1 --severity CRITICAL nombre-imagen:tag

Este último comando es la clave: convierte el escaneo en un gate real, no en un informe que nadie lee.

¿Qué significa exactamente "gate real"?

Cuando ejecutas trivy image sin más, el comando siempre termina con código de salida 0 (éxito), aunque encuentre 50 vulnerabilidades críticas. Solo te imprime una tabla en la terminal. Si eso lo integras en un pipeline tal cual, el build se marca como ✅ verde da igual lo que diga el reporte — porque ningún sistema de CI/CD lee tablas de texto, solo lee códigos de salida.

Un "gate" (puerta/barrera) es un punto del pipeline que puede bloquear el flujo si no se cumple una condición. Ejemplos de gates que ya conoces: los tests que fallan y detienen el merge, o el linter que bloquea un PR.

El flag --exit-code 1 es lo que convierte a Trivy en un gate real:

• Si no encuentra vulnerabilidades del nivel indicado → sale con código 0 → el pipeline continúa normal
• Si encuentra al menos una vulnerabilidad CRITICAL → sale con código 1 → cualquier CI/CD interpreta eso como fallo y detiene el pipeline automáticamente

Sin --exit-code 1, Trivy solo "informa". Con --exit-code 1, Trivy "decide". Esa es la diferencia entre tener un escáner decorativo y tener un control de seguridad que nadie puede saltarse sin querer.

Un par de flags que conviene combinar con esto en producción real:

trivy image --exit-code 1 --severity CRITICAL --ignore-unfixed nombre-imagen:tag

--ignore-unfixed evita que el pipeline se bloquee por CVEs que todavía no tienen parche disponible — no tiene sentido frenar un despliegue por algo que no puedes arreglar hoy. Así el gate solo bloquea lo que realmente puedes solucionar.

Como integrar el escaneo en CI/CD

El escaneo manual sirve para auditorías puntuales, pero el valor real está en automatizarlo para que ningún despliegue dependa de que alguien se acuerde de escanear a mano. Aquí tienes el flujo completo, no solo el paso suelto.

GitHub Actions — workflow completo

name: Build y escaneo de seguridad

on:
  push:
    branches: [main]

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout del código
        uses: actions/checkout@v4

      - name: Construir la imagen
        run: docker build -t tu-usuario/tu-imagen:${{ github.sha }} .

      - name: Escanear imagen con Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'tu-usuario/tu-imagen:${{ github.sha }}'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'
          ignore-unfixed: true
          format: 'table'

      - name: Publicar imagen (solo si el escaneo pasó)
        run: docker push tu-usuario/tu-imagen:${{ github.sha }}

Lo importante del orden: el push a producción va después del escaneo, no antes. Si Trivy falla, GitHub Actions corta la ejecución ahí mismo y el paso de push nunca se ejecuta — la imagen vulnerable nunca sale de tu pipeline.

GitLab CI — equivalente

scan:
  stage: test
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image --exit-code 1 --severity CRITICAL --ignore-unfixed tu-usuario/tu-imagen:$CI_COMMIT_SHA

Mismo principio: si trivy devuelve1, el job se marca como fallido y GitLab detiene el pipeline antes del stage de deploy.

Qué hacer cuando el gate bloquea un build

Esto va a pasar tarde o temprano, y no es un fallo del sistema, es el sistema funcionando como debe:

• Actualiza la imagen base o la dependencia si hay parche disponible,normalmente resuelve el 80% de los bloqueos.
• Revisa el reporte (trivy image --format table para verlo legible) y confirma si el CVE afecta realmente tu caso de uso.
• Si no hay parche y el riesgo es asumible, documenta la excepción explícitamente en un .trivyignore en vez de bajar el nivel de severidad global — así queda registrado por qué se ignoró, no simplemente desactivado

# .trivyignore

CVE-2023-XXXXX

Con esto tienes un pipeline que no solo avisa de vulnerabilidades, sino que físicamente impide que lleguen a producción sin pasar por una decisión consciente de alguien del equipo.

Buenas practicas para reducir vulnerabilidades en Docker

1. Usa imágenes base mínimas (alpine, distroless) en lugar de ubuntu o debian completas.
2. Aplica multi-stage builds para no arrastrar herramientas de compilación a la imagen final.Los multi-stage builds son la tecnica mas efectiva para reducir la superficie de ataque de tus imagenes. Si aun no los usas, tenemos una guia completa de Dockerfile optimizado con ejemplos reales.
3. Actualiza la imagen base con regularidad.No la dejes fija en una versión de hace un año.
4. Ejecuta el contenedor como usuario no-root siempre que puedas.Ejecutar contenedores como usuario no-root es una de las primeras recomendaciones del articulo de Dockerfile optimizado — si no lo has aplicado, es el momento.
5. Escanea en cada build, no solo antes de un release grande

Reducir la superficie de red de tus contenedores también ayuda — si usas multiples servicios revisa nuestra guia de Docker Networking.

Trivy vs Grype vs Docker Scout vs Snyk

Preguntas frecuentes

Escanear tus imagenes no es un paso extra burocratico, es la diferencia entre desplegar con confianza o desplegar a ciegas. Empieza con Trivy en local esta misma semana — la instalacion son 4 comandos y el primer escaneo te da un panorama real del estado de seguridad de tus imagenes. Cuando lo tengas dominado, metelo como gate obligatorio en tu CI/CD.

Si quieres seguir reforzando la seguridad de tus contenedores, en Zymeralabs tienes guias de Dockerfile optimizado, configuracion de UFW y claves SSH — todo lo que necesitas para llevar tus servidores a produccion de forma segura.