Registros de gestión de vulnerabilidades de la CRA

Sytance · Actualizado

Los registros de gestión de vulnerabilidades muestran cómo el fabricante detecta, documenta, evalúa, corrige, divulga y comunica vulnerabilidades durante el período de soporte.

Obligación relativa al proceso

Al introducir un producto con elementos digitales en el mercado y durante el período de soporte, los fabricantes garantizarán que las vulnerabilidades de dicho producto, incluidos sus componentes, se gestionen de forma eficaz y de conformidad con los requisitos esenciales de ciberseguridad establecidos en la parte II del anexo I.

Reglamento (UE) 2024/2847, artículo 13(8)

La obligación comienza cuando el producto se introduce en el mercado y continúa durante el período de soporte. Abarca el producto y sus componentes.

Tipos principales de registros

Ejemplo: desde una alerta de componente hasta el cierre

Considere una vulnerabilidad ficticia en un analizador sintáctico de una versión de firmware de un controlador. Los seis registros siguientes forman un historial de caso de ejemplo. Muestran cómo un equipo puede conectar la recepción del aviso, el impacto en el producto y la corrección; esta secuencia no es un formulario establecido por la CRA.

  1. Recepción: registre cuándo llegó el informe, su fuente, el componente y el identificador de la vulnerabilidad, así como la información disponible en ese momento. Conserve el informe original.
  2. Impacto en el producto: utilice la SBOM y los registros de compilación para identificar las versiones candidatas. Confirme si un atacante puede alcanzar el analizador afectado en cada configuración con soporte; registre las pruebas y la incertidumbre que persista.
  3. Decisión de notificación: evalúe inmediatamente el artículo 14 si hay pruebas de explotación activa o de un incidente grave de seguridad del producto. Registre cuándo se tuvo conocimiento y presente las notificaciones obligatorias dentro de los plazos aplicables mientras continúa la investigación técnica.
  4. Tratamiento: evalúe el riesgo para el producto, asigne la corrección o la medida de mitigación y coordine con la persona responsable del componente cuando corresponda. Conserve la medida elegida y su justificación.
  5. Verificación y publicación: pruebe el analizador corregido y las funciones afectadas del producto, conserve la compilación sometida a prueba y vincule la actualización de seguridad, las pruebas de distribución y las instrucciones para los usuarios.
  6. Cierre y seguimiento: registre el resultado verificado, el inventario de componentes actualizado, la comunicación a los usuarios y la divulgación. Mantenga abiertas las acciones pendientes para cualquier versión con soporte afectada que aún no tenga una solución eficaz.

El registro del caso debería distinguir entre la finalización de la corrección interna, la presentación de las notificaciones obligatorias y la entrega o instalación de la actualización. Por ejemplo, una corrección puede publicarse mientras algunos usuarios afectados aún deben instalarla, lo que requiere seguimiento.

Relación con el anexo VII

El anexo VII exige que la documentación técnica incluya la información y las especificaciones necesarias para los procesos de gestión de vulnerabilidades, como la SBOM, la política de divulgación coordinada de vulnerabilidades, el contacto para notificaciones y la distribución segura de actualizaciones.

  • registros que respalden el historial de vulnerabilidades del producto;
  • registros que expliquen cómo se clasifican y corrigen las vulnerabilidades;
  • registros que muestren la distribución de actualizaciones y la comunicación a los usuarios;
  • informes de pruebas y revisiones que respalden la evaluación de la conformidad.

El proyecto prEN 40000-1-3 explica con más detalle el proyecto actual de norma sobre gestión de vulnerabilidades.

Los registros no activan por sí mismos la obligación de notificar

Estos registros respaldan la gestión de vulnerabilidades. La notificación del artículo 14 es una obligación independiente que se activa ante vulnerabilidades explotadas activamente e incidentes graves de seguridad del producto.

Fuentes