SBOM (lista de materiales de software) — qué exige el Cyber Resilience Act

Una lista de materiales de software es un artefacto aburrido con consecuencias desproporcionadas. Es una lista: de qué componentes está construido el software de un producto, en qué versiones, de qué proveedores, bajo qué licencias. Hasta hace poco era una comodidad interna del equipo de ingeniería. Con el Reglamento (UE) 2024/2847 — el Cyber Resilience Act — pasa a ser un requisito esencial, y de los que las autoridades de vigilancia del mercado pueden exigir ver.

La razón es sencilla. Cuando se publica una vulnerabilidad en una biblioteca de uso extendido, solo importa una pregunta: ¿nos afecta? Sin una lista de materiales, la respuesta cuesta semanas de arqueología manual por repositorios y servidores de compilación. Con ella cuesta una consulta. El CRA convierte esa realidad operativa en un deber jurídico — y, como en casi todas las obligaciones sobre datos de producto, la cuestión no es tanto redactar un documento una vez como mantener los datos ciertos a lo largo de cada versión durante una década. Esa es la misma disciplina que exige el pasaporte digital del producto en otros ámbitos del derecho de producto de la UE.

Qué es realmente un SBOM

Quitado el acrónimo, un SBOM es un inventario con procedencia. Para cada componente que acaba en el producto entregado registra, como mínimo, cómo se llama el componente, qué versión tiene y quién lo suministró. Las listas mejores añaden la licencia, un hash criptográfico que permite identificar el componente sin ambigüedad y las relaciones de dependencia — qué componente arrastró a cuál.

La distinción que más importa es la profundidad. Un SBOM de primer nivel enumera lo que el código declara directamente: las doce bibliotecas del archivo de manifiesto. Un SBOM transitivo resuelve lo que esas doce arrastran, y lo que arrastran aquellas, hasta las hojas del árbol. En aplicaciones reales, doce dependencias declaradas se convierten rutinariamente en varios cientos de dependencias efectivas. Las vulnerabilidades aparecen con la misma facilidad cuatro niveles más abajo que en la superficie — y por eso la distancia entre el umbral del CRA y lo que contiene un SBOM útil no es académica.

La segunda distinción es cuándo se genera. Un SBOM generado a partir del código fuente describe lo que el equipo pretendía. Un SBOM generado a partir del resultado de la compilación describe lo que realmente se entregó, incluidos los componentes que aportan el sistema de compilación, la imagen base del contenedor o el binario de un proveedor. Ambos divergen con más frecuencia de la que los equipos esperan, y solo el segundo sirve como prueba.

Qué exige el CRA — y qué no

El anexo I parte II del Reglamento (UE) 2024/2847 recoge los requisitos de gestión de vulnerabilidades que un fabricante debe cumplir durante todo el periodo de soporte. El primero es la lista de materiales: los fabricantes deben identificar y documentar los componentes contenidos en el producto, entre otras cosas elaborando una lista de materiales de software en un formato de uso común y legible por máquina que cubra al menos las dependencias de primer nivel, y mantenerla actualizada.

Tres elementos de esa frase merecen una lectura atenta.

«Formato de uso común y legible por máquina». El reglamento no nombra formato de forma deliberada. Es la práctica habitual en el derecho de producto de la UE: el texto legal enuncia la propiedad y las normas armonizadas aportan el detalle técnico. En la práctica el campo se ha condensado en dos formatos, y elegir cualquiera de ellos es defendible.

«Al menos las dependencias de primer nivel». Es un suelo, no un objetivo. La ley no obliga a resolver el árbol transitivo completo. Tampoco impide que una autoridad, un organismo de certificación o un gran cliente corporativo pidan más — ni hace útil un SBOM limitado al primer nivel para el fin que justifica su existencia. Trate el umbral como el mínimo de cumplimiento y el árbol transitivo como el requisito operativo.

«Mantenerla actualizada». La obligación es continua y corre durante el periodo de soporte. Una lista elaborada una vez para el expediente técnico y nunca regenerada diverge de la realidad en la primera versión correctiva.

Igual de importante es lo que el CRA no exige:

Ningún deber de publicación. Hacer público el SBOM es una decisión comercial. El deber legal es ponerlo a disposición de la vigilancia del mercado a petición. Algunos sectores y grandes compradores lo exigirán por contrato: eso es otra presión, no una jurídica.
Ningún formato ni perfil impuesto. No hay mandato de CycloneDX frente a SPDX, ni lista mínima de campos en el propio reglamento.
Ningún SBOM en el pasaporte de producto. El CRA no crea pasaporte, ni soporte de datos, ni registro.

Formatos: CycloneDX, SPDX y SWID

	CycloneDX	SPDX	Etiquetas SWID
Origen	OWASP	Linux Foundation	ISO/IEC
Norma	ECMA-424	ISO/IEC 5962:2021	ISO/IEC 19770-2
Diseñado para	seguridad de aplicaciones	cumplimiento de licencias y procedencia	gestión de activos de software
Fortaleza típica	flujos de vulnerabilidades, CI/CD, VEX	nivel de archivo y fragmento, compras	identificación de software instalado
Inventario completo de dependencias	sí	sí	no es su propósito

CycloneDX salió de la comunidad de seguridad de aplicaciones y se construyó desde el principio para casos de uso de seguridad. Su ventaja práctica es el ecosistema que lo rodea: se extiende a listas de materiales de hardware, SaaS, aprendizaje automático y criptografía, y transporta VEX — Vulnerability Exploitability eXchange —, que permite declarar que una vulnerabilidad conocida en un componente listado no es explotable en su producto. Para un fabricante con obligaciones de gestión de vulnerabilidades bajo el CRA, poder decir «presente pero no explotable, y este es el motivo» en forma legible por máquina ahorra muchísimo trabajo.

SPDX nació en el cumplimiento de licencias y lleva ese origen como profundidad: describe software hasta el nivel de archivos y fragmentos de código, y es la elección natural cuando el requisito lo impulsan las compras, la revisión jurídica y la documentación formal.

Las etiquetas SWID aparecen en casi todas las comparativas de formatos y en algunas guías oficiales, pero resuelven otro problema: identificar el software instalado en una máquina. No sustituyen a un inventario de dependencias.

La respuesta honesta sobre la elección: los dos formatos principales convergen, las herramientas soportan ambos y existen conversores. Elija el que su cadena de herramientas actual genere de forma más fiable y estandarice sobre él. Un SBOM roto en el formato «mejor» es peor que uno correcto en cualquiera de los dos.

Los campos de datos — tres referencias

El CRA fija un suelo. Tres documentos publicados dicen qué contiene realmente un SBOM serio.

La referencia alemana: BSI TR-03183-2

La oficina federal alemana de seguridad de la información publica la Guía técnica TR-03183: requisitos de ciberresiliencia para fabricantes y productos, parte 2: lista de materiales de software (SBOM). No es derecho vinculante, pero es la especificación pública más concreta escrita expresamente contra el CRA, y cada vez se cita más en los cuestionarios alemanes a proveedores. La versión 2.1.0 se publicó en agosto de 2025.

Exige serialización en JSON o XML, en CycloneDX versión 1.6 o superior o SPDX versión 3.0.1 o superior. Sus campos se dividen en tres categorías: obligatorios (siempre), adicionales (obligatorios cuando el dato subyacente existe) y opcionales.

Obligatorios a nivel de documento:

creador del SBOM — dirección de correo o URL que identifique al productor,
marca de tiempo en formato ISO 8601.

Obligatorios para cada componente:

nombre del componente,
versión del componente,
creador del componente, es decir, el proveedor,
nombre de archivo del componente,
dependencias de otros componentes — resueltas de forma recursiva,
licencias de distribución,
hash del componente desplegable, SHA-512,
si el componente es ejecutable, si es un archivo comprimido, si es estructurado.

Fíjese en la distancia con el texto del CRA. La resolución recursiva del árbol completo es bastante más trabajo que las dependencias de primer nivel, y el requisito de SHA-512 obliga a generar el SBOM a partir de artefactos de compilación reales y no de un archivo de manifiesto. Si vende al mercado alemán, planifique contra esta referencia y no contra el umbral del reglamento.

La línea base estadounidense: elementos mínimos de la NTIA

El documento Minimum Elements for a Software Bill of Materials de la NTIA, de 2021, definió siete campos base a los que todavía apuntan la mayoría de las herramientas: nombre del proveedor, nombre del componente, versión, otros identificadores únicos, relación de dependencia, autor de los datos del SBOM y marca de tiempo. La guía estadounidense se ha revisado desde entonces — CISA llevó a cabo una consulta pública sobre un conjunto actualizado de elementos mínimos que añade campos como el hash del componente, la licencia y el contexto de generación. Si ya produce SBOM para clientes federales estadounidenses, está cerca del umbral del CRA; todavía no está en la referencia alemana.

Las normas armonizadas, aún en curso

La petición de normalización de la Comisión para el CRA fue aceptada por CEN, CENELEC y ETSI el 3 de abril de 2025 y abarca un programa de normas horizontales y verticales. La relevante aquí es la serie horizontal EN 40000, en particular la norma sobre gestión de vulnerabilidades, donde se concretará la práctica del SBOM. En el momento de escribir estas líneas siguen en fase de redacción y aprobación, y la Comisión ha planteado retrasar los plazos de entrega.

La consecuencia práctica: no espere a la norma armonizada. Su contenido se está redactando contra el mismo texto del anexo I, y el trabajo operativo — instrumentar la compilación para que emita un SBOM por versión — no cambia según qué lista de campos acabe imponiéndose. Esperar cuesta el año de historial de versiones que de otro modo ya se tendría.

Dónde fallan los SBOM en la práctica

Generado a mano, una vez

El fallo más frecuente es una hoja de cálculo compilada para el expediente técnico, exportada a JSON y nunca vuelta a tocar. Es exacta el día en que se escribe y errónea en la primera subida de versión de una dependencia. El deber del CRA es mantener la lista actualizada, así que un SBOM desactualizado no es un cumplimiento parcial: es un incumplimiento documentado de una obligación continua.

No ligado a una versión

Un SBOM sin indicación inequívoca de qué producto, qué versión y qué compilación describe no prueba nada. Cuando una autoridad pregunte si las unidades entregadas en marzo de 2028 contenían una biblioteca vulnerable, necesitará la lista de aquella compilación, no la actual. Es el error estructural más común, y es un problema de modelado de datos, no de seguridad.

Construido del código, no del artefacto

Los archivos de manifiesto describen intenciones. El artefacto entregado contiene lo que produjo la compilación: la imagen base, la biblioteca enlazada estáticamente, el SDK del proveedor incorporado como binario. Los SBOM generados solo desde el código fuente subnotifican de forma sistemática, y los componentes que omiten son, desproporcionadamente, los que nadie parchea.

Faltan componentes de terceros e integrados

Si un proveedor le entrega un módulo, sus componentes están en su producto. Al CRA le da igual que no los haya escrito usted. Conseguir SBOM de los proveedores es un problema de compras con plazos largos: hay que modificar contratos y los proveedores pequeños a menudo no tienen capacidad alguna. Es lo que conviene empezar antes.

No hay dónde guardarlo

Un SBOM por versión, conservado diez años o el periodo de soporte, en todas las familias de producto, es un conjunto de datos versionado que debe sobrevivir a migraciones de herramientas, mudanzas de repositorio y la salida de quien lo montó. Un artefacto de compilación en un sistema de CI que se sustituirá en tres años no es una estrategia de conservación.

Integrar la generación de SBOM en el proceso de publicación — cinco pasos

Generar desde la compilación, de forma automática. Añada la generación del SBOM a la fase del pipeline que produce el artefacto entregable, de modo que no pueda existir un SBOM sin compilación ni una compilación sin SBOM. La generación manual siempre se desvía.
Ligar el SBOM a una identidad. Producto, versión, identificador de compilación, marca de tiempo. Eso convierte un archivo en una prueba, y es el paso que más se omite.
Fijar profundidad y formato, y dejarlo por escrito. Decida CycloneDX o SPDX, decida si resuelve de forma transitiva (debería) y documente la decisión para que seis ciclos de publicación después nadie la cambie en silencio.
Empujar el requisito cadena de suministro arriba. Modifique los acuerdos con proveedores para exigir un SBOM por versión entregada, en el formato elegido. Empiece por los proveedores de los componentes que no puede inspeccionar.
Guardarlo donde siga siendo legible dentro de una década. Versionado, indexado por producto y versión, recuperable sin el sistema de compilación original. La conservación es el requisito que sobrevive a cualquier herramienta que se use para satisfacerlo.

El programa de datos más amplio en el que esto encaja lo cubre nuestra checklist de implementación del DPP.

Qué significa esto para los datos de producto

Marquemos la frontera con claridad: el CRA no mete un SBOM en el pasaporte digital del producto. El reglamento no contiene obligación de pasaporte, y ninguna lectura convierte una lista de materiales en un campo público. Las obligaciones de pasaporte vienen del ESPR y de actos sectoriales que las imponen expresamente.

Lo que ambos regímenes comparten es la forma. Los dos exigen datos que sean:

ligados a una versión, no a una línea de producto. El SBOM cambia con cada publicación, igual que los datos del pasaporte cambian con cada revisión de especificación. Los sistemas que sobrescriben el registro actual no pueden responder a una pregunta sobre una unidad vendida hace tres años;
legibles por máquina por diseño. No un PDF que casualmente contiene una tabla, sino un documento estructurado que otro sistema pueda procesar sin una persona en medio;
conservados durante una década. Diez años de documentación técnica bajo el CRA son el mismo compromiso de infraestructura que la disponibilidad a largo plazo del pasaporte bajo el ESPR;
coherentes entre canales. La fecha de fin de soporte, el punto de contacto para vulnerabilidades y la información sobre actualizaciones tienen que decir lo mismo en su tienda, en un distribuidor y en la documentación.

Para la electrónica el argumento se acumula. El mismo producto cae a la vez bajo el ESPR, la directiva RoHS, la directiva RAEE y el CRA. Una empresa que guarda datos de sustancias en un sistema, datos de reparabilidad en otro y datos de componentes de software en un tercero mantiene cuatro registros sobre un mismo producto. El argumento de fondo para tratar los datos de producto como infraestructura está en DPP y PIM, y el encaje con el marcado está en marcado CE y pasaporte digital.

Una nota honesta sobre dónde acaba una plataforma de pasaportes: myDPP no genera SBOM, no escanea código ni contenedores, no valida una lista de materiales contra una compilación, no realiza análisis de vulnerabilidades y no evalúa la conformidad con el CRA. Eso pertenece a su cadena de herramientas de ingeniería y, donde se exija, a un organismo notificado. Lo que hace una plataforma de pasaportes es almacenar datos de producto versionados, mantenerlos recuperables durante años y publicar las partes que deben ser públicas. La responsabilidad del cumplimiento sigue siendo del fabricante.

Calendario

Fecha	Qué ocurre
10 de diciembre de 2024	entra en vigor el Reglamento (UE) 2024/2847
3 de abril de 2025	CEN, CENELEC y ETSI aceptan la petición de normalización
11 de junio de 2026	se aplican las disposiciones sobre organismos notificados
11 de septiembre de 2026	se aplican las obligaciones de notificación — también a productos ya en el mercado
11 de diciembre de 2027	aplicación plena — el requisito de SBOM del anexo I pasa a ser vinculante

El deber de notificación llega más de un año antes que el deber de SBOM, y ese orden es instructivo. Desde septiembre de 2026 puede tener que notificar una vulnerabilidad explotada activamente en 24 horas. Responder «cuáles de nuestros productos contienen este componente» dentro de esa ventana es exactamente el problema para el que existe un SBOM — lo que sitúa el plazo práctico bastante antes que el legal.

Preguntas frecuentes

¿Tengo que publicar mi SBOM?

No. El CRA obliga a elaborarlo, mantenerlo actualizado y ponerlo a disposición de las autoridades de vigilancia del mercado a petición. Pasa a formar parte de la documentación técnica. Publicarlo a los clientes es una decisión comercial — y cada vez más una exigencia contractual de grandes compradores, cosa distinta del deber legal.

¿Basta con una lista de dependencias de primer nivel?

Cumple la letra del anexo I parte II. No cumple la BSI TR-03183-2 alemana, que exige resolución recursiva del árbol de dependencias, y no responderá a la pregunta que realmente necesita responder cuando aparezca una vulnerabilidad cuatro niveles más abajo. El primer nivel es el suelo; el transitivo, el objetivo.

¿CycloneDX o SPDX?

Bajo el CRA, que no nombra formato, ambos son defendibles. CycloneDX tiene el ecosistema de seguridad más fuerte y transporta VEX; SPDX tiene más profundidad para el trabajo de licencias y procedencia. La BSI TR-03183-2 acepta CycloneDX 1.6+ o SPDX 3.0.1+. Lo decisivo debería ser cuál genera de forma fiable su cadena de herramientas.

¿Cuánto tiempo debo conservar los SBOM?

El SBOM forma parte de la documentación técnica, que debe mantenerse a disposición de las autoridades de vigilancia del mercado durante al menos diez años desde la introducción del producto en el mercado, o durante el periodo de soporte si este es mayor. Como cada publicación genera un SBOM nuevo, se trata de un archivo versionado y no de un único fichero.

¿Debe ir el SBOM en el pasaporte digital del producto?

Jurídicamente, no. El CRA no crea obligación de pasaporte y ningún acto de pasaporte vigente exige una lista de materiales como campo de datos. El solapamiento está en la infraestructura: ambos necesitan datos de producto a nivel de versión, legibles por máquina, conservados una década y accesibles mediante un identificador estable.

Sigue leyendo

Fuentes

Reglamento (UE) 2024/2847 — Cyber Resilience Act — EUR-Lex
The Cyber Resilience Act — resumen del texto legislativo — Comisión Europea
BSI TR-03183-2: Software Bill of Materials (SBOM) — Bundesamt für Sicherheit in der Informationstechnik
CycloneDX — ECMA-424 — OWASP
SPDX — ISO/IEC 5962:2021 — Linux Foundation
Minimum Elements for a Software Bill of Materials — CISA