Todo fabricante sujeto al CRA necesita un proceso vivo de gestión de vulnerabilidades para cada producto: saber qué contiene, encontrar y corregir vulnerabilidades, probar con regularidad, publicar avisos, recibir informes externos y entregar actualizaciones de seguridad de forma segura y gratuita. Esta página explica ese modelo operativo y dónde pasa a la notificación regulatoria urgente.
Resumen
- La gestión de vulnerabilidades es un modelo operativo de ingeniería que todo fabricante CRA necesita para cada producto con elementos digitales.
- Ocho deberes numerados: identificar (con SBOM), remediar sin demora, probar periódicamente, divulgar públicamente las vulnerabilidades corregidas, operar una política CVD, facilitar la notificación de vulnerabilidades, distribuir actualizaciones de forma segura, suministrar actualizaciones de seguridad gratuitas.
- La gratuidad no es negociable: las actualizaciones de seguridad son gratuitas por defecto, con una excepción estrecha para productos a medida suministrados a usuarios profesionales.
- La política CVD es obligatoria, no opcional: la divulgación coordinada de vulnerabilidades forma parte de la preparación para el marcado CE, no de una buena práctica voluntaria.
- La gestión de vulnerabilidades se aplica durante todo el período de soporte; el mínimo es de cinco años desde la introducción en el mercado salvo que el período previsto de uso del producto sea menor y se haya comunicado.
- La gestión de vulnerabilidades no es notificación regulatoria urgente: la gestión es el proceso de ingeniería del día a día; la notificación solo empieza por explotación activa o incidentes graves.
Los cuatro anclajes de la gestión de vulnerabilidades del CRA: alcance, duración, coste de actualización y frontera con la notificación urgente.
Los ocho deberes de gestión de vulnerabilidades
El CRA no trata la gestión de vulnerabilidades como una lista de comprobación puntual. Espera un ciclo continuo durante todo el período de soporte, desde el inventario de componentes hasta la remediación, la divulgación y la entrega segura de actualizaciones. La tabla agrupa los ocho deberes por la fase operativa en la que normalmente se ejecutan.
| Fase | Puntos | Qué cubre | Foco operativo |
|---|---|---|---|
| Detectar y catalogarEntrada e inventario | Puntos 1 y 6 | Identificación basada en SBOM de componentes y vulnerabilidades conocidas, junto con un canal público de notificación. | Mantener actualizados los datos de componentes y facilitar que terceros lleguen al equipo de seguridad del producto. |
| Diseñar y corregirRemediación y pruebas | Puntos 2 y 3 | Remediación sin demora y pruebas periódicas eficaces del código y de sus dependencias. | Usar la gravedad para fijar urgencia y conservar evidencia de que las correcciones y pruebas ocurrieron a tiempo. |
| DistribuirCanal de actualización seguro | Puntos 7 y 8 | Actualizaciones de seguridad firmadas y autenticadas, separables de funcionalidades y gratuitas salvo para productos B2B a medida. | Entregar correcciones de seguridad sin forzar a los usuarios a aceptar funcionalidades nuevas o planes de mantenimiento de pago. |
| Coordinar y divulgarCVD y avisos | Puntos 4 y 5 | Una política CVD aplicada y avisos públicos una vez disponible la corrección. | Coordinar entrada de investigadores, aviso a usuarios y demoras justificadas desde un mismo playbook. |
Qué significa cada deber en la práctica
| # | Deber | Qué exige realmente |
|---|---|---|
| 1 | Identificar y documentar vulnerabilidades y componentes | Un SBOM en CycloneDX o SPDX que cubra al menos las dependencias de primer nivel. El SBOM es el índice que hace posible la correlación con CVE: no se puede remediar lo que no se ha catalogado. |
| 2 | Remediar sin demora, separadamente de las funcionalidades | Sin SLA fijo; la velocidad esperada se escala con la gravedad. Las ramas de seguridad deben ser separables de las ramas de funcionalidades para que los usuarios no puedan posponer un parche posponiendo una versión. |
| 3 | Pruebas eficaces y periódicas | Análisis estático, pruebas dinámicas, escaneo de dependencias contra fuentes de vulnerabilidades y pruebas de penetración. "Periódicas" debe ajustarse al riesgo y al ritmo de cambio del código. |
| 4 | Divulgación pública de las vulnerabilidades corregidas | Una vez disponible la corrección, publicar la descripción, el producto afectado, el impacto, la gravedad y la remediación. Solo se puede demorar "en casos debidamente justificados" hasta que los usuarios puedan aplicar el parche. CVE más CSAF es el soporte de facto. |
| 5 | Política de divulgación coordinada de vulnerabilidades | Una política CVD escrita y aplicada, con canal de recepción, SLA de respuesta y condiciones de divulgación. ISO/IEC 29147 y 30111 ofrecen un marco formal. |
| 6 | Facilitar la notificación externa de vulnerabilidades | Una dirección de contacto para notificar problemas en el producto y en sus componentes de terceros. security.txt conforme a RFC 9116 satisface el requisito de canal. |
| 7 | Distribución segura de actualizaciones | Actualizaciones firmadas y autenticadas, automáticas cuando proceda. Los productos sin canal de actualización deben construir uno o documentar por qué la automatización no es aplicable. Véase actualizaciones de seguridad. |
| 8 | Gratuitas, con mensajes de aviso | Las actualizaciones de seguridad deben distribuirse sin demora y de forma gratuita (única excepción: productos a medida para usuarios profesionales cuando las partes hayan acordado otra cosa). Cada actualización debe llevar un mensaje de aviso que describa el problema y la acción que el usuario debe realizar. Una barrera de mantenimiento de pago, o un parche silencioso sin aviso, incumple el punto 8. |
La gestión de vulnerabilidades y el período de soporte
La gestión de vulnerabilidades se aplica durante todo el período de soporte. El mínimo por defecto es de cinco años desde la fecha de introducción del producto en el mercado de la UE, salvo que el período de uso previsto sea menor y se haya comunicado. La fecha de fin del período de soporte debe figurar en la información del producto. Una vez finalizado ese período, los deberes activos de gestión decaen para esa versión del producto, pero la documentación técnica y la declaración de conformidad deben conservarse durante 10 años desde la introducción en el mercado o durante el período de soporte, el plazo que sea mayor. Véase período de soporte del CRA.
La gestión de vulnerabilidades no es notificación urgente
El CRA distingue dos obligaciones que operan sobre superficies y destinatarios distintos:
- La gestión de vulnerabilidades es el proceso de ingeniería: SBOM, remediación, política CVD, divulgación pública y actualizaciones seguras. Se aplica a todas las vulnerabilidades durante todo el período de soporte y reside en la organización de seguridad del producto del fabricante.
- La notificación regulatoria urgente solo empieza cuando hay una vulnerabilidad activamente explotada o un incidente grave que afecte a la seguridad del producto. Se presenta a través de la ENISA Single Reporting Platform con una cadencia de 24h / 72h, más un informe final (14 días después de que esté disponible una medida correctora o de mitigación para una vulnerabilidad activamente explotada, o un mes después de la notificación de 72h en caso de incidente grave), hacia ENISA y el CSIRT designado como coordinador. Para la mecánica de incorporación al SRP, véase incorporación al SRP de ENISA.
Un equipo de producto puede ejecutar un proceso conforme de gestión de vulnerabilidades sin presentar nunca una notificación urgente, porque la mayoría de las vulnerabilidades se remedian antes de ser explotadas activamente. La notificación solo empieza cuando la remediación todavía no ha alcanzado a la explotación activa o a un incidente grave. Véase notificación de vulnerabilidades del CRA.
Exposición sancionadora
Los fallos en la gestión de vulnerabilidades pueden generar sanciones administrativas serias, pero el detalle de tramos corresponde a la guía dedicada de aplicación. Consulta sanciones y aplicación del CRA para los niveles de multa, los activadores de enforcement y cómo encajan los fallos de gestión de vulnerabilidades en el modelo general.
Preguntas frecuentes
¿El SBOM debe cubrir las dependencias transitivas?
El suelo legal son las dependencias de primer nivel, pero un SBOM práctico suele tener que ir más profundo. No puedes remediar sin demora un CVE en un componente transitivo que nunca has catalogado. La mayoría de los reguladores y clientes esperan un SBOM profundo conforme a BSI TR-03183 o guía equivalente. Tanto CycloneDX como SPDX se consideran formatos ampliamente utilizados y legibles por máquina. Véase requisitos de SBOM del CRA.
¿Qué significa "sin demora" en la práctica para la remediación conforme al punto 2?
El CRA no fija un SLA de remediación específico. "Sin demora" se escala con el riesgo de ciberseguridad: una vulnerabilidad crítica con explotación activa en circulación exige una corrección en días, mientras que un problema de gravedad baja puede esperar al siguiente ciclo regular. La gravedad se establece con CVSS, se afina con datos de probabilidad de explotación de EPSS y se confirma con la evidencia del catálogo CISA KEV cuando la vulnerabilidad figura en la lista de CISA de vulnerabilidades activamente explotadas. Véase puntuación de gravedad para la escala operativa que las autoridades de mercado aplican al juzgar si un fabricante remedió "sin demora".
¿Pueden cobrarse las actualizaciones de seguridad en algún caso?
Solo existe una excepción: los productos a medida suministrados a un usuario profesional pueden usar un acuerdo de pago cuando el fabricante y el usuario profesional hayan acordado otra cosa. Para cualquier otro producto, incluidos todos los productos de consumo y todo el SaaS o el hardware B2B estándar, las actualizaciones de seguridad deben ser gratuitas durante todo el período de soporte. Condicionar un parche de seguridad a un nivel de mantenimiento de pago expone al fabricante a las multas del tramo superior.
¿Continúan los deberes de gestión de vulnerabilidades tras finalizar el período de soporte?
No. Los ocho deberes de gestión de vulnerabilidades decaen para esa versión del producto cuando el período de soporte termina. Las nuevas vulnerabilidades encontradas tras el fin de soporte no tienen que remediarse para esa versión, siempre que el fabricante haya publicado una fecha clara de fin de soporte para que los usuarios puedan migrar. Dos deberes continúan en todo caso. La documentación técnica y la declaración UE de conformidad deben conservarse durante 10 años desde la introducción en el mercado o durante el período de soporte, el plazo que sea mayor. La notificación es distinta de la gestión: si el fabricante tiene conocimiento de una vulnerabilidad explotada activamente o de un incidente grave en el producto, el deber de notificación del artículo 14 puede seguir aplicándose, porque no está vinculado al período de soporte. Véase período de soporte y divulgación del fin de soporte.
¿Cuándo una entrada de CVD requiere notificación urgente?
El activador es la explotación activa, no una notificación privada ni una prueba de explotabilidad. Una prueba de concepto funcional adjunta a un informe de CVD no es por sí sola notificable; pasa a serlo cuando existe una creencia razonable de que un actor malicioso ha utilizado el fallo contra un objetivo real. Una vez superado ese umbral, arranca el aviso temprano de 24 horas a ENISA y al CSIRT coordinador, seguido de la notificación de 72 horas y un informe final en los 14 días posteriores a que una medida correctora esté disponible. Véase notificación de vulnerabilidades del CRA.