Análisis de vulnerabilidades y SBOM
El CRA convierte su lista de materiales de software en una obligación viva: conozca lo que contiene su producto, vigile esos componentes ante nuevas vulnerabilidades, y corríjalas y notifíquelas dentro de los plazos del artículo 14. Esta página recorre todo el ciclo y la herramienta gratuita que lo ejecuta.
Genere un SBOM
Elabore un inventario de software (SBOM) legible por máquina que abarque al menos sus dependencias de nivel superior. Se trata de un requisito obligatorio, no de una buena práctica.
Cómo generarlo ↓Monitorizar las vulnerabilidades
Coteje de forma continua cada componente con datos de vulnerabilidades en tiempo real (NVD, EUVD). Los resúmenes de notificaciones por lotes no cumplen el plazo de 24 horas.
Por qué los resúmenes periódicos resultan insuficientes ↓Evalúe, corrija y notifique
Documente la explotabilidad, distribuya una corrección y notifique las vulnerabilidades explotadas activamente a ENISA y al CSIRT en el calendario de 24 h / 72 h / 14 días.
La herramienta que hace esto ↓Analizador de Vulnerabilidades del CRA
Suba su SBOM y su lista de vulnerabilidades activas. El Analyzer contrasta cada componente con la National Vulnerability Database (NVD) y la EU Vulnerability Database (EUVD), señala los componentes en fin de vida (End-of-Life) y genera un informe de conformidad que puede adjuntar a su documentación técnica.
Guías prácticas
Genere un SBOM conforme
Una lista de materiales de software (SBOM) es un requisito legal estricto en virtud del Anexo I, Parte II, Punto (1). Esta guía abarca el alcance y el formato obligatorios, cómo generar una y cómo alimenta el ciclo de seguimiento.
1 · Base jurídica
El anexo I, parte II («Requisitos de tratamiento de vulnerabilidades»), punto (1) exige a los fabricantes «identificar y documentar las vulnerabilidades y los componentes … en particular, elaborando una lista de materiales de software en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de nivel superior del producto.»
A diferencia de algunas disposiciones del CRA que permiten cierta flexibilidad interpretativa, la obligación de elaborar un SBOM legible por máquina que cubra al menos las dependencias de primer nivel no admite enfoques alternativos.
2 · Ámbito y formato obligatorios
Cobertura de componentes. El SBOM debe documentar todas las dependencias de nivel superior, lo que constituye el mínimo legal y no el objetivo recomendado. Asigne las dependencias transitivas (indirectas) siempre que sea posible; un SBOM superficial cumple la letra de la ley, pero a menudo resulta insuficiente para una gestión eficaz de las vulnerabilidades.
Formato. El CRA exige un «formato de uso común y legible por máquina». Entre los formatos aceptados se incluyen:
- SPDX (ISO/IEC 5962:2021): ampliamente adoptado, centrado en las licencias y adecuado para la documentación de conformidad.
- CycloneDX: centrado en la seguridad, idóneo para los flujos de trabajo de gestión de vulnerabilidades.
- Otros formatos estructurados (JSON, XML) procedentes de herramientas reconocidas son por lo general aceptables conforme al requisito de referencia.
No almacene los SBOM como PDF. Las autoridades de vigilancia del mercado pueden impugnar el PDF por no ser legible por máquina. Conserve la salida nativa JSON, XML o tag-value de su cadena de herramientas.
Campos de metadatos obligatorios
| Campo | Descripción |
|---|---|
| Nombre del componente | Identificador único de la biblioteca, el paquete o el módulo |
| Versión | Cadena de versión exacta; los intervalos de versiones no son suficientes |
| Proveedor / origen | Nombre del editor, proveedor o proyecto de código abierto |
| Relaciones entre dependencias | Directas frente a transitivas; gráfico de dependencias cuando sea viable |
| Hash criptográfico | Comprobación de integridad SHA-256 o más robusta por componente |
| Identificador de licencia | Expresión de licencia SPDX (p. ej., Apache-2.0, MIT) |
3 · Generar su SBOM
La mayoría de las plataformas modernas pueden generar SBOM automáticamente en tiempo de compilación sin coste adicional:
- GitHub / Actions: Dependency Graph → Export SBOM (Settings → Code security). Genera SPDX JSON.
- GitLab: Los informes CycloneDX se generan de forma nativa mediante el trabajo de CI/CD de análisis de dependencias.
- Syft (Anchore): herramienta CLI de código abierto que genera SPDX y CycloneDX para imágenes de contenedores, sistemas de archivos y manifiestos de paquetes.
- cdxgen: SBOM en CycloneDX para npm, Maven, pip, Go, Rust y otros.
Cribado de vulnerabilidades. Antes de finalizar cualquier SBOM, coteje cada componente con las bases de datos de vulnerabilidades conocidas. Tanto el escáner de GitHub como Syft se integran con Grype para ello. Incluir un componente con una vulnerabilidad conocida y ya corregida constituye una infracción directa del Anexo I y no admite flexibilidad interpretativa.
Si existe una versión parcheada de un componente, debe utilizarla. No existe ninguna categoría de «riesgo aceptado» en el CRA para las vulnerabilidades resueltas. Actúe ante cada hallazgo antes de introducir el producto en el mercado.
4 · Mantenimiento del ciclo de vida y conservación
Un SBOM es un artefacto vivo, que se actualiza de forma continua a lo largo del ciclo de vida con soporte del producto para reflejar los componentes parcheados, las nuevas dependencias, los componentes en fin de vida eliminados y los cambios en la cadena de suministro. Todas las versiones de la documentación técnica, incluidos los SBOM, deben conservarse durante al menos 10 años desde la primera introducción en el mercado…
Secciones 4–9: ciclo de vida, sanciones, BSI TR-03183-2 y la lista de verificación de preparación
El resto de la guía aborda la obligación de conservación durante 10 años, la confidencialidad y la divulgación en la cadena de suministro, la integración con la notificación de vulnerabilidades del Artículo 14, la frecuencia de la supervisión, las normas más estrictas del BSI en Alemania, las multas (de hasta 15 millones de euros o el 2,5 % del volumen de negocios) y una lista de verificación de preparación lista para usar.
Herramientas y análisis relacionados
Matriz de conformidad
Cada obligación del ciclo de vida con su referencia al artículo; siga su progreso y descargue la lista de comprobación completa.
Situación actual
Situación actual del CRA: actos de ejecución, normas armonizadas y el camino hacia diciembre de 2027.
Calculadora de costes
Una estimación indicativa de lo que probablemente costará alcanzar y mantener la conformidad.