Herramientas SBOM Comparadas: Syft vs Trivy vs CycloneDX CLI

por

Por qué importan los SBOMs: el imperativo regulatorio y de seguridad

Un Software Bill of Materials (SBOM) es un inventario formal y legible por máquinas de cada componente, biblioteca y dependencia que compone un software. Piensa en ello como la etiqueta nutricional de tu aplicación — excepto que en lugar de calorías y sodio, estás listando paquetes, versiones, licencias y datos de procedencia.

Los SBOMs han pasado de ser algo deseable a convertirse en un requisito regulatorio. Dos políticas fundamentales están impulsando su adopción en todas las industrias:

Orden Ejecutiva 14028 (Estados Unidos)

Firmada en mayo de 2021, la OE 14028 — “Mejora de la Ciberseguridad de la Nación” — exige que cualquier software vendido al gobierno federal de EE.UU. incluya un SBOM. La orden instruyó al NIST a definir los elementos mínimos del SBOM, lo que resultó en una guía alineada con los estándares SBOM de la NTIA. Si tu organización vende a agencias gubernamentales, la generación de SBOMs ya no es opcional — es un prerrequisito de adquisición.

Ley de Ciberresiliencia de la UE (CRA)

La Ley de Ciberresiliencia de la UE, que entró en vigor en 2024, exige a los fabricantes y distribuidores de productos con elementos digitales proporcionar SBOMs como parte de su evaluación de conformidad. La CRA se aplica ampliamente — desde dispositivos IoT hasta plataformas SaaS empresariales. Con los plazos de aplicación acelerándose en 2026 y 2027, los productores de software para el mercado europeo deben integrar la generación de SBOMs en sus procesos de construcción ahora.

Más allá del cumplimiento: valor operativo

Dejando de lado los factores regulatorios, los SBOMs aportan beneficios operativos concretos:

  • Respuesta ante vulnerabilidades: Cuando aparece un nuevo CVE (como Log4Shell), un SBOM te permite determinar instantáneamente qué productos y despliegues están afectados.
  • Cumplimiento de licencias: Los SBOMs enumeran las licencias en todo tu árbol de dependencias, señalando licencias copyleft o incompatibles antes de que se conviertan en problemas legales.
  • Transparencia de la cadena de suministro: Los SBOMs crean una cadena de custodia auditable, permitiendo a los consumidores posteriores verificar exactamente qué están ejecutando.
  • Investigación forense de incidentes: Durante investigaciones de brechas de seguridad, los SBOMs aceleran el análisis de causa raíz proporcionando un inventario preciso de componentes en el momento de la compilación.

La pregunta ya no es si generar SBOMs, sino qué herramienta utilizar. En esta comparativa, evaluamos tres generadores de SBOMs de código abierto líderes: Syft, Trivy y CycloneDX CLI.

Syft: el generador de SBOMs dedicado de Anchore

Syft es desarrollado por Anchore y está diseñado para hacer una sola cosa excepcionalmente bien: generar SBOMs precisos y completos. Es una herramienta dedicada a SBOMs, no un escáner que produce SBOMs como efecto secundario.

Capacidades principales

  • Formatos de salida: SPDX (JSON, tag-value), CycloneDX (JSON, XML), JSON nativo de Syft y formato de snapshot de dependencias de GitHub.
  • Tipos de origen: Imágenes de contenedores (desde registros, tarballs o daemon Docker), sistemas de archivos, directorios y archivos comprimidos (tar, zip, jar, war).
  • Ecosistemas de lenguajes: Excelente cobertura — Go, Java (Maven/Gradle), JavaScript (npm/yarn), Python (pip/Poetry/Pipenv), Ruby, Rust, PHP (Composer), .NET (NuGet), C/C++ (Conan), Swift, Dart, Haskell y más.
  • Catalogadores de paquetes: Syft utiliza una arquitectura de catalogadores modular. Cada ecosistema tiene su propio catalogador que comprende archivos lock nativos, manifiestos y artefactos binarios. Esto produce resultados altamente precisos.
  • Soporte de attestations: Syft se integra estrechamente con los frameworks de attestation cosign e in-toto. Puedes canalizar la salida SBOM de Syft directamente hacia cosign attest para producir attestations SBOM firmadas.

Fortalezas

El enfoque exclusivo de Syft en la generación de SBOMs significa que tiene la cobertura de catalogadores más profunda de cualquier herramienta en esta comparativa. Detecta componentes que otras herramientas pasan por alto — especialmente paquetes binarios compilados en binarios Go y Rust, y dependencias anidadas dentro de uber-jars de Java. Su flexibilidad de formatos de salida es inigualable, y se integra nativamente con el escáner de vulnerabilidades Grype de Anchore.

Limitaciones

Syft no realiza escaneo de vulnerabilidades por sí mismo. Necesitas combinarlo con Grype u otro escáner. Esto es posiblemente una fortaleza (filosofía Unix: hacer una cosa bien), pero significa una herramienta adicional en tu pipeline.

Ejemplo de uso

# Generate CycloneDX SBOM from a container image
syft packages registry.example.com/myapp:latest -o cyclonedx-json > sbom.cdx.json

# Generate SPDX SBOM from a local directory
syft dir:/path/to/source -o spdx-json > sbom.spdx.json

# Attest the SBOM with cosign
cosign attest --predicate sbom.cdx.json --type cyclonedx my-image:latest

Trivy: el escáner todo-en-uno de Aqua Security con modo SBOM

Trivy es desarrollado por Aqua Security y comenzó como un escáner de vulnerabilidades para contenedores. Con el tiempo, evolucionó hasta convertirse en una herramienta de seguridad integral que también genera SBOMs. Su capacidad de SBOM fue añadida como un modo de escaneo junto con el escaneo de vulnerabilidades, configuraciones incorrectas, secretos y licencias.

Capacidades principales

  • Formatos de salida: CycloneDX (JSON), SPDX (JSON), JSON nativo de Trivy, SARIF y salida en tabla/legible por humanos.
  • Tipos de origen: Imágenes de contenedores, sistemas de archivos, repositorios git, clústeres Kubernetes, cuentas AWS e imágenes de VM.
  • Ecosistemas de lenguajes: Buena cobertura — Go, Java, JavaScript, Python, Ruby, Rust, PHP, .NET, C/C++, Elixir, Dart, Swift y más.
  • Escaneo de vulnerabilidades integrado: Esta es la característica estrella de Trivy. Genera un SBOM y escanéalo en busca de vulnerabilidades en una sola pasada, o escanea un archivo SBOM existente producido por otra herramienta.
  • Soporte de attestations: Trivy puede generar y verificar attestations in-toto de forma nativa mediante trivy image --format cosign-vuln, y se integra con cosign para flujos de trabajo de attestation de SBOMs.

Fortalezas

La mayor ventaja de Trivy es su arquitectura todo-en-uno. Un solo binario maneja la generación de SBOMs, escaneo de vulnerabilidades, detección de configuraciones incorrectas, escaneo de secretos y análisis de licencias. Esto reduce enormemente la complejidad del conjunto de herramientas. También es la única herramienta en esta comparativa que puede escanear clústeres Kubernetes y cuentas cloud directamente. Su base de datos de vulnerabilidades se actualiza frecuentemente y cubre múltiples fuentes (NVD, avisos de proveedores, GitHub Security Advisories).

Limitaciones

Debido a que la generación de SBOMs de Trivy es una funcionalidad entre muchas, la profundidad de sus catalogadores puede quedar por detrás de Syft en casos límite — particularmente para el análisis binario de binarios compilados Go/Rust y artefactos Java profundamente anidados. El soporte SPDX fue añadido después que CycloneDX, por lo que la salida CycloneDX tiende a ser más completa en algunos escenarios. La naturaleza todo-en-uno también implica un binario más grande y descargas iniciales de base de datos más prolongadas.

Ejemplo de uso

# Generate CycloneDX SBOM from a container image
trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/myapp:latest

# Generate SPDX SBOM from a filesystem
trivy fs --format spdx-json --output sbom.spdx.json /path/to/source

# Scan an existing SBOM for vulnerabilities
trivy sbom sbom.cdx.json

# Combined: generate SBOM + scan in one pass
trivy image --format json --list-all-pkgs registry.example.com/myapp:latest

CycloneDX CLI: el kit de herramientas SBOM nativo de OWASP

CycloneDX CLI es parte del proyecto OWASP CycloneDX. A diferencia de Syft y Trivy, no es principalmente un generador de SBOMs a partir de código fuente o imágenes de contenedores. En cambio, es un kit de herramientas para manipular, convertir, validar, fusionar y comparar SBOMs CycloneDX. El ecosistema más amplio de CycloneDX incluye plugins de generación de SBOMs específicos por lenguaje (por ejemplo, cyclonedx-maven-plugin, cyclonedx-npm, cyclonedx-gomod) que producen SBOMs durante el proceso de compilación.

Capacidades principales

  • Formatos de salida: CycloneDX (JSON, XML, Protocol Buffers) — fidelidad completa. Puede convertir entre versiones de CycloneDX. Soporte limitado de conversión a SPDX.
  • Operaciones con SBOMs: Fusionar múltiples SBOMs en uno, comparar dos SBOMs para ver qué cambió, validar SBOMs contra el esquema CycloneDX y convertir entre formatos CycloneDX.
  • Generación en tiempo de compilación: Los plugins de lenguaje del ecosistema CycloneDX generan SBOMs durante la compilación leyendo directamente el resolvedor de dependencias (Maven, npm, Go modules, pip, etc.), lo que produce el grafo de dependencias más preciso posible.
  • Soporte de attestations: Los SBOMs CycloneDX pueden encapsularse en attestations CycloneDX BOM-Link, y el ecosistema soporta documentos VEX (Vulnerability Exploitability eXchange) como ciudadanos de primera clase.

Fortalezas

El enfoque de generación en tiempo de compilación del ecosistema CycloneDX produce los SBOMs más precisos porque accede a la resolución real de dependencias de la herramienta de compilación — no un escaneo post-hoc del sistema de archivos. La capacidad de fusión del CLI es invaluable para monorepos y arquitecturas de microservicios donde necesitas combinar SBOMs por servicio en un SBOM a nivel de producto. La validación de esquemas asegura que los SBOMs cumplan con la especificación antes de su distribución. El soporte VEX es el más maduro en este ecosistema.

Limitaciones

El enfoque CycloneDX requiere integración de plugins por lenguaje en tu sistema de compilación. Esto implica más trabajo que ejecutar un solo binario contra una imagen de contenedor. El CLI en sí no escanea contenedores ni sistemas de archivos en busca de paquetes — necesitas los plugins de lenguaje para la generación. El soporte SPDX es limitado comparado con Syft y Trivy. Las herramientas están más fragmentadas (CLI + múltiples plugins) frente a un solo binario.

Ejemplo de uso

# Generate SBOM during Maven build
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

# Generate SBOM from npm project
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Merge multiple SBOMs
cyclonedx merge --input-files sbom-api.cdx.json sbom-frontend.cdx.json --output-file product-sbom.cdx.json

# Validate an SBOM against the schema
cyclonedx validate --input-file sbom.cdx.json --fail-on-errors

# Diff two SBOMs to see what changed between releases
cyclonedx diff --from v1-sbom.cdx.json --to v2-sbom.cdx.json

Tabla comparativa directa

Característica Syft Trivy CycloneDX CLI + Plugins
Propósito principal Generación de SBOMs Escáner de seguridad todo-en-uno Manipulación de SBOMs + generación en tiempo de compilación
Salida SPDX JSON, tag-value (excelente) JSON (bueno) Solo conversión limitada
Salida CycloneDX JSON, XML (excelente) JSON (excelente) JSON, XML, Protobuf (nativo, el mejor)
Escaneo de contenedores Sí (registro, daemon, tarball) Sí (registro, daemon, tarball) No (solo tiempo de compilación)
Escaneo de sistema de archivos Sí Sí Mediante plugins de lenguaje
Análisis binario Fuerte (binarios Go, Rust) Moderado Ninguno
Escaneo de vulnerabilidades No (usar Grype) Sí (integrado) No (usar herramienta separada)
Precisión (profundidad de dependencias) Excelente Muy buena La mejor (resolución en tiempo de compilación)
Fusión/comparación de SBOMs No No Sí (nativo)
Soporte VEX Mediante Grype/Vunnel Soporte OpenVEX VEX nativo de CycloneDX
Firma de attestations Mediante integración con cosign Mediante integración con cosign Attestation BOM-Link
Integración CI/CD GitHub Action, CLI GitHub Action, CLI, operador Kubernetes Plugin de compilación por lenguaje
Velocidad (contenedor típico) Rápido (15-30s) Moderado (20-60s con descarga de BD) El más rápido (integrado en compilación, sin escaneo separado)
Escaneo de clúster Kubernetes No Sí No

Precisión y completitud: donde realmente importa

La precisión del SBOM es el diferenciador más importante. Un SBOM incompleto es posiblemente peor que no tener SBOM — proporciona una falsa confianza.

Los plugins de tiempo de compilación de CycloneDX ganan en precisión por una razón clara: se conectan al resolvedor del gestor de paquetes durante la compilación. Cuando cyclonedx-maven-plugin se ejecuta, ve exactamente el mismo árbol de dependencias que Maven resolvió. No hay adivinanzas, no hay coincidencias heurísticas — lee el grafo resuelto directamente.

Syft queda en segundo lugar. Su arquitectura de catalogadores está específicamente ajustada para analizar archivos lock, manifiestos y metadatos binarios con alta fidelidad. Syft destaca encontrando componentes que otras herramientas pasan por alto — particularmente binarios Go (que incorporan información de módulos), binarios Rust y uber-jars de Java con dependencias embebidas.

Trivy es muy bueno para la mayoría de los casos de uso pero puede pasar por alto casos límite en el análisis binario. Su fortaleza es la amplitud — cubre más tipos de origen (Kubernetes, cloud) aunque la profundidad por origen sea ligeramente menor que Syft en algunos escenarios.

Integración CI/CD: incorporando SBOMs en tu pipeline

Las tres herramientas se integran en pipelines CI/CD, pero los patrones de integración difieren significativamente:

Syft en CI/CD

Syft proporciona una GitHub Action oficial (anchore/sbom-action) que genera SBOMs y opcionalmente los sube como snapshots de dependencias de GitHub. Para GitLab, Jenkins u otros sistemas CI, el binario CLI es sencillo de instalar e invocar. Combínalo con anchore/scan-action (Grype) para puertas de control de vulnerabilidades.

Trivy en CI/CD

Trivy ofrece la superficie de integración CI/CD más amplia: una GitHub Action (aquasecurity/trivy-action), operador Kubernetes (Trivy Operator) y salida SARIF para integración con GitHub Code Scanning. Un solo paso de Trivy puede producir un SBOM, escanear vulnerabilidades, verificar configuraciones incorrectas y detectar secretos — reemplazando tres o cuatro herramientas separadas.

CycloneDX en CI/CD

La integración de CycloneDX requiere añadir el plugin de lenguaje apropiado a tu configuración de compilación. Para Maven, añades el plugin a tu POM. Para npm, añades un script que invoque @cyclonedx/cyclonedx-npm. Este enfoque nativo de compilación significa que el SBOM se genera como un artefacto de compilación junto a tu aplicación, sin necesidad de un paso de escaneo separado.

Cuándo usar cada herramienta

Elige Syft cuando:

  • La precisión en la generación de SBOMs sea tu máxima prioridad
  • Necesites máxima flexibilidad de formatos de salida (SPDX + CycloneDX)
  • Estés escaneando imágenes de contenedores o artefactos pre-compilados (no código fuente)
  • Ya uses o planees usar Grype para escaneo de vulnerabilidades
  • Necesites analizar binarios compilados (Go, Rust)
  • Quieras una herramienta ligera y de propósito único con dependencias mínimas

Elige Trivy cuando:

  • Quieras una sola herramienta para generación de SBOMs y escaneo de vulnerabilidades
  • Necesites escanear clústeres Kubernetes o cuentas cloud
  • La simplicidad y reducción de complejidad del conjunto de herramientas importen más que la máxima profundidad de SBOM
  • Quieras detección integrada de configuraciones incorrectas y secretos junto con SBOMs
  • Tu equipo prefiera una sola herramienta bien mantenida en lugar de ensamblar múltiples componentes
  • Necesites salida SARIF para integración con GitHub Code Scanning o Azure DevOps

Elige CycloneDX CLI + Plugins cuando:

  • Necesites la resolución de dependencias más precisa posible
  • Tu organización haya estandarizado el formato CycloneDX
  • Gestiones monorepos y necesites fusionar SBOMs por servicio en SBOMs a nivel de producto
  • Necesites comparar SBOMs entre versiones para rastrear cambios de dependencias
  • La validación de esquemas de SBOMs antes de su distribución sea un requisito
  • La generación de documentos VEX sea parte de tu flujo de trabajo de divulgación de vulnerabilidades

Pipeline combinado: usando las tres herramientas juntas

En la práctica, muchas organizaciones maduras combinan estas herramientas. Aquí tienes un patrón de pipeline que aprovecha las fortalezas de cada una:

# Stage 1: Build-time SBOM (most accurate dependency graph)
# In your Maven/npm/Go build step:
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom
# Output: target/bom.json (CycloneDX format)

# Stage 2: Container-level SBOM (catches OS packages + runtime deps)
syft packages myapp:${BUILD_TAG} -o cyclonedx-json > container-sbom.cdx.json

# Stage 3: Merge build-time and container SBOMs
cyclonedx merge \
  --input-files target/bom.json container-sbom.cdx.json \
  --output-file merged-sbom.cdx.json

# Stage 4: Validate the merged SBOM
cyclonedx validate --input-file merged-sbom.cdx.json --fail-on-errors

# Stage 5: Vulnerability scan the merged SBOM
trivy sbom merged-sbom.cdx.json --exit-code 1 --severity CRITICAL,HIGH

# Stage 6: Sign and attest
cosign attest --predicate merged-sbom.cdx.json \
  --type cyclonedx myapp:${BUILD_TAG}

Este pipeline logra lo mejor de todos los mundos: los plugins CycloneDX proporcionan precisión en tiempo de compilación, Syft añade descubrimiento de paquetes a nivel de contenedor, el CLI de CycloneDX fusiona y valida el SBOM combinado, Trivy escanea vulnerabilidades como puerta de calidad, y cosign proporciona attestation criptográfica.

Consideraciones de rendimiento

La velocidad importa en pipelines CI/CD donde cada minuto de tiempo de compilación tiene un coste:

  • Syft es consistentemente rápido. Un escaneo típico de imagen de contenedor se completa en 15-30 segundos sin necesidad de descarga de base de datos externa. El binario es ligero y arranca instantáneamente.
  • Trivy requiere una descarga inicial de base de datos de vulnerabilidades (~30-50MB) en la primera ejecución, lo que añade 10-30 segundos. Las ejecuciones posteriores con base de datos en caché son comparables a Syft. Usar --skip-db-update en CI (con caché precargada) elimina esta sobrecarga.
  • Los plugins CycloneDX añaden un tiempo insignificante a las compilaciones porque se ejecutan como parte del proceso de compilación existente. No hay una fase de escaneo separada — el SBOM es un subproducto de la resolución de dependencias que ya ocurrió.

Attestation y firma: demostrando la procedencia del SBOM

Un SBOM sin firmar es un documento de “confía en mí”. Para que los SBOMs tengan valor real en la seguridad de la cadena de suministro, deben estar firmados criptográficamente y asociados con el artefacto que describen.

Syft + cosign es el flujo de trabajo de attestation más maduro. Anchore ha invertido fuertemente en soporte de attestation SLSA e in-toto, y la salida de Syft está diseñada para alimentar directamente a cosign attest.

Trivy soporta attestation basada en cosign y puede verificar attestations existentes. La salida trivy image --format cosign-vuln produce informes de vulnerabilidades listos para attestation.

CycloneDX soporta BOM-Link, que proporciona un mecanismo de enlace basado en URI entre SBOMs y los artefactos que describen. Combinado con Sigstore o in-toto, esto crea una cadena verificable desde el código fuente hasta el despliegue.

Conclusión

No existe una única herramienta SBOM “mejor” — la elección correcta depende de tus necesidades específicas. Para profundidad pura en generación de SBOMs, Syft es el estándar de referencia. Para simplicidad todo-en-uno, Trivy reduce la complejidad del conjunto de herramientas dramáticamente. Para precisión en tiempo de compilación y gestión del ciclo de vida de SBOMs, el ecosistema CycloneDX es insuperable.

El enfoque más sólido es combinarlas: usa plugins CycloneDX en tiempo de compilación para máxima precisión, Syft para descubrimiento a nivel de contenedor, el CLI de CycloneDX para fusión y validación, y Trivy para escaneo de vulnerabilidades. Añade attestation con cosign encima, y tendrás un pipeline SBOM de nivel productivo que satisface la OE 14028, la CRA de la UE y tus propias necesidades de seguridad operativa.

¿Listo para construir este pipeline de forma práctica? Consulta nuestro Laboratorio SBOM para un tutorial paso a paso con imágenes de contenedores reales y plantillas CI/CD.