Respuesta corta: sí. El Reglamento de Ciberresiliencia, Reglamento (UE) 2024/2847, exige a todo fabricante de un producto con elementos digitales en su ámbito que elabore una lista de materiales de software. Es uno de los ocho requisitos de gestión de vulnerabilidades del anexo I, parte II, que se aplican a todo producto en el ámbito sin «cuando proceda» y sin umbral de tamaño, desde el 11 de diciembre de 2027.

La respuesta larga son tres frases del Reglamento, y cada una zanja una pregunta que la gente no deja de hacer.

El requisito: anexo I, parte II, punto 1

Los fabricantes deben «identificar y documentar las vulnerabilidades y los componentes contenidos en los productos con elementos digitales, también 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 de los productos».

Cuatro cosas quedan fijadas por esa frase.

Es obligatoria. La SBOM es el medio nombrado para identificar y documentar componentes. No hay camino al punto 1 sin ella.

El formato es «de uso común y legible por máquina». El Reglamento no nombra CycloneDX ni SPDX, y no lo necesita: ambos son de uso común y legibles por máquina, y cualquiera de los dos satisface el texto. Una hoja de cálculo es legible por máquina en un sentido débil y no es de uso común para este fin; no confíe en ella.

La profundidad es «al menos las dependencias de primer nivel». Ese es el suelo, no la recomendación. Primer nivel significa los paquetes que su producto declara directamente. Las dependencias transitivas son donde realmente están la mayoría de las vulnerabilidades conocidas, así que una SBOM solo de primer nivel cumple la letra y deja débil la mitad del punto 1 sobre identificación de vulnerabilidades. La mayoría de las herramientas producen de todos modos el grafo completo.

Cubre «los productos», en plural, por producto. Una SBOM por producto con elementos digitales, por versión que afecte al cumplimiento (el anexo VII, punto 1, letra b), pide las versiones). Una única SBOM para toda la organización no lo satisface.

Dónde va: anexo VII, puntos 2, letra b), y 8

La SBOM forma parte de la documentación técnica. El anexo VII, punto 2, letra b), cita «la lista de materiales de software» entre las especificaciones de gestión de vulnerabilidades que debe contener el expediente. Es un documento que conserva, fechado, con el expediente, durante diez años o el período de soporte, lo que sea más largo.

El punto 8 del mismo anexo responde a la pregunta que todos hacen después: ¿tenemos que publicarla? No. La SBOM se facilita «previa solicitud motivada de una autoridad de vigilancia del mercado, siempre que sea necesaria para que dicha autoridad pueda comprobar el cumplimiento de los requisitos esenciales de ciberseguridad establecidos en el anexo I». Se revela a una autoridad, a petición, con un motivo. Nada en el Reglamento exige publicarla a clientes o al público, aunque nada lo prohíbe tampoco: el anexo II, punto 9, dice que si el fabricante decide poner la SBOM a disposición de los usuarios, la información al usuario debe indicar dónde puede accederse a ella. El cuestionario de seguridad de un cliente puede pedirla de todos modos.

Lo que no zanja

Los detalles de formato. La Comisión puede especificar el formato y los elementos de la SBOM mediante acto de ejecución (artículo 13, apartado 24). Hasta entonces, «de uso común y legible por máquina» es el criterio, y los dos formatos abiertos lo cumplen.

La profundidad más allá del primer nivel. El Reglamento fija un suelo. Que una autoridad, un organismo notificado o un cliente acepte solo el primer nivel es una cuestión práctica con respuesta previsible: cuanto más profunda la SBOM, menos preguntas.

Los componentes de hardware. El punto 1 dice «vulnerabilidades y componentes», y la SBOM es una lista de materiales de software. Para un producto de hardware el expediente sigue teniendo que identificar componentes (el anexo VII, punto 1, letra c), quiere la disposición interna), pero el requisito de legibilidad por máquina está formulado para software.

Qué hacer

Genere la SBOM a partir de la compilación, no a mano, en CycloneDX o SPDX, para cada producto y cada versión relevante para el cumplimiento, y guárdela con la documentación técnica. Mantenga la generación en el pipeline de publicación para que la SBOM del expediente sea la del producto entregado y no la del trimestre pasado. Redacte un procedimiento SBOM de una página que diga qué herramienta, qué formato, qué profundidad, dónde se guarda y quién responde a una solicitud motivada; ese procedimiento es uno de los cuatro documentos operativos que presupone la parte II, y es lo que un auditor pide ver antes que la propia SBOM.

Y no pierda de vista el lado de las vulnerabilidades: el punto 1 dice «identificar y documentar las vulnerabilidades y los componentes». La SBOM es la mitad de los componentes. La mitad de las vulnerabilidades es el escaneo que la lee, y en el momento en que ese escaneo muestra una vulnerabilidad explotada, el reloj de 24 horas del artículo 14 es lo siguiente en lo que pensar.

Lo que el Reglamento le pide después por cada componente de esa lista, diligencia debida según el artículo 13(5), notificación aguas arriba según el artículo 13(6) y la prueba de las «vulnerabilidades explotables conocidas» al publicar, está en el artículo complementario, según las orientaciones de la Comisión.

Fuentes

  • Reglamento (UE) 2024/2847, anexo I, parte II, punto 1 (citado); anexo II, punto 9; anexo VII, puntos 1, letra b), 1, letra c), 2, letra b), y 8; artículo 13, apartado 24, sobre el acto de ejecución para el formato de la SBOM; artículo 71, apartado 2, para las fechas. Leído en el texto del Diario Oficial en EUR-Lex el 11 de septiembre de 2026.

Esto no es asesoramiento jurídico. Las tres frases de arriba son lo bastante cortas para leerlas en el propio Reglamento, que es donde debe apoyarse una decisión sobre su producto.