Trivy y Grype un año después: cuál ha madurado mejor

Actualizado: 2026-05-03

Trivy y Grype llevan ya un par de años instalados como los dos escáneres de contenedores open-source de referencia. Trivy viene de Aqua Security; Grype, de Anchore. Sobre el papel hacen lo mismo —leer capas de una imagen Docker, enumerar paquetes y cruzarlos con bases de datos de CVE— pero en la práctica han evolucionado hacia filosofías distintas. Después de un año largo integrando ambos en pipelines de CI reales, con imágenes que van desde node:20 pelado hasta bases Python con cien dependencias transitivas, tengo bastante claro dónde gana cada uno.

Puntos clave

• Trivy ha evolucionado de escáner de imágenes a navaja suiza: cubre también filesystems, repos Git, manifests de Kubernetes, Helm charts y plantillas de IaC.
• Grype destaca por su tasa de falsos positivos más baja y su SBOM generado con Syft, que se puede reutilizar en auditorías independientes del escaneado.
• El Trivy Operator genera VulnerabilityReports como Custom Resources de Kubernetes, consultables con kubectl y exportables a Prometheus.
• Ambos son Apache 2.0 y soportan modo offline para entornos air-gapped.
• Para pipelines mixtos (imagen + IaC + cluster), Trivy cubre todo con un solo binario; para imagen-only con máximo rigor, Grype + Syft es la combinación más sólida.

Superficie común

Lo que comparten es fácil de resumir: escanean imágenes de contenedor, generan SBOM en formatos SPDX y CycloneDX, se integran con GitHub Actions y GitLab CI, devuelven códigos de salida útiles para romper builds, ambos son Apache 2.0 y ambos soportan modo offline. Si el requisito es simplemente tener un escáner de CVE en el pipeline antes de publicar la imagen, los dos lo hacen bien. La discusión interesante empieza cuando el alcance crece.

Trivy: el escáner que se convirtió en navaja suiza

Trivy nació como escáner de imágenes, pero Aqua fue ampliando el target hasta cubrir sistemas de ficheros, repositorios Git, manifests de Kubernetes, charts de Helm, módulos Terraform y plantillas de CloudFormation. La invocación típica se resume en cuatro verbos —image, fs, config, repo— y todos aceptan los mismos flags de severidad, formato de salida y política de exit code. Esta uniformidad es lo que más se agradece cuando toca integrarlo en un pipeline: un solo binario cubre desde “escanea esta imagen” hasta “revisa el Dockerfile y los manifests que la despliegan”.

# Imagen
trivy image --severity HIGH,CRITICAL myapp:latest

# Manifests de Kubernetes
trivy config ./k8s/

# Repositorio completo (imagen + IaC)
trivy repo https://github.com/myorg/myapp

El Trivy Operator para Kubernetes es el otro diferencial fuerte. Instalado con Helm, observa el clúster y genera cuatro tipos de Custom Resource:

• VulnerabilityReport: por pod, con CVEs de las imágenes en uso.
• ConfigAuditReport: chequeos CIS Benchmark sobre manifests en vivo.
• RbacAssessmentReport: problemas de RBAC.
• ExposedSecretReport: credenciales embebidas en imágenes.

Todo queda como recursos nativos de Kubernetes, consultables con kubectl get y exportables a Prometheus. Para equipos ya metidos en el ecosistema K8s —especialmente los que siguen mejoras como las de Kubernetes 1.30— eso es lo que empuja la balanza.

Grype: precisión y SBOM de primera clase

Grype toma la dirección opuesta: foco total en la tarea de escaneo de imágenes y paquetes, con la máxima precisión posible. No tiene ambición de ser navaja suiza. El diferencial clave está en dos áreas.

Falsos positivos: en mis pruebas con imágenes Python complejas, Grype mostraba consistentemente menos alarmas que Trivy para el mismo conjunto de paquetes. La diferencia viene de cómo cada herramienta interpreta la información de fix disponibility y las versiones afectadas en las bases de datos de CVE —NVD, GitHub Advisory Database, las DBs específicas de distribución. No es que Trivy sea inexacto; es que Grype es más conservador antes de reportar.

Syft + Grype como pipeline separado: Anchore publica Syft como generador de SBOM independiente, y Grype puede consumir ese SBOM como entrada. La ventaja es que puedes generar el SBOM una vez (en el build, firmarlo con cosign) y escanear el SBOM resultante en distintos puntos del pipeline sin volver a leer la imagen:

# Generar y firmar SBOM
syft myapp:latest -o spdx-json > sbom.spdx.json
cosign attest --predicate sbom.spdx.json --type spdxjson myapp:latest

# Escanear el SBOM
grype sbom:sbom.spdx.json --fail-on high

Este patrón es particularmente relevante para supply chain security: el SBOM firmado viaja con la imagen y cualquier herramienta del ecosistema puede verificarlo y volver a escanearlo. El taller de la ITU sobre Zero Trust y Software Supply Chain Security^[1] documenta cómo este tipo de artefactos firmados se integran con marcos de confianza más amplios.

Integración en pipelines de CI

Ambas herramientas se integran bien con GitHub Actions y GitLab CI. La diferencia práctica es el tiempo de inicio: Trivy descarga su base de datos de vulnerabilidades la primera vez (~200 MB), mientras que Grype también tiene su propia DB. En pipelines sin caché de DB, esto añade 30-60 segundos al primer run. Con caché, la diferencia desaparece.

Para la política de ruptura de builds, ambos devuelven exit code no cero cuando encuentran vulnerabilidades por encima del umbral configurado. La diferencia está en la granularidad: Trivy permite políticas OPA/Rego para casos complejos, mientras que Grype es más directo con flags simples.

# GitHub Actions con Trivy
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:latest
    severity: HIGH,CRITICAL
    exit-code: 1
    ignore-unfixed: true

Para equipos que gestionan seguridad de forma continua con eBPF profiling en producción, el Trivy Operator añade la capa de visibilidad post-deploy que CI por sí solo no cubre.

Cuándo elegir cada uno

Usa Trivy si:

• Necesitas cubrir imágenes, IaC, manifests de K8s y Git repos con un solo binario.
• Operas Kubernetes y quieres CVE reports como Custom Resources consultables en cluster.
• Tu equipo ya usa el ecosistema Aqua o quieres una solución all-in-one.

Usa Grype + Syft si:

• El foco es imagen/paquete scanning con la menor tasa de falsos positivos posible.
• Necesitas SBOMs firmados y portables como parte del proceso de firma de artefactos.
• Prefieres herramientas con alcance bien delimitado y sin sorpresas de licencia futura.

En muchos equipos maduros, la respuesta es ambas: Trivy en el pipeline de CI por su cobertura amplia, Grype + Syft en el proceso de firma y publicación de imágenes por su precisión en SBOM.

Conclusión

Trivy y Grype no compiten en el mismo espacio que aparentan. Trivy es la mejor opción cuando el requisito es “un escáner que cubra todo el stack con uniformidad y se integre con Kubernetes como ciudadano de primera clase”. Grype es la mejor opción cuando el requisito es “el SBOM más preciso posible, firmado y reutilizable en toda la cadena de distribución”. La decisión real no es cuál es mejor en abstracto, sino qué combina mejor con los flujos de build y auditoría de tu equipo.

1. Zero Trust y Software Supply Chain Security