Gestión de SBOM para la cadena de suministro de software

Dos formatos abiertos dominan la práctica. CycloneDX procede de la comunidad OWASP y se estandariza internacionalmente a través del comité TC54 de Ecma: la versión 1.6 se publicó en junio de 2024 como ECMA-424 (1.ª edición), y la versión 1.7, aparecida en octubre de 2025, se publicó en diciembre de 2025 como ECMA-424 (2.ª edición), con un modelado ampliado, entre otros, para artefactos criptográficos y modelos de ML. SPDX se desarrolla bajo el paraguas de la Linux Foundation; la norma ISO/IEC 5962:2021 estandariza la versión 2.2.1, mientras que la especificación actual 3.0.1 (diciembre de 2024) atraviesa el proceso ISO como ISO/IEC DIS 5962. SPDX tiene sus raíces en el cumplimiento de licencias, mientras que CycloneDX está más orientado a casos de uso de seguridad; ambos cumplen el requisito del CRA de un «formato de uso común y legible por máquina».

En 2021, la NTIA definió por primera vez los componentes mínimos de una SBOM en tres categorías: campos de datos (entre otros, proveedor, nombre del componente, versión, identificadores únicos, relaciones de dependencia, autor de la SBOM y marca de tiempo), soporte de automatización y procesos de acompañamiento. En julio de 2026, la CISA, la NSA, el FBI y agencias asociadas internacionales publicaron los «2026 Minimum Elements for a SBOM», que sustituyen a la versión de la NTIA. Entre las novedades figuran los hashes de componentes, la información de licencias, el nombre de la herramienta de generación y el contexto de generación; los campos existentes se precisaron y se denominaron de forma más uniforme. El contenido mínimo se entiende expresamente como un umbral inferior: según el caso de uso, conviene añadir información adicional.

El momento más fiable para generar la SBOM es el build: allí se conocen todas las dependencias resueltas, incluidas las versiones exactas, algo que ni un análisis puro del código fuente ni un análisis binario posterior pueden reconstruir por completo. En la práctica, esta tarea la asumen plugins para gestores de paquetes y sistemas de build o generadores como cdxgen y Syft, integrados como paso fijo de la pipeline de CI/CD. Cada versión publicada recibe así su propia SBOM versionada, que se archiva junto con los artefactos de build y, en el mejor de los casos, se firma. El contexto de generación exigido por los CISA Elements 2026 hace además transparente en qué fase del ciclo de vida se creó una SBOM.

Una SBOM solo despliega su valor mediante la correlación continua con datos de vulnerabilidades procedentes de fuentes como NVD, OSV o GitHub Advisories: así, ante una nueva CVE puede responderse de inmediato qué productos contienen componentes afectados. Dado que un componente vulnerable no implica automáticamente un producto vulnerable, VEX (Vulnerability Exploitability eXchange) complementa la SBOM con declaraciones del fabricante legibles por máquina sobre la afectación real; la CISA publicó en abril de 2023 requisitos mínimos al respecto. Como formatos de intercambio sirven el Common Security Advisory Framework (CSAF 2.0, estándar OASIS desde noviembre de 2022, con un perfil VEX propio) y CycloneDX con VEX integrado. Bien empleada, esta combinación reduce considerablemente los falsos positivos y centra la corrección en las vulnerabilidades realmente explotables.

El Cyber Resilience Act (Reglamento (UE) 2024/2847, en vigor desde el 10 de diciembre de 2024) convierte la SBOM en obligatoria: el anexo I, parte II, exige a los fabricantes documentar vulnerabilidades y componentes, incluida una lista de materiales de software en un formato de uso común y legible por máquina que cubra como mínimo las dependencias de primer nivel (top-level dependencies). La SBOM forma parte de la documentación técnica y debe presentarse a las autoridades de vigilancia del mercado cuando la soliciten; no existe obligación de publicarla. Las obligaciones principales rigen a partir del 11 de diciembre de 2027, y las obligaciones de notificación ya desde el 11 de septiembre de 2026. El BSI concreta los requisitos en la directriz técnica TR-03183 parte 2 (versión 2.1.0, agosto de 2025) con especificaciones formales y de contenido para cada campo de datos, incluidas recomendaciones de correspondencia con SPDX y CycloneDX y, desde la versión 2.1.0, el tratamiento de componentes virtuales y referenciados.

Para la operación continua se ha consolidado el patrón de una plataforma SBOM central, cuyo ejemplo open source más conocido es OWASP Dependency-Track. La plataforma consume y produce SBOM y documentos VEX en formato CycloneDX, inventaría componentes en todos los proyectos y versiones, y los coteja continuamente con fuentes de vulnerabilidades como NVD, OSV, GitHub Advisories o Snyk. Un motor de políticas aplica de forma automatizada directrices de seguridad, licencias y operación; el diseño API-first permite la conexión directa con pipelines de CI/CD. Lo decisivo es el cambio de paradigma: en lugar de escaneos puntuales, todo el portafolio se reevalúa automáticamente con cada nueva notificación de vulnerabilidad.