Generador de SBOM: nomenclatura de materiales del software en CycloneDX para el Reglamento de Ciberresiliencia

El Reglamento de Ciberresiliencia exige a todo fabricante de un producto con elementos digitales elaborar una nomenclatura de materiales de los programas informáticos (SBOM) en un formato comúnmente utilizado y legible por máquina, que incluya como mínimo las dependencias de máximo nivel. Abra aquí sus archivos de bloqueo y descargue un archivo CycloneDX 1.6. Los archivos se leen en su navegador.

Comprobado con las fuentes el 17 de octubre de 2026

Archivos de dependencias

Tipo de archivo

Abrir archivos

lockfileVersion 2 o 3 (npm 7 o posterior). Se excluyen los paquetes solo de desarrollo.

Elija el tipo y abra uno o varios archivos de ese tipo. Abra los archivos de cada parte del producto (por ejemplo, la interfaz web y el backend) para reunirlos en una sola SBOM. Los archivos se leen en su navegador y no se suben.

Todavía no hay ningún archivo.

Vulnerabilidades conocidas

Compruebe los componentes en OSV.dev, la base de datos abierta de vulnerabilidades de Google, y las vulnerabilidades encontradas en el catálogo de vulnerabilidades explotadas conocidas de la CISA (KEV). Solo si hace clic: se envían a OSV.dev los nombres y versiones de los paquetes (los nombres NuGet también a nuget.org, para su grafía exacta) y después los identificadores de las vulnerabilidades encontradas; el catálogo KEV se descarga de la página de la CISA en GitHub. No se envía nada más.

Nada de lo que abre o escribe se guarda ni se nos envía.

Kit documental CRA: la documentación técnica, la evaluación de los riesgos de ciberseguridad, la información para el usuario y la declaración UE de conformidad en 9 idiomas, en archivos Word (de pago).

Qué exige el Reglamento

Anexo I, parte II, punto 1, del Reglamento (UE) 2024/2847: los fabricantes «identificarán y documentarán las vulnerabilidades y los componentes presentes en el producto con elementos digitales, también mediante la elaboración de una nomenclatura de materiales de los programas informáticos en un formato comúnmente utilizado y legible por máquina, que incluya, como mínimo, las dependencias de máximo nivel del producto». Se aplica desde el 11 de diciembre de 2027 (artículo 71).

La SBOM forma parte de la documentación técnica, junto con los procesos de gestión de vulnerabilidades (anexo VII, punto 2, letra b)).
Se entrega a una autoridad de vigilancia del mercado previa solicitud motivada (anexo VII, punto 8). No está obligado a hacerla pública (considerando 77).
Si decide ponerla a disposición de los usuarios, la información para el usuario indica dónde (anexo II, punto 9).
La Comisión puede especificar su formato y sus elementos mediante un acto de ejecución (artículo 13, apartado 24). CycloneDX y SPDX son formatos de uso común.

Qué genera esta página

Un archivo JSON CycloneDX 1.6 con su producto como componente principal, cada paquete con su versión exacta y su URL de paquete (purl), y las dependencias de máximo nivel del producto cuando el archivo de bloqueo las indica. Lee:

npm package-lock.json (lockfileVersion 2 o 3), Yarn yarn.lock (Yarn 1, 2 y posteriores) y pnpm-lock.yaml (lockfileVersion 9.0); se excluyen los paquetes solo de desarrollo cuando el archivo los indica;
Python requirements.txt con cada paquete fijado (name==version), tal como lo escriben pip freeze o pip-compile;
Rust Cargo.lock, versión 3 o 4, y Go go.mod, con los módulos indirectos;
el árbol de dependencias de Maven que escribe mvn dependency:tree -DoutputFile, y Gradle gradle.lockfile; se excluyen los paquetes con ámbito test;
PHP Composer composer.lock, sin packages-dev, y NuGet packages.lock.json.

Un archivo que no sigue su formato no se lee: la página indica la línea y el motivo en lugar de adivinar. Un paquete de una fuente distinta del registro público se enumera sin URL de paquete, para que el archivo nunca apunte a un paquete que usted no ha utilizado.

¿Ya tiene un SBOM generado con otra herramienta? Ábralo como archivo JSON CycloneDX, o como archivo JSON SPDX como el que exporta el gráfico de dependencias de GitHub (Export SBOM), para comprobar sus componentes en OSV.dev y en el catálogo KEV. Solo se lee para la comprobación: para generar un SBOM nuevo, abra los archivos de bloqueo. Cuando ningún archivo de bloqueo fija la versión, el archivo de GitHub da un rango como ^4.17.0: esos componentes se listan como no comprobados; abra el archivo de bloqueo para comprobarlos.

Vulnerabilidades explotadas conocidas

La comprobación marca cada vulnerabilidad encontrada en OSV.dev cuyo número CVE figura en el catálogo de vulnerabilidades explotadas conocidas (KEV) de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA), con la fecha en que la CISA la incluyó. La CISA incluye una vulnerabilidad cuando hay pruebas fiables de que se ha explotado. Desde el 11 de septiembre de 2026, el artículo 14 del Reglamento de Ciberresiliencia le exige notificar una vulnerabilidad activamente explotada presente en su producto (artículo 3, punto 42) en un plazo de 24 horas desde que tenga conocimiento de ella. Una entrada en el KEV no lo decide para su producto, pero indica dónde mirar primero; la página de plazos de notificación cuenta las horas.

Qué no cubre

La SBOM enumera lo que enumeran los archivos de bloqueo. El código copiado en el producto, los paquetes del sistema operativo, el firmware y las bibliotecas en otros lenguajes no figuran en ellos: añádalos usted. La comprobación de vulnerabilidades usa OSV.dev, que solo registra vulnerabilidades publicadas; no sustituye la evaluación de vulnerabilidades que exige el anexo I, parte II.

Para el resto de la documentación del CRA, el kit documental CRA redacta la documentación técnica y la declaración UE de conformidad. La página sobre el Reglamento de Ciberresiliencia indica la clase de su producto.