Ley de Ciberresiliencia (CRA) y SBOM: respuestas breves
Las preguntas más frecuentes de los fabricantes sobre el CRA, cada una respondida en pocas frases y con su fuente oficial.
¿Qué es la Ley de Ciberresiliencia (Cyber Resilience Act) y a quién se aplica?
La Ley de Ciberresiliencia (Cyber Resilience Act, CRA) es el Reglamento (UE) 2024/2847, la norma de la UE sobre requisitos de ciberseguridad para productos con elementos digitales. Se aplica al hardware con software y a los productos de software comercializados en la UE, y sus obligaciones recaen sobre todo en los fabricantes, sea cual sea su tamaño. Los sectores con normas propias, como los productos sanitarios, los vehículos de motor y la aviación civil, quedan excluidos, y el software como servicio puro, sin producto, queda en general fuera. El reglamento entró en vigor el 10 de diciembre de 2024.
Obligaciones de notificación del CRA en detalle →
Fuente: Reglamento (UE) 2024/2847, EUR-Lex, Ley de Ciberresiliencia, Comisión Europea
¿En qué consiste la obligación de notificación del CRA?
Desde el 11 de septiembre de 2026, los fabricantes deben notificar toda vulnerabilidad aprovechada activamente en su producto y todo incidente grave que afecte a su seguridad, también en productos que ya están en el mercado. La alerta temprana debe enviarse en las 24 horas siguientes a tener conocimiento, la notificación en 72 horas y el informe final a más tardar 14 días después de que exista una corrección (vulnerabilidades) o en el plazo de un mes desde la notificación (incidentes). Las notificaciones se presentan a través de la plataforma única de notificación de ENISA al CSIRT coordinador y a ENISA; la plataforma no ofrece una API a los fabricantes, por lo que cada notificación se presenta a mano en el navegador.
Notificación CRA: desencadenantes, plazos, destinatarios → Ver vídeo: El flujo de notificación del CRA (4 min)
Fuente: Reglamento (UE) 2024/2847, artículo 14, EUR-Lex, ENISA
¿Cómo se crea una SBOM?
Genérela automáticamente en su pipeline de compilación en lugar de escribirla a mano. Utilice uno de los dos formatos legibles por máquina más extendidos, CycloneDX o SPDX, y cree una SBOM por cada versión publicada. Hay generadores para la mayoría de los entornos, por ejemplo Syft o cdxgen para contenedores y sistemas de archivos, los plugins de CycloneDX para Maven, Gradle y npm, y la salida SPDX del Yocto Project para Linux embebido.
- Elija el formato. CycloneDX o SPDX: ambos son legibles por máquina.
- Genérela en CI. Ejecute el generador de SBOM de su entorno en cada compilación de versión.
- Guarde una SBOM por versión. Archívela con la versión como parte de la documentación técnica.
- Contrástela con datos de vulnerabilidades. Kernwatch comprueba los componentes con identificador de paquete (purl) a diario en los planes de pago y semanalmente en el plan Free.
SBOM para el CRA → Ver vídeo: Productos, versiones y SBOM (4 min) Ver vídeo: Cargar SBOM desde CI con una clave de API (2 min)
Fuente: CycloneDX, SPDX
¿Desde cuándo es obligatoria la SBOM según el CRA?
La SBOM forma parte de los requisitos del CRA que se aplican desde el 11 de diciembre de 2027: a partir de entonces, los productos con elementos digitales necesitan la conformidad con el CRA y el marcado CE para comercializarse en la UE. El anexo I exige una SBOM en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de nivel superior. Forma parte de la documentación técnica: no es obligatorio publicarla, pero las autoridades de vigilancia del mercado pueden solicitarla. Como la obligación de notificación rige desde el 11 de septiembre de 2026, una SBOM actualizada es también la forma más rápida de saber si una vulnerabilidad aprovechada afecta a sus productos.
Qué exige el CRA de una SBOM →
Fuente: Reglamento (UE) 2024/2847, anexo I, EUR-Lex
¿Qué hace una herramienta de notificación de vulnerabilidades del CRA?
Convierte los resultados de la vigilancia y los plazos en tareas. En Kernwatch, un hallazgo incluido en una lista de vulnerabilidades aprovechadas activamente se convierte en una tarea de la bandeja de tareas para abrir un caso de notificación, con vencimiento 24 horas después de tener conocimiento, y la alerta temprana, la notificación y el informe final se redactan a partir de sus datos de producto, versión y evaluación para su aprobación. Usted presenta la notificación en la plataforma de ENISA y registra la referencia; cuando una versión más reciente ya no contiene la versión vulnerable, Kernwatch propone la fecha de la corrección que inicia el plazo de 14 días del informe final. Las tareas aparecen en todos los planes; aprobar casos de notificación y notificaciones requiere Starter o superior.
Planes y precios → Ver vídeo: La bandeja de tareas (6 min)