Cadena de suministro de software
SBOM: qué es una lista de materiales de software y cómo crearla
Un SBOM (software bill of materials o lista de materiales de software) es un registro formal y legible por máquina de los componentes de un software y de las relaciones entre ellos. El Cyber Resilience Act obliga a los fabricantes a elaborar uno que cubra, como mínimo, las dependencias de máximo nivel, en un formato de uso común como CycloneDX o SPDX.
Plan gratuito, sin tarjeta.
¿Qué es un SBOM?
Piensa en la lista de ingredientes de un producto. Para cada componente registra un nombre, una versión e, idealmente, un identificador único como un package URL, junto con el proveedor y las relaciones entre componentes: qué biblioteca arrastra a cuál. El Reglamento de Ciberresiliencia, cuya versión en español lo denomina «nomenclatura de materiales de los programas informáticos», lo define como un registro formal que contiene los detalles y las relaciones de la cadena de suministro de los componentes incluidos en los elementos de software de un producto.
Un SBOM no dice si un componente es vulnerable. Es el inventario que permite responder a esa pregunta, hoy y cada vez que se publique una nueva vulnerabilidad.
¿Es obligatorio un SBOM?
Para los fabricantes de productos incluidos en el ámbito del Cyber Resilience Act, sí. El anexo I, parte II, les exige identificar y documentar las vulnerabilidades y los componentes, también mediante la elaboración de un SBOM en un formato de uso común y legible por máquina que incluya, como mínimo, las dependencias de máximo nivel. El SBOM forma parte de la documentación técnica y debe entregarse a la autoridad de vigilancia del mercado que lo pida mediante solicitud motivada; el Reglamento no exige publicarlo.
La Comisión puede especificar el formato y los elementos mediante un acto de ejecución. Hasta entonces, CycloneDX y SPDX son los formatos que más herramientas generan y aceptan.
CycloneDX frente a SPDX
Los dos son estándares abiertos y los dos cuentan con un soporte amplio. La elección suele depender de las herramientas que ya usan tus clientes y proveedores; muchos equipos mantienen ambos.
| CycloneDX | SPDX | |
|---|---|---|
| Mantenido por | OWASP y Ecma International (ECMA-424) | Linux Foundation; publicado como ISO/IEC 5962:2021 |
| Origen | Seguridad de aplicaciones y riesgo de la cadena de suministro | Cumplimiento de licencias |
| Serializaciones | JSON, XML, Protocol Buffers | JSON, tag-value, RDF, YAML y otras |
| Datos de vulnerabilidades | Soporte VEX integrado | Es habitual usar documentos VEX separados |
Cómo generar un SBOM
El SBOM más preciso es el que se genera a partir de lo que realmente distribuyes. En el código fuente, eso significa los lockfiles y manifiestos que resuelve la compilación; en el firmware y las imágenes de contenedor, los archivos que hay dentro de la imagen, porque las herramientas de compilación pueden pasar por alto paquetes que se añaden más adelante en el pipeline.
- Genéralo en el pipeline de compilación, en cada versión, no a mano.
- Analiza el artefacto final además del código fuente, incluidas las imágenes de firmware y de contenedor.
- Registra versiones exactas y package URLs, no rangos de versiones.
- Conserva el SBOM de cada versión que siga con soporte; lo necesitarás cuando aparezca una nueva vulnerabilidad.
- Vuelve a contrastar los SBOM guardados con los nuevos datos de vulnerabilidades en lugar de recompilar versiones antiguas.
Qué hacer con un SBOM una vez que lo tienes
Un SBOM demuestra su valor cuando se publica una nueva vulnerabilidad. Con un inventario por versión, la pregunta «¿cuáles de nuestros productos llevan este componente?» se responde en minutos en lugar de días. Esa rapidez importa con el artículo 14 del CRA, donde una vulnerabilidad aprovechada activamente pone en marcha un plazo de notificación de 24 horas.
Compleméntalo con declaraciones VEX (Vulnerability Exploitability eXchange) para registrar qué vulnerabilidades de la lista no afectan al producto y por qué, de modo que clientes y autoridades vean la decisión además del inventario.
Disponible hoy en KROMSE
KROMSE genera y lee SBOM hoy.
- Cada análisis de un repositorio, una imagen de contenedor o una imagen de firmware basada en Linux genera un SBOM CycloneDX JSON y otro SPDX JSON para descargar.
- Sube SBOM CycloneDX (JSON 1.2 a 1.7, o XML) o SPDX 2.2 y 2.3 (JSON o tag-value), además de manifiestos de compilación de Yocto y Buildroot; cada subida se contrasta automáticamente con OSV.dev.
- Envía SBOM desde tu CI con un token de API del espacio de trabajo; hay fragmentos listos para GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, Bitbucket Pipelines, Yocto, Buildroot, Zephyr y ESP-IDF.
- Exportación VEX en CycloneDX 1.6 VEX y OpenVEX, y cada declaración VEX importada la acepta una persona.
- En los planes de pago, el último SBOM de cada producto se vuelve a contrastar con OSV cada seis horas.
Próximamente
En la hoja de ruta, todavía no disponible. Las fechas son objetivos, no promesas; esta página cambia el mismo día en que una funcionalidad está operativa.
- Próximamente · T1 2027Componentes de hardware. KROMSE contrastará los componentes de hardware de tu producto con los avisos de hardware publicados.
- Próximamente · T1 2027Seguridad de agentes y modelos de IA. KROMSE generará una lista de materiales de IA (AI bill of materials), revisará las herramientas y los permisos que pueden usar tus agentes y detectará archivos de modelo inseguros.
Preguntas frecuentes
¿Qué significa SBOM?
Software bill of materials, o lista de materiales de software: una lista formal y legible por máquina de los componentes de un software, con sus versiones, proveedores y relaciones. Funciona como una lista de ingredientes y es el punto de partida para averiguar si un producto contiene un componente vulnerable.
¿Exige el Cyber Resilience Act un SBOM?
Sí. El anexo I, parte II, obliga a los fabricantes de productos con elementos digitales a elaborar un SBOM en un formato de uso común y legible por máquina que cubra, como mínimo, las dependencias de máximo nivel. Forma parte de la documentación técnica y se facilita a las autoridades de vigilancia del mercado previa solicitud motivada.
¿Qué formato de SBOM debo usar?
CycloneDX y SPDX son los dos de uso común, legibles por máquina y con un soporte amplio. Elige el que esperan tus clientes y tus herramientas, o genera ambos. La coherencia entre versiones importa más que el formato elegido.
¿Tengo que publicar mi SBOM?
El CRA no obliga a los fabricantes a hacer público el SBOM. Debe formar parte de la documentación técnica y entregarse a la autoridad de vigilancia del mercado que lo solicite. Muchas empresas comparten sus SBOM con los clientes bajo contrato.
¿Puedo crear un SBOM de firmware?
Sí. En el firmware basado en Linux, lo fiable es desempaquetar la imagen y enumerar los paquetes y binarios que contiene, en lugar de basarse solo en los archivos de compilación. KROMSE lo hace hoy con imágenes de firmware basadas en Linux; las imágenes bare-metal y RTOS están en la hoja de ruta.