La letra 5) del Anexo I Parte II de la Ley de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847) exige a todos los fabricantes establecer y aplicar una política de divulgación coordinada de vulnerabilidades (CVD), y el Artículo 13(17) exige un único punto de contacto accesible para las personas que deseen notificar vulnerabilidades. No existe ninguna exención por tamaño. Esta página cubre qué debe contener la política, cómo publicar el canal de contacto y la relación entre la CVD, la notificación conforme al Artículo 14 y el marco más amplio del Anexo I Parte II.
Resumen
- La política de CVD es obligatoria conforme a la letra 5) del Anexo I Parte II: por escrito, publicada, aplicada, sin umbral por tamaño.
- El Artículo 13(17) exige un único punto de contacto para que los usuarios notifiquen vulnerabilidades; el canal no puede limitarse a herramientas automatizadas.
security.txt(RFC 9116) es la convención de facto para publicar el contacto, aunque el CRA no impone un formato específico.- La CVD no es la notificación del Artículo 14: la CVD regula la relación con los investigadores; el Artículo 14 es el reloj regulatorio hacia ENISA y el CSIRT coordinador cuando una vulnerabilidad está siendo activamente explotada.
- La divulgación pública de vulnerabilidades corregidas es obligatoria conforme a la letra 4) del Anexo I Parte II, con un margen de demora estrictamente delimitado para los casos en que el riesgo de seguridad de la publicación supera el beneficio hasta que los usuarios hayan tenido la posibilidad de aplicar el parche.
- Se aplican las multas del nivel superior: hasta €15.000.000 o el 2,5 % de la facturación anual mundial total conforme al Artículo 64(2), el importe que sea mayor.
Los cuatro pilares que definen una postura de CVD conforme al CRA: el mandato de política, el deber de contacto, la convención de publicación y el techo de sanciones.
Qué exige realmente el CRA en materia de CVD
La letra 5) del Anexo I Parte II es breve. Transcripción literal del Reglamento (UE) 2024/2847:
(5) establecer y aplicar una política de divulgación coordinada de vulnerabilidades;
Esa única frase contiene cuatro componentes operativos, cada uno de los cuales falla de forma distinta en la práctica:
Significa que existe una política escrita y accesible. Una práctica interna no documentada de gestionar correos en security@ no constituye una política.
Significa que la política se opera, no solo que existe por escrito. Los plazos de acuse de recibo, los compromisos de triaje y las condiciones de divulgación recogidos en el documento deben respetarse en la práctica. Una política que promete un acuse de recibo en 72 horas pero que habitualmente tarda tres semanas no se está aplicando.
Es la dirección que la política debe servir. La letra 6) del Anexo I Parte II lo recoge de forma explícita: los fabricantes deben "facilitar el intercambio de información sobre posibles vulnerabilidades", "incluyendo la provisión de una dirección de contacto".
No figura en el texto del CRA. El Considerando 76 encuadra la CVD como un proceso de notificación estructurado y señala que los programas de recompensas pueden incentivar los informes. La práctica del sector (ISO/IEC 29147, guía de buenas prácticas de ENISA) trata el puerto seguro para la investigación de buena fe como una norma de política CVD; el CRA en sí no lo codifica.
Para el marco completo del Anexo I Parte II (las ocho obligaciones numeradas de las que la CVD es una), consulta la gestión de vulnerabilidades del CRA.
El único punto de contacto (Artículo 13(17))
El Artículo 13(17) acompaña a la letra 5) del Anexo I Parte II y le da forma operativa. Transcripción literal:
- A los efectos del presente Reglamento, los fabricantes designarán un único punto de contacto para que los usuarios puedan comunicarse con ellos de forma directa y rápida, incluso con el fin de facilitar la notificación de vulnerabilidades del producto con elementos digitales.
Los fabricantes se asegurarán de que el único punto de contacto sea fácilmente identificable por los usuarios. También incluirán el único punto de contacto en la información e instrucciones dirigidas al usuario que figuran en el Anexo II.
El único punto de contacto permitirá a los usuarios elegir su medio de comunicación preferido y no limitará dichos medios a herramientas automatizadas.
Tres reglas que hay que interiorizar:
- Fácilmente identificable. El contacto debe ser visible en la información del producto, en las instrucciones de acompañamiento del Anexo II y en el sitio web público. Un contacto solo accesible leyendo la política de privacidad no supera este criterio.
- Múltiples canales. "Elegir su medio de comunicación preferido" implica al menos dos. Un buzón
security@operativo más un formulario web, con una clave PGP disponible para envíos sensibles, es la base de referencia realista. - Sin recepción exclusivamente automatizada. "No limitará dichos medios a herramientas automatizadas" descarta una postura en la que la única dirección accesible sea
security-noreply@o un chatbot que cierra tickets sin revisión humana.
El CRA no exige separar el soporte al cliente de la recepción de vulnerabilidades, pero la mayoría de los fabricantes operan un buzón de seguridad dedicado, enrutado al equipo de seguridad del producto, para mantener la CVD separada del soporte general.
Publicar la política de CVD: security.txt y más allá
El CRA no menciona security.txt, RFC 9116, ni ningún formato de publicación específico. Exige un canal de contacto "fácilmente identificable" y una política de CVD "establecida y aplicada". Dentro de esas restricciones, el sector ha convergido en security.txt como convención de facto.
Campos de RFC 9116 que conviene publicar:
| Campo | Finalidad |
|---|---|
Contact: |
Uno o más canales de notificación. Se requiere al menos uno. |
Expires: |
Fecha a partir de la cual el fichero queda obsoleto. Obligatorio según RFC 9116. |
Encryption: |
Clave pública (PGP, S/MIME) para informes confidenciales. |
Acknowledgments: |
Página de créditos a los investigadores por divulgaciones anteriores. |
Policy: |
Enlace al documento completo de política de CVD. |
Preferred-Languages: |
Idiomas en los que opera el equipo de triaje. |
Canonical: |
URL donde se espera que resida el fichero. |
Dónde alojarlo. La ubicación convencional es https://ejemplo.com/.well-known/security.txt, servido por HTTPS. RFC 9116 también acepta https://ejemplo.com/security.txt como alternativa, aunque se prefiere well-known.
Más allá de security.txt. El estándar de "fácilmente identificable" implica que el contacto debe aparecer también en la página de soporte o contacto del producto, en las instrucciones de acompañamiento del Anexo II, en la documentación para desarrolladores en productos de API, y en una página pública de política de CVD a la que los investigadores puedan enlazar.
Los fabricantes que gestionan programas de recompensas suelen añadir HackerOne, Bugcrowd o Intigriti como canales adicionales de recepción. Estos satisfacen el deber de "facilitar la notificación" (letra 6) del Anexo I Parte II) y el deber de "no limitarse a herramientas automatizadas" (Artículo 13(17)) únicamente si están abiertos a investigadores externos con respuesta humana. Un programa privado, solo por invitación, no satisface por sí solo el requisito de contacto público y debe coexistir con un canal público.
Recepción y triaje de informes de vulnerabilidades
Una política de CVD se aplica mediante un flujo de trabajo documentado de recepción y triaje. La mecánica que se describe a continuación no está prescrita por el CRA, pero es el aspecto de una política aplicable en la práctica.
| Fase | Qué hace una política aplicable | Error habitual |
|---|---|---|
| Acuse de recibo | Confirmar la recepción dentro del SLA publicado. La referencia del sector es 72 horas; muchas políticas se comprometen a 24 o 48 horas para informes de gravedad alta. Lo que se publica es lo que se hace. | "Responderemos con prontitud" es inaplicable por definición. |
| Triaje | Validar (reproducible en una versión soportada), puntuar la gravedad (CVSS v3.1 o v4.0 con ajustes ambientales, véase puntuación de gravedad), evaluar la explotabilidad (exploit conocido, PoC público o evidencia en circulación, que es la condición de entrada del Artículo 14) y delimitar las versiones afectadas mediante el SBOM. | Cerrar como "no reproducible" sin indicar el rango de versiones probado. |
| Relación con el investigador | Publicar tres elementos: una declaración de puerto seguro para la investigación de buena fe dentro del alcance; los elementos fuera de alcance (datos de producción, ingeniería social, denegación de servicio contra la infraestructura en producción); y las expectativas de divulgación (ventana de embargo, condiciones de corrección, reconocimiento). Embargo habitual: hasta que el parche se publique, límite máximo de 90 días. | Reservarse el derecho a emprender acciones legales contra la investigación dentro del alcance, lo que destruye el canal. |
| Cierre del caso | Cada informe recibe una respuesta final: corregido (con aviso y CVE), duplicado, no se corregirá (con justificación) o fuera de alcance. | Acusar recibo una vez y no volver a responder, la causa más frecuente de que las políticas de CVD no parezcan aplicadas desde el exterior. |
Coordinación con ENISA e investigadores externos
La recepción de CVD y la notificación a ENISA del Artículo 14 son obligaciones distintas con destinatarios distintos. La política de CVD rige la relación con el investigador. El Artículo 14 rige la notificación regulatoria al CSIRT coordinador y a ENISA. Ambas corren en paralelo y se activan de forma diferente.
Cuándo un informe de CVD se convierte en un activador del Artículo 14. El Artículo 14(1) exige a los fabricantes notificar "cualquier vulnerabilidad activamente explotada" a través del SRP. El Artículo 14(2) establece la cadencia: aviso temprano de 24 horas, notificación de 72 horas e informe final en 14 días desde que una medida correctora esté disponible. El activador es "activamente explotada", no "notificada". Un informe de CVD con una prueba de concepto funcional no es por sí solo un activador del Artículo 14; lo es cuando existe un indicio razonable de que un actor malicioso ha utilizado el fallo contra un objetivo real. En los incidentes graves conforme al Artículo 14(3) y 14(4), la cadencia es de 24 horas, 72 horas y un informe final en el plazo de un mes desde la notificación de 72 horas. Los dos flujos comparten las fases iniciales y divergen en el tramo del informe final. No hay que colapsar ambos en un único esquema "24h/72h/14d". Véase la notificación del Artículo 14 del CRA.
ENISA y los CSIRT designados como coordinadores. El Artículo 14(7) exige la presentación a través del SRP utilizando el punto de acceso electrónico del CSIRT designado como coordinador en el Estado miembro del establecimiento principal del fabricante. El Considerando 76 enmarca el contexto general: los fabricantes pueden recibir informes directamente o a través de un CSIRT designado como coordinador conforme al Artículo 12(1) de la Directiva (UE) 2022/2555 (NIS2). Para la mecánica de incorporación al SRP, véase la incorporación al SRP de ENISA.
Coordinación con el investigador. Cuando un investigador ofrece un embargo mientras se publica la corrección, se documenta la ventana acordada y se respeta. Cuando el investigador rechaza el embargo o publica antes de tiempo, la política de CVD debe indicar cómo se responde, habitualmente acelerando el aviso y el parche.
Plazos de divulgación pública
La divulgación pública de una vulnerabilidad corregida no es opcional conforme al CRA. La letra 4) del Anexo I Parte II exige a los fabricantes, "una vez que se haya puesto a disposición una actualización de seguridad", "compartir y divulgar públicamente información sobre las vulnerabilidades corregidas, incluida una descripción de las vulnerabilidades, la información que permita a los usuarios identificar el producto con elementos digitales afectado, los impactos de las vulnerabilidades, su gravedad e información clara y accesible que ayude a los usuarios a remediarlas". El mismo punto permite un retraso "en casos debidamente justificados, cuando los fabricantes consideren que los riesgos de seguridad de la publicación superan los beneficios para la seguridad", pero solo "hasta que los usuarios hayan tenido la posibilidad de aplicar el parche correspondiente".
Ventanas de embargo. El estándar de facto del sector es de 90 días desde la notificación hasta la divulgación pública, medido desde la fecha en que el fabricante fue notificado por primera vez. Project Zero, CERT/CC y la mayoría de los CSIRT nacionales operan sobre ese anclaje o cerca de él. En el caso de vulnerabilidades activamente explotadas, la ventana suele reducirse a días, dado que el Artículo 14(2)(c) exige un informe final en 14 días desde que una medida correctora esté disponible.
Formato de la divulgación pública. Un aviso alineado con el CRA debe incluir, como mínimo, un identificador CVE, una descripción clara, el producto y rango de versiones afectados, la gravedad (puntuación base CVSS), el impacto, la solución y el reconocimiento cuando el investigador haya aceptado ser nombrado. CSAF (Common Security Advisory Framework) es el soporte legible por máquina que esperan la mayoría de los CSIRT nacionales y la base de datos de vulnerabilidades de ENISA.
El retraso "debidamente justificado" de la letra 4) es estricto. Permite retener el detalle público hasta que los usuarios puedan aplicar el parche; no permite correcciones silenciosas que nunca se publiquen. Un fabricante que distribuye un parche y nunca describe qué corrigió incumple la letra 4) independientemente de su intención.
Errores habituales
| Error | Por qué incumple el CRA |
|---|---|
| Amenazas legales contra investigadores de buena fe | Incumple "aplicar una política de divulgación coordinada de vulnerabilidades" (letra 5) del Anexo I Parte II) y disuade el canal de recepción que exige la letra 6). |
| Sin canal de contacto público, solo un portal interno con acceso restringido | Incumple el requisito de "fácilmente identificable" del Artículo 13(17) y la "dirección de contacto" de la letra 6) del Anexo I Parte II. |
Respuesta automática security-noreply@ sin triaje humano |
El Artículo 13(17) prohíbe limitar la comunicación a herramientas automatizadas. |
| Acusar recibo y no volver a responder | La política está "establecida" pero no "aplicada". La letra 5) del Anexo I Parte II exige ambas cosas. |
| Cerrar informes como "no se corregirá" sin justificación | Externamente indistinguible de ignorar el informe; los investigadores escalan publicando. |
| Agrupar correcciones de seguridad en versiones de funcionalidades que los usuarios posponen | Incumple la letra 2) del Anexo I Parte II: las actualizaciones de seguridad deben ser separables de las actualizaciones de funcionalidades "cuando sea técnicamente viable". |
| Parchear silenciosamente sin publicar ningún aviso | Incumple el deber de divulgación pública de la letra 4) del Anexo I Parte II. |
| Tratar la recepción de CVD como la presentación al ENISA del Artículo 14 | Son destinatarios y obligaciones distintos. La CVD no exime del Artículo 14, y el Artículo 14 no exime de la CVD. |
Preguntas frecuentes
¿Necesitan los fabricantes pequeños una política de CVD conforme al CRA?
Sí. La obligación de política CVD no tiene umbral por tamaño. Se aplica a todos los fabricantes que comercializan en el mercado de la UE un producto con elementos digitales, independientemente de la plantilla o la facturación. Las microempresas y pequeñas empresas se benefician de un alivio limitado en las sanciones por los plazos de aviso temprano de 24 horas del Artículo 14 conforme al Artículo 64(10)(a), que cubre tanto el Artículo 14(2)(a) para vulnerabilidades activamente explotadas como el Artículo 14(4)(a) para incidentes graves. Ese alivio afecta únicamente a esas multas concretas, no a la obligación subyacente, y no se extiende a las medianas empresas. Una empresa de dos personas que comercializa firmware necesita una política de CVD publicada, un canal de contacto y un proceso de triaje exactamente igual que un proveedor grande. (Anexo I Parte II punto 5; Artículo 64(10)(a); Artículo 3(19).)
¿Es obligatorio `security.txt` conforme al CRA?
No. El CRA no menciona security.txt ni RFC 9116. Exige un único punto de contacto "fácilmente identificable" y una dirección de contacto para la notificación de vulnerabilidades. security.txt es la convención de facto utilizada para satisfacer esas obligaciones porque es lo que los escáneres automatizados y la mayoría de los investigadores comprueban primero, pero un contacto publicado de forma destacada en una página pública de seguridad y en las instrucciones del Anexo II también es conforme. El requisito estricto es un canal publicado, operativo y accesible por personas; el formato es una elección. (Artículo 13(17); Anexo I Parte II punto 6; RFC 9116.)
¿Puede el canal de recepción de CVD ser el mismo que la presentación al ENISA del Artículo 14?
No. Son destinatarios y obligaciones distintos. El canal de recepción de CVD es el medio por el que investigadores externos y usuarios notifican vulnerabilidades al fabricante. La presentación del Artículo 14 es la notificación regulatoria del fabricante a ENISA y al CSIRT coordinador, realizada a través de la Plataforma Única de Notificación de ENISA. Un investigador no presenta al SRP; lo hace el fabricante. Confundir ambos conduce a no acusar recibo al investigador (incumplimiento de la CVD) o a no notificar a ENISA cuando se confirma la explotación (exposición a multas del nivel superior). (Artículo 14(1) y 14(7); Artículo 16; Artículo 64(2).)
¿Qué ocurre cuando un investigador externo notifica una vulnerabilidad activamente explotada?
Arrancan en paralelo dos relojes. El proceso de CVD rige la relación con el investigador: acusar recibo, realizar el triaje, acordar un embargo, publicar una corrección, publicar un aviso y reconocer al investigador. El proceso del Artículo 14 rige la relación con el regulador: un aviso temprano de 24 horas a ENISA y al CSIRT coordinador, una notificación de 72 horas y un informe final en 14 días desde que una medida correctora esté disponible. El reloj de 24 horas arranca cuando el fabricante tiene conocimiento de que la explotación es activa; esperar certeza forense hará que se incumpla el plazo. Los dos procesos corren en paralelo y concluyen en superficies distintas. (Artículo 14(1) y 14(2); Anexo I Parte II punto 5.)
¿Debe la política de CVD ofrecer puerto seguro legal a los investigadores?
No, el CRA no exige una cláusula explícita de puerto seguro. El Considerando 76 encuadra la CVD como un proceso de notificación estructurado y señala los programas de recompensas como una forma de incentivar los informes; no codifica el puerto seguro ni el alivio del riesgo legal para los investigadores. La norma proviene de la práctica del sector, no del Reglamento: ISO/IEC 29147, la guía de buenas prácticas de ENISA y la mayoría de las recomendaciones de los CSIRT nacionales convergen en una cláusula escrita de puerto seguro que cubre la investigación de buena fe dentro del alcance publicado. Una política que se reserva el derecho a emprender acciones legales contra la investigación dentro del alcance destruye el canal y falla la mitad de "aplicar" de la letra 5) del Anexo I Parte II en la práctica. (Considerando 76; ISO/IEC 29147; guía de buenas prácticas de ENISA sobre divulgación coordinada.)