SBOM explicada: CycloneDX frente a SPDX, VEX y por qué la piden

El software moderno, más que escribirse, se ensambla. Una aplicación típica incorpora cientos de paquetes open source, cada uno con sus propias dependencias, además de una imagen base de contenedor, librerías del sistema y, cada vez más, modelos de IA. Cuando aparece una vulnerabilidad crítica en una librería popular, la primera pregunta siempre es la misma: "¿La usamos? ¿Dónde?" Los equipos que no tienen respuesta pasan días buscando en repositorios y preguntando por los pasillos.

Una Software Bill of Materials (SBOM) es esa respuesta preparada de antemano. En esta guía verás qué contiene una SBOM, en qué se diferencian CycloneDX y SPDX, por qué clientes y reguladores la exigen y cómo mantenerla útil para que no se quede en papeleo de cumplimiento.

Qué es una SBOM

Una SBOM es un inventario formal y legible por máquina de los componentes que forman un software y de las relaciones entre ellos. Es como la lista de ingredientes de una etiqueta alimentaria, pero aplicada al código.

En Estados Unidos, la NTIA publicó un conjunto de elementos mínimos muy citado. Dicho de forma sencilla, cada componente debería describirse con:

• Proveedor — quién lo creó o lo mantiene.
• Nombre y versión del componente.
• Identificadores únicos — como un Package URL (purl) o un CPE, para que las herramientas puedan cruzarlo con bases de datos de vulnerabilidades.
• Relaciones de dependencia — qué incluye a qué, para distinguir dependencias directas y transitivas.
• Autor de los datos de la SBOM y marca de tiempo.

Las SBOM más completas añaden licencias, hashes criptográficos, ubicaciones de descarga e información de compilación. Las licencias importan para la revisión legal; los hashes, para la integridad y para detectar paquetes manipulados o sustituidos.

CycloneDX frente a SPDX

Dos formatos dominan el mercado, y la mayoría de herramientas admiten ambos.

SPDX (Software Package Data Exchange) es un proyecto de la Linux Foundation que nació centrado en el cumplimiento de licencias y está publicado como estándar internacional (ISO/IEC 5962). Destaca describiendo paquetes, ficheros, licencias y copyright, y con el tiempo se ha ampliado a casos de uso de seguridad.

CycloneDX es un proyecto de OWASP diseñado desde el principio para casos de seguridad y riesgo de la cadena de suministro, y posteriormente estandarizado a través de Ecma International. Además de componentes de software, puede describir servicios, hardware, vulnerabilidades, declaraciones VEX y modelos y datasets de machine learning.

¿Cuál elegir? En la práctica:

• Si tu motivación principal es el cumplimiento de licencias o un cliente pide SPDX expresamente, usa SPDX.
• Si tu motivación principal es la gestión de vulnerabilidades y la seguridad de la cadena de suministro, CycloneDX suele encajar mejor.
• Muchas organizaciones generan ambos, porque la conversión entre ellos está bien resuelta para los campos principales.

El formato importa mucho menos que la completitud, la precisión y la actualidad. Una SBOM con un formato impecable que omite dependencias transitivas o tiene seis meses de antigüedad sirve de poco.

Por qué compradores y reguladores piden SBOM

Varias fuerzas han convertido la SBOM de práctica minoritaria en requisito de compra:

• La Orden Ejecutiva 14028 de EE. UU. (mayo de 2021), sobre la mejora de la ciberseguridad del país, pidió a las agencias federales reforzar la seguridad de la cadena de suministro de software, incluida la entrega de SBOM para el software vendido a la Administración. Eso llevó la SBOM a los contratos con proveedores y, de ahí, al resto del mercado.
• El Cyber Resilience Act (CRA) de la UE fija requisitos de ciberseguridad para los productos con elementos digitales comercializados en la UE. Entre otras obligaciones, los fabricantes deben identificar y documentar los componentes de sus productos, incluida la elaboración de una SBOM, y gestionar las vulnerabilidades durante todo el periodo de soporte. Sus obligaciones entran en vigor de forma escalonada a lo largo de varios años, así que es el momento de construir la capacidad.
• Los compradores corporativos incluyen cada vez más la SBOM en cuestionarios de seguridad y contratos, sobre todo en sectores regulados donde marcos como NIS2 y DORA dan peso al riesgo de terceros y de la cadena de suministro. Consulta nuestro resumen de NIS2 y DORA para la gestión de vulnerabilidades.

El denominador común: si algo en tu producto es vulnerable, tus clientes quieren saberlo rápido y con evidencias, no tras una semana de investigación.

Cómo mantener útiles las SBOM: VEX y generación continua

Una SBOM por sí sola enumera componentes. Cruzada con bases de datos de vulnerabilidades, puede generar una larga lista de CVE, muchas de las cuales no afectan realmente al producto porque la función vulnerable nunca se invoca o la configuración afectada no se usa. Enviar esa lista en bruto a los clientes solo genera ruido y alarma.

VEX (Vulnerability Exploitability eXchange) resuelve esto. Una declaración VEX indica, para un producto y una vulnerabilidad concretos, si el producto no está afectado, está afectado, está corregido o está en investigación, con su justificación. VEX puede expresarse en CycloneDX, en CSAF o en formatos ligeros como OpenVEX. Combinado con el análisis de alcanzabilidad, te permite decir "sí, esa librería está presente, pero el código vulnerable no es alcanzable" y demostrarlo.

El segundo requisito es la generación continua. Las dependencias cambian con cada merge. La SBOM debe generarse automáticamente en el pipeline para cada versión, versionarse junto al artefacto y reevaluarse con nuevos datos de vulnerabilidades aunque el código no cambie, porque cada día se publican CVE nuevas contra componentes que ya distribuyes.

Una lista de comprobación práctica:

1. Genera SBOM en CI para cada build, no a mano antes de una auditoría.
2. Incluye dependencias transitivas y los paquetes de la imagen base del contenedor.
3. Usa identificadores estables (purl) para que el cruce con datos de vulnerabilidades sea fiable.
4. Guarda la SBOM de cada versión para poder responder "¿qué versiones están afectadas?".
5. Crúzala de forma continua con nuevas vulnerabilidades e inteligencia sobre paquetes maliciosos.
6. Publica VEX para las vulnerabilidades por las que van a preguntar tus clientes.

AI-BOM: el siguiente inventario

Las aplicaciones que usan modelos de lenguaje añaden componentes nuevos: los propios modelos, sus proveedores, datasets, prompts, herramientas de agentes y servidores MCP. Una AI-BOM extiende la idea de la SBOM a estos elementos para que sepas de qué modelos e integraciones de IA depende cada aplicación. CycloneDX ya permite describir modelos y datasets de machine learning. A medida que se extienden las funciones de IA, la pregunta "¿lo usamos? ¿dónde?" se hará también sobre los modelos; consulta nuestra guía de seguridad en aplicaciones LLM para los riesgos asociados.

Preguntas frecuentes

¿Una SBOM es un control de seguridad en sí misma? No. Es un inventario. Su valor está en cruzarla continuamente con datos de vulnerabilidades y amenazas, y en actuar sobre los resultados.

¿Debo compartir mi SBOM con los clientes? Cada vez más clientes lo esperan. Muchas organizaciones la comparten bajo petición y con acuerdo de confidencialidad, junto con VEX para explicar qué hallazgos no aplican.

¿CycloneDX o SPDX? Ambos sirven para la mayoría de usos. Elige según lo que pidan tus clientes y si tu foco es el cumplimiento de licencias o la seguridad; generar ambos es habitual.

Cómo ayuda priorIQ.ai

CodeIQ genera SBOM en CycloneDX y SPDX a partir de tus repositorios y contenedores como parte de su SCA, con análisis de alcanzabilidad para separar las vulnerabilidades alcanzables del ruido, detección de paquetes maliciosos y una AI-BOM para las aplicaciones que usan LLM. Su control en el pipeline impide que nuevas dependencias de riesgo lleguen a una versión, y el auto-fix con IA puede abrir pull requests verificadas para actualizarlas. Los hallazgos llegan a PriorIQ Core, donde se priorizan con CVSS, EPSS, CISA KEV y contexto de negocio junto al resto de tu exposición.

Descubre cómo encaja CodeIQ con el escaneo SAST, SCA, de secretos e IaC. Solicita una demo.