Un Software Bill of Materials (SBOM) es un inventario formal y legible por m\u00e1quinas de cada componente, biblioteca y dependencia que compone un software. Piensa en ello como la etiqueta nutricional de tu aplicaci\u00f3n \u2014 excepto que en lugar de calor\u00edas y sodio, est\u00e1s listando paquetes, versiones, licencias y datos de procedencia.<\/p>\n
Los SBOMs han pasado de ser algo deseable a convertirse en un requisito regulatorio. Dos pol\u00edticas fundamentales est\u00e1n impulsando su adopci\u00f3n en todas las industrias:<\/p>\n
Firmada en mayo de 2021, la OE 14028<\/strong> \u2014 “Mejora de la Ciberseguridad de la Naci\u00f3n” \u2014 exige que cualquier software vendido al gobierno federal de EE.UU. incluya un SBOM. La orden instruy\u00f3 al NIST a definir los elementos m\u00ednimos del SBOM, lo que result\u00f3 en una gu\u00eda alineada con los est\u00e1ndares SBOM de la NTIA. Si tu organizaci\u00f3n vende a agencias gubernamentales, la generaci\u00f3n de SBOMs ya no es opcional \u2014 es un prerrequisito de adquisici\u00f3n.<\/p>\n La Ley de Ciberresiliencia de la UE<\/strong>, que entr\u00f3 en vigor en 2024, exige a los fabricantes y distribuidores de productos con elementos digitales proporcionar SBOMs como parte de su evaluaci\u00f3n de conformidad. La CRA se aplica ampliamente \u2014 desde dispositivos IoT hasta plataformas SaaS empresariales. Con los plazos de aplicaci\u00f3n aceler\u00e1ndose en 2026 y 2027, los productores de software para el mercado europeo deben integrar la generaci\u00f3n de SBOMs en sus procesos de construcci\u00f3n ahora.<\/p>\n Dejando de lado los factores regulatorios, los SBOMs aportan beneficios operativos concretos:<\/p>\n La pregunta ya no es si<\/em> generar SBOMs, sino qu\u00e9 herramienta<\/em> utilizar. En esta comparativa, evaluamos tres generadores de SBOMs de c\u00f3digo abierto l\u00edderes: Syft<\/strong>, Trivy<\/strong> y CycloneDX CLI<\/strong>.<\/p>\n Syft<\/a> es desarrollado por Anchore<\/strong> y est\u00e1 dise\u00f1ado para hacer una sola cosa excepcionalmente bien: generar SBOMs precisos y completos. Es una herramienta dedicada a SBOMs, no un esc\u00e1ner que produce SBOMs como efecto secundario.<\/p>\n El enfoque exclusivo de Syft en la generaci\u00f3n de SBOMs significa que tiene la cobertura de catalogadores m\u00e1s profunda de cualquier herramienta en esta comparativa. Detecta componentes que otras herramientas pasan por alto \u2014 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\u00e1ner de vulnerabilidades Grype de Anchore.<\/p>\n Syft no realiza escaneo de vulnerabilidades por s\u00ed mismo. Necesitas combinarlo con Grype<\/strong> u otro esc\u00e1ner. Esto es posiblemente una fortaleza (filosof\u00eda Unix: hacer una cosa bien), pero significa una herramienta adicional en tu pipeline.<\/p>\n Trivy<\/a> es desarrollado por Aqua Security<\/strong> y comenz\u00f3 como un esc\u00e1ner de vulnerabilidades para contenedores. Con el tiempo, evolucion\u00f3 hasta convertirse en una herramienta de seguridad integral que tambi\u00e9n genera SBOMs. Su capacidad de SBOM fue a\u00f1adida como un modo de escaneo junto con el escaneo de vulnerabilidades, configuraciones incorrectas, secretos y licencias.<\/p>\n La mayor ventaja de Trivy es su arquitectura todo-en-uno<\/strong>. Un solo binario maneja la generaci\u00f3n de SBOMs, escaneo de vulnerabilidades, detecci\u00f3n de configuraciones incorrectas, escaneo de secretos y an\u00e1lisis de licencias. Esto reduce enormemente la complejidad del conjunto de herramientas. Tambi\u00e9n es la \u00fanica herramienta en esta comparativa que puede escanear cl\u00fasteres Kubernetes y cuentas cloud directamente. Su base de datos de vulnerabilidades se actualiza frecuentemente y cubre m\u00faltiples fuentes (NVD, avisos de proveedores, GitHub Security Advisories).<\/p>\n Debido a que la generaci\u00f3n de SBOMs de Trivy es una funcionalidad entre muchas, la profundidad de sus catalogadores puede quedar por detr\u00e1s de Syft en casos l\u00edmite \u2014 particularmente para el an\u00e1lisis binario de binarios compilados Go\/Rust y artefactos Java profundamente anidados. El soporte SPDX fue a\u00f1adido despu\u00e9s que CycloneDX, por lo que la salida CycloneDX tiende a ser m\u00e1s completa en algunos escenarios. La naturaleza todo-en-uno tambi\u00e9n implica un binario m\u00e1s grande y descargas iniciales de base de datos m\u00e1s prolongadas.<\/p>\n CycloneDX CLI<\/a> es parte del proyecto OWASP CycloneDX<\/strong>. A diferencia de Syft y Trivy, no es principalmente un generador<\/em> de SBOMs a partir de c\u00f3digo fuente o im\u00e1genes de contenedores. En cambio, es un kit de herramientas para manipular, convertir, validar, fusionar y comparar<\/strong> SBOMs CycloneDX. El ecosistema m\u00e1s amplio de CycloneDX incluye plugins de generaci\u00f3n de SBOMs espec\u00edficos por lenguaje (por ejemplo, El enfoque de generaci\u00f3n en tiempo de compilaci\u00f3n<\/strong> del ecosistema CycloneDX produce los SBOMs m\u00e1s precisos porque accede a la resoluci\u00f3n real de dependencias de la herramienta de compilaci\u00f3n \u2014 no un escaneo post-hoc del sistema de archivos. La capacidad de fusi\u00f3n 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\u00f3n de esquemas asegura que los SBOMs cumplan con la especificaci\u00f3n antes de su distribuci\u00f3n. El soporte VEX es el m\u00e1s maduro en este ecosistema.<\/p>\n El enfoque CycloneDX requiere integraci\u00f3n de plugins por lenguaje<\/strong> en tu sistema de compilaci\u00f3n. Esto implica m\u00e1s trabajo que ejecutar un solo binario contra una imagen de contenedor. El CLI en s\u00ed no escanea contenedores ni sistemas de archivos en busca de paquetes \u2014 necesitas los plugins de lenguaje para la generaci\u00f3n. El soporte SPDX es limitado comparado con Syft y Trivy. Las herramientas est\u00e1n m\u00e1s fragmentadas (CLI + m\u00faltiples plugins) frente a un solo binario.<\/p>\n La precisi\u00f3n del SBOM es el diferenciador m\u00e1s importante. Un SBOM incompleto es posiblemente peor que no tener SBOM \u2014 proporciona una falsa confianza.<\/p>\n Los plugins de tiempo de compilaci\u00f3n de CycloneDX<\/strong> ganan en precisi\u00f3n por una raz\u00f3n clara: se conectan al resolvedor del gestor de paquetes durante la compilaci\u00f3n. Cuando Syft<\/strong> queda en segundo lugar. Su arquitectura de catalogadores est\u00e1 espec\u00edficamente ajustada para analizar archivos lock, manifiestos y metadatos binarios con alta fidelidad. Syft destaca encontrando componentes que otras herramientas pasan por alto \u2014 particularmente binarios Go (que incorporan informaci\u00f3n de m\u00f3dulos), binarios Rust y uber-jars de Java con dependencias embebidas.<\/p>\n Trivy<\/strong> es muy bueno para la mayor\u00eda de los casos de uso pero puede pasar por alto casos l\u00edmite en el an\u00e1lisis binario. Su fortaleza es la amplitud \u2014 cubre m\u00e1s tipos de origen (Kubernetes, cloud) aunque la profundidad por origen sea ligeramente menor que Syft en algunos escenarios.<\/p>\n Las tres herramientas se integran en pipelines CI\/CD, pero los patrones de integraci\u00f3n difieren significativamente:<\/p>\n Syft proporciona una GitHub Action<\/strong> oficial ( Trivy ofrece la superficie de integraci\u00f3n CI\/CD m\u00e1s amplia: una GitHub Action<\/strong> ( La integraci\u00f3n de CycloneDX requiere a\u00f1adir el plugin de lenguaje apropiado<\/strong> a tu configuraci\u00f3n de compilaci\u00f3n. Para Maven, a\u00f1ades el plugin a tu POM. Para npm, a\u00f1ades un script que invoque En la pr\u00e1ctica, muchas organizaciones maduras combinan estas herramientas. Aqu\u00ed tienes un patr\u00f3n de pipeline que aprovecha las fortalezas de cada una:<\/p>\n Este pipeline logra lo mejor de todos los mundos: los plugins CycloneDX proporcionan precisi\u00f3n en tiempo de compilaci\u00f3n, Syft a\u00f1ade 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\u00e1fica.<\/p>\n La velocidad importa en pipelines CI\/CD donde cada minuto de tiempo de compilaci\u00f3n tiene un coste:<\/p>\n Un SBOM sin firmar es un documento de “conf\u00eda en m\u00ed”. Para que los SBOMs tengan valor real en la seguridad de la cadena de suministro, deben estar firmados criptogr\u00e1ficamente y asociados con el artefacto que describen.<\/p>\n Syft + cosign<\/strong> es el flujo de trabajo de attestation m\u00e1s maduro. Anchore ha invertido fuertemente en soporte de attestation SLSA e in-toto, y la salida de Syft est\u00e1 dise\u00f1ada para alimentar directamente a Trivy<\/strong> soporta attestation basada en cosign y puede verificar attestations existentes. La salida CycloneDX<\/strong> 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\u00f3digo fuente hasta el despliegue.<\/p>\n No existe una \u00fanica herramienta SBOM “mejor” \u2014 la elecci\u00f3n correcta depende de tus necesidades espec\u00edficas. Para profundidad pura en generaci\u00f3n de SBOMs, Syft<\/strong> es el est\u00e1ndar de referencia. Para simplicidad todo-en-uno, Trivy<\/strong> reduce la complejidad del conjunto de herramientas dram\u00e1ticamente. Para precisi\u00f3n en tiempo de compilaci\u00f3n y gesti\u00f3n del ciclo de vida de SBOMs, el ecosistema CycloneDX<\/strong> es insuperable.<\/p>\n El enfoque m\u00e1s s\u00f3lido es combinarlas: usa plugins CycloneDX en tiempo de compilaci\u00f3n para m\u00e1xima precisi\u00f3n, Syft para descubrimiento a nivel de contenedor, el CLI de CycloneDX para fusi\u00f3n y validaci\u00f3n, y Trivy para escaneo de vulnerabilidades. A\u00f1ade attestation con cosign encima, y tendr\u00e1s un pipeline SBOM de nivel productivo que satisface la OE 14028, la CRA de la UE y tus propias necesidades de seguridad operativa.<\/p>\n \u00bfListo para construir este pipeline de forma pr\u00e1ctica? Consulta nuestro Laboratorio SBOM<\/a> para un tutorial paso a paso con im\u00e1genes de contenedores reales y plantillas CI\/CD.<\/p>\n","protected":false},"excerpt":{"rendered":" Por qu\u00e9 importan los SBOMs: el imperativo regulatorio y de seguridad Un Software Bill of Materials (SBOM) es un inventario formal y legible por m\u00e1quinas de cada componente, biblioteca y dependencia que compone un software. Piensa en ello como la etiqueta nutricional de tu aplicaci\u00f3n \u2014 excepto que en lugar de calor\u00edas y sodio, est\u00e1s … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55,59],"tags":[],"post_folder":[],"class_list":["post-662","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-software-supply-chain"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/662","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/comments?post=662"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/662\/revisions"}],"predecessor-version":[{"id":862,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/662\/revisions\/862"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=662"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=662"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=662"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=662"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Ley de Ciberresiliencia de la UE (CRA)<\/h3>\n
M\u00e1s all\u00e1 del cumplimiento: valor operativo<\/h3>\n
\n
Syft: el generador de SBOMs dedicado de Anchore<\/h2>\n
Capacidades principales<\/h3>\n
\n
cosign<\/code> e in-toto<\/code>. Puedes canalizar la salida SBOM de Syft directamente hacia cosign attest<\/code> para producir attestations SBOM firmadas.<\/li>\n<\/ul>\nFortalezas<\/h3>\n
Limitaciones<\/h3>\n
Ejemplo de uso<\/h3>\n
# Generate CycloneDX SBOM from a container image\nsyft packages registry.example.com\/myapp:latest -o cyclonedx-json > sbom.cdx.json\n\n# Generate SPDX SBOM from a local directory\nsyft dir:\/path\/to\/source -o spdx-json > sbom.spdx.json\n\n# Attest the SBOM with cosign\ncosign attest --predicate sbom.cdx.json --type cyclonedx my-image:latest<\/code><\/pre>\nTrivy: el esc\u00e1ner todo-en-uno de Aqua Security con modo SBOM<\/h2>\n
Capacidades principales<\/h3>\n
\n
trivy image --format cosign-vuln<\/code>, y se integra con cosign para flujos de trabajo de attestation de SBOMs.<\/li>\n<\/ul>\nFortalezas<\/h3>\n
Limitaciones<\/h3>\n
Ejemplo de uso<\/h3>\n
# Generate CycloneDX SBOM from a container image\ntrivy image --format cyclonedx --output sbom.cdx.json registry.example.com\/myapp:latest\n\n# Generate SPDX SBOM from a filesystem\ntrivy fs --format spdx-json --output sbom.spdx.json \/path\/to\/source\n\n# Scan an existing SBOM for vulnerabilities\ntrivy sbom sbom.cdx.json\n\n# Combined: generate SBOM + scan in one pass\ntrivy image --format json --list-all-pkgs registry.example.com\/myapp:latest<\/code><\/pre>\nCycloneDX CLI: el kit de herramientas SBOM nativo de OWASP<\/h2>\n
cyclonedx-maven-plugin<\/code>, cyclonedx-npm<\/code>, cyclonedx-gomod<\/code>) que producen SBOMs durante el proceso de compilaci\u00f3n.<\/p>\nCapacidades principales<\/h3>\n
\n
Fortalezas<\/h3>\n
Limitaciones<\/h3>\n
Ejemplo de uso<\/h3>\n
# Generate SBOM during Maven build\nmvn org.cyclonedx:cyclonedx-maven-plugin:makeBom\n\n# Generate SBOM from npm project\nnpx @cyclonedx\/cyclonedx-npm --output-file sbom.cdx.json\n\n# Merge multiple SBOMs\ncyclonedx merge --input-files sbom-api.cdx.json sbom-frontend.cdx.json --output-file product-sbom.cdx.json\n\n# Validate an SBOM against the schema\ncyclonedx validate --input-file sbom.cdx.json --fail-on-errors\n\n# Diff two SBOMs to see what changed between releases\ncyclonedx diff --from v1-sbom.cdx.json --to v2-sbom.cdx.json<\/code><\/pre>\nTabla comparativa directa<\/h2>\n
\n\n
\n \nCaracter\u00edstica<\/th>\n Syft<\/th>\n Trivy<\/th>\n CycloneDX CLI + Plugins<\/th>\n<\/tr>\n<\/thead>\n \n Prop\u00f3sito principal<\/strong><\/td>\n Generaci\u00f3n de SBOMs<\/td>\n Esc\u00e1ner de seguridad todo-en-uno<\/td>\n Manipulaci\u00f3n de SBOMs + generaci\u00f3n en tiempo de compilaci\u00f3n<\/td>\n<\/tr>\n \n Salida SPDX<\/strong><\/td>\n JSON, tag-value (excelente)<\/td>\n JSON (bueno)<\/td>\n Solo conversi\u00f3n limitada<\/td>\n<\/tr>\n \n Salida CycloneDX<\/strong><\/td>\n JSON, XML (excelente)<\/td>\n JSON (excelente)<\/td>\n JSON, XML, Protobuf (nativo, el mejor)<\/td>\n<\/tr>\n \n Escaneo de contenedores<\/strong><\/td>\n S\u00ed (registro, daemon, tarball)<\/td>\n S\u00ed (registro, daemon, tarball)<\/td>\n No (solo tiempo de compilaci\u00f3n)<\/td>\n<\/tr>\n \n Escaneo de sistema de archivos<\/strong><\/td>\n S\u00ed<\/td>\n S\u00ed<\/td>\n Mediante plugins de lenguaje<\/td>\n<\/tr>\n \n An\u00e1lisis binario<\/strong><\/td>\n Fuerte (binarios Go, Rust)<\/td>\n Moderado<\/td>\n Ninguno<\/td>\n<\/tr>\n \n Escaneo de vulnerabilidades<\/strong><\/td>\n No (usar Grype)<\/td>\n S\u00ed (integrado)<\/td>\n No (usar herramienta separada)<\/td>\n<\/tr>\n \n Precisi\u00f3n (profundidad de dependencias)<\/strong><\/td>\n Excelente<\/td>\n Muy buena<\/td>\n La mejor (resoluci\u00f3n en tiempo de compilaci\u00f3n)<\/td>\n<\/tr>\n \n Fusi\u00f3n\/comparaci\u00f3n de SBOMs<\/strong><\/td>\n No<\/td>\n No<\/td>\n S\u00ed (nativo)<\/td>\n<\/tr>\n \n Soporte VEX<\/strong><\/td>\n Mediante Grype\/Vunnel<\/td>\n Soporte OpenVEX<\/td>\n VEX nativo de CycloneDX<\/td>\n<\/tr>\n \n Firma de attestations<\/strong><\/td>\n Mediante integraci\u00f3n con cosign<\/td>\n Mediante integraci\u00f3n con cosign<\/td>\n Attestation BOM-Link<\/td>\n<\/tr>\n \n Integraci\u00f3n CI\/CD<\/strong><\/td>\n GitHub Action, CLI<\/td>\n GitHub Action, CLI, operador Kubernetes<\/td>\n Plugin de compilaci\u00f3n por lenguaje<\/td>\n<\/tr>\n \n Velocidad (contenedor t\u00edpico)<\/strong><\/td>\n R\u00e1pido (15-30s)<\/td>\n Moderado (20-60s con descarga de BD)<\/td>\n El m\u00e1s r\u00e1pido (integrado en compilaci\u00f3n, sin escaneo separado)<\/td>\n<\/tr>\n \n Escaneo de cl\u00faster Kubernetes<\/strong><\/td>\n No<\/td>\n S\u00ed<\/td>\n No<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Precisi\u00f3n y completitud: donde realmente importa<\/h2>\n
cyclonedx-maven-plugin<\/code> se ejecuta, ve exactamente el mismo \u00e1rbol de dependencias que Maven resolvi\u00f3. No hay adivinanzas, no hay coincidencias heur\u00edsticas \u2014 lee el grafo resuelto directamente.<\/p>\nIntegraci\u00f3n CI\/CD: incorporando SBOMs en tu pipeline<\/h2>\n
Syft en CI\/CD<\/h3>\n
anchore\/sbom-action<\/code>) 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\u00ednalo con anchore\/scan-action<\/code> (Grype) para puertas de control de vulnerabilidades.<\/p>\nTrivy en CI\/CD<\/h3>\n
aquasecurity\/trivy-action<\/code>), operador Kubernetes (Trivy Operator<\/strong>) y salida SARIF para integraci\u00f3n con GitHub Code Scanning. Un solo paso de Trivy puede producir un SBOM, escanear vulnerabilidades, verificar configuraciones incorrectas y detectar secretos \u2014 reemplazando tres o cuatro herramientas separadas.<\/p>\nCycloneDX en CI\/CD<\/h3>\n
@cyclonedx\/cyclonedx-npm<\/code>. Este enfoque nativo de compilaci\u00f3n significa que el SBOM se genera como un artefacto de compilaci\u00f3n junto a tu aplicaci\u00f3n, sin necesidad de un paso de escaneo separado.<\/p>\nCu\u00e1ndo usar cada herramienta<\/h2>\n
Elige Syft cuando:<\/h3>\n
\n
Elige Trivy cuando:<\/h3>\n
\n
Elige CycloneDX CLI + Plugins cuando:<\/h3>\n
\n
Pipeline combinado: usando las tres herramientas juntas<\/h2>\n
# Stage 1: Build-time SBOM (most accurate dependency graph)\n# In your Maven\/npm\/Go build step:\nmvn org.cyclonedx:cyclonedx-maven-plugin:makeBom\n# Output: target\/bom.json (CycloneDX format)\n\n# Stage 2: Container-level SBOM (catches OS packages + runtime deps)\nsyft packages myapp:${BUILD_TAG} -o cyclonedx-json > container-sbom.cdx.json\n\n# Stage 3: Merge build-time and container SBOMs\ncyclonedx merge \\\n --input-files target\/bom.json container-sbom.cdx.json \\\n --output-file merged-sbom.cdx.json\n\n# Stage 4: Validate the merged SBOM\ncyclonedx validate --input-file merged-sbom.cdx.json --fail-on-errors\n\n# Stage 5: Vulnerability scan the merged SBOM\ntrivy sbom merged-sbom.cdx.json --exit-code 1 --severity CRITICAL,HIGH\n\n# Stage 6: Sign and attest\ncosign attest --predicate merged-sbom.cdx.json \\\n --type cyclonedx myapp:${BUILD_TAG}<\/code><\/pre>\nConsideraciones de rendimiento<\/h2>\n
\n
--skip-db-update<\/code> en CI (con cach\u00e9 precargada) elimina esta sobrecarga.<\/li>\nAttestation y firma: demostrando la procedencia del SBOM<\/h2>\n
cosign attest<\/code>.<\/p>\ntrivy image --format cosign-vuln<\/code> produce informes de vulnerabilidades listos para attestation.<\/p>\nConclusi\u00f3n<\/h2>\n