Cualquier persona que encuentre una vulnerabilidad en tu producto necesita una vía clara y humana para notificarla, y tu equipo necesita una política escrita sobre cómo se acusa recibo, se tría, se corrige y se divulga ese informe. Bajo el Reglamento (UE) 2024/2847 sobre Ciberresiliencia, esto implica poner en marcha y aplicar una política de divulgación coordinada de vulnerabilidades (CVD), además de publicar un único punto de contacto para las notificaciones de vulnerabilidades. No existe exención por tamaño. Esta página cubre qué debe contener la política, cómo publicar el canal de contacto y cómo la CVD se relaciona con la vulnerability reporting y con el marco más amplio del vulnerability handling.
Resumen
- La política de CVD es obligatoria. Escrita, publicada, aplicada, sin umbral por tamaño. Se detalla en Qué exige realmente el CRA más abajo.
- Se exige un único punto de contacto. Los usuarios deben poder llegar a una persona; 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 lo mismo que la notificación a ENISA. La CVD rige tu relación con quien informa; el reloj regulatorio hacia ENISA y el CSIRT coordinador corre en paralelo. Véase Coordinación con ENISA más abajo.
- La divulgación pública de las vulnerabilidades corregidas es obligatoria, con un margen de demora estrechamente delimitado cuando el riesgo de seguridad de la publicación supera el beneficio hasta que los usuarios hayan podido aplicar el parche.
- Los detalles de sanciones van en la guía de ejecución. Consulta sanciones y ejecución para la escala de multas y las medidas de mercado.
Los cuatro anclajes de una postura CVD conforme al CRA: política, contacto, publicación y remisión a ejecución.
Qué exige realmente el CRA en materia de CVD
El requisito de CVD es breve: los fabricantes deben "poner en marcha 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:
| Requisito | Qué significa en la práctica | Fallo habitual |
|---|---|---|
| Poner en marchaPolítica documentada | Existe una política escrita y accesible. Indica a quien informa qué entra en el alcance, cómo notificar, qué respuesta esperar y cuándo se produce la divulgación. | Una costumbre interna no documentada de gestionar correos a security@ no cumple el requisito. |
| AplicarProceso operado | La política se opera, no se limita a publicarse. Los plazos de acuse de recibo, los compromisos de triaje y las condiciones de divulgación recogidos en el documento se respetan en la práctica. | Una política que promete acuse de recibo en 72 horas pero que de forma habitual tarda tres semanas no se está aplicando. |
| Facilitar la notificaciónCanal accesible | La política hace que compartir información de vulnerabilidades sea sencillo para quien notifica desde fuera: una dirección de contacto, un proceso publicado y un canal humanamente accesible que no esté detrás de un inicio de sesión o de un chatbot. | Un portal solo accesible tras autenticación, una recepción solo automatizada o una ruta de contacto enterrada incumplen la dirección de la obligación. |
| No penalizar a quien informaNorma de investigación de buena fe | No es una cláusula literal del CRA. El CRA encuadra la CVD como notificación estructurada y señala que los programas de recompensas pueden incentivar los informes. ISO/IEC 29147 y la guía de buenas prácticas de ENISA tratan el puerto seguro para la investigación de buena fe como una característica normal de una política de CVD. | Reservarse acciones legales contra investigación de buena fe dentro del alcance hace colapsar el canal aunque exista dirección de contacto. |
Para el marco más amplio (los ocho deberes numerados de los cuales la CVD es uno), consulta vulnerability handling.
El único punto de contacto
La política de CVD solo funciona si quien informa puede encontrar un contacto real y llegar a una vía humana dentro del fabricante. El deber de único punto de contacto del CRA se traduce en tres requisitos concretos:
- Fácilmente identificable. El contacto debe ser fácil de encontrar y aparecer en las instrucciones que acompañan al producto; en la práctica, también en el sitio web de seguridad o en un canal de contacto público similar donde los investigadores lo buscan, no enterrado en la política de privacidad.
- Múltiples canales. "Elegir los medios de comunicación que prefieran" 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 usuario 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 distinta del soporte general.
Publicar tu política de CVD: security.txt y más allá
El CRA no nombra 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 "puesta en marcha y aplicada". Dentro de esas restricciones, la industria 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 quienes han notificado divulgaciones pasadas. |
Policy: |
Enlace al documento completo de política de CVD. |
Preferred-Languages: |
Idiomas en los que opera el equipo de triaje. |
Canonical: |
URL en la que 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 well-known es preferible.
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 que acompañan al producto, 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 quien informa pueda enlazar.
Los fabricantes que operan 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" y el de "no limitarse a herramientas automatizadas" solo si están abiertos a notificadores externos con respuesta humana. Un programa privado, únicamente 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 documentado de recepción y triaje. La mecánica que sigue no está prescrita por el CRA, pero es como se ve una política aplicable en la práctica.
| Fase | Qué hace una política aplicable | Fallo 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 su propio enunciado. |
| Triaje | Validar (reproducible en una versión soportada), puntuar la gravedad (CVSS v3.1 o v4.0 con ajustes ambientales, véase severity scoring), evaluar la explotabilidad (exploit conocido, PoC público o evidencia en circulación, que es la condición de escalada regulatoria) y delimitar las versiones afectadas mediante el SBOM. | Cerrar como "no reproducible" sin indicar el rango de versiones probado. |
| Relación con quien informa | 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 infraestructura en producción); y las expectativas de divulgación (ventana de embargo, condiciones de corrección, reconocimiento). Embargo habitual: hasta que se publique el parche, con tope de 90 días. | Reservarse el derecho a emprender acciones legales contra 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 una política de CVD no parezca aplicada desde fuera. |
Coordinación con ENISA e investigadores externos
La recepción de CVD y la notificación a ENISA son obligaciones distintas con destinatarios distintos. La política de CVD rige tu relación con quien informa. La notificación regulatoria rige tu deber hacia ENISA y el CSIRT coordinador. Ambas corren en paralelo y se activan de forma diferente.
Cuándo un informe de CVD se convierte en un activador regulatorio. Los fabricantes deben notificar "cualquier vulnerabilidad aprovechada activamente" a través de la SRP con una cadencia de 24 horas, 72 horas y 14 días. El activador es "aprovechada activamente", no "notificada". Una recepción de CVD con una prueba de concepto funcional no es por sí sola un activador regulatorio; lo es cuando existe evidencia fiable de que un actor malicioso ha explotado la vulnerabilidad en un sistema sin permiso.
Los incidentes graves siguen una cadencia distinta: 24 horas, 72 horas y luego 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 los colapses en un único esquema "24h/72h/14d". Véase vulnerability reporting.
ENISA y los CSIRT designados como coordinadores. La presentación se realiza a través de la SRP utilizando el nodo final electrónico del CSIRT designado como coordinador en el Estado miembro del establecimiento principal del fabricante. Los fabricantes pueden recibir informes directamente, o indirectamente a través de un CSIRT designado como coordinador con arreglo a la Directiva NIS2. Para la mecánica de incorporación a la SRP, consulta ENISA SRP onboarding.
Coordinación con quien informa. Cuando quien informa ofrece un embargo mientras se publica la corrección, documenta la ventana acordada y respétala. Cuando quien informa rechaza el embargo o publica antes de tiempo, tu 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 bajo el CRA. Una vez puesta a disposición una actualización de seguridad, los fabricantes deben compartir y divulgar públicamente una descripción de la vulnerabilidad, información que permita a los usuarios identificar el producto afectado, el impacto, la gravedad y orientación clara sobre la corrección. Se permite un retraso "en casos debidamente justificados" cuando el riesgo de seguridad de la publicación supere el beneficio, pero solo "hasta que se haya dado a los usuarios la posibilidad de aplicar el parche correspondiente".
Ventanas de embargo. El estándar de facto del sector es 90 días desde la notificación hasta la divulgación pública, medidos 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. Para vulnerabilidades aprovechadas activamente, la ventana suele reducirse a días, dado que el informe final regulatorio debe presentarse 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 quien informa 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" 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 el deber de divulgación pública, con independencia de su intención.
Errores comunes
| Error | Por qué incumple el CRA |
|---|---|
| Amenazas legales contra investigadores de buena fe | Rompe el deber de "aplicar una política de divulgación coordinada de vulnerabilidades" y disuade el canal de recepción que exige el mismo deber. |
| Sin canal de contacto público, solo un portal interno con inicio de sesión | Incumple el deber de "fácilmente identificable" del único punto de contacto y el deber de "facilitar una dirección de contacto". |
Respuesta automática security-noreply@ sin triaje humano |
El único punto de contacto prohíbe limitar la comunicación a herramientas automatizadas. |
| Acusar recibo y no volver a responder | La política está "puesta en marcha" pero no "aplicada"; ambas son obligatorias. |
| Cerrar informes como "no se corregirá" sin justificación | Externamente indistinguible de ignorar el informe; quienes informan escalan publicando. |
| Agrupar correcciones de seguridad en versiones con funcionalidades que los usuarios posponen | Las actualizaciones de seguridad deben poder separarse 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. |
| Tratar la recepción de CVD como la presentación a ENISA | Destinatarios distintos, obligaciones distintas. La CVD no exime de la notificación regulatoria, y la notificación regulatoria no exime de la CVD. |
Preguntas frecuentes
¿Necesitan los fabricantes pequeños una política de CVD bajo el CRA?
Sí. El deber de política de CVD no tiene umbral por tamaño. Se aplica a todo fabricante que comercializa en el mercado de la UE un producto con elementos digitales, con independencia de la plantilla o la facturación. Las microempresas y las pequeñas empresas se benefician de un alivio sancionador estrecho sobre los plazos de alerta temprana de 24 horas, pero el alivio afecta únicamente a [esas multas](/cra-compliance/penalties-and-enforcement), no a la obligación subyacente, y no se extiende a las medianas empresas. Una empresa de dos personas que vende firmware necesita una política de CVD publicada, un canal de contacto y un proceso de triaje exactamente igual que un proveedor grande.
¿Es obligatorio `security.txt` bajo el CRA?
No. El CRA no nombra 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 esos deberes porque es lo que comprueban primero los escáneres automatizados y la mayoría de los investigadores, pero un contacto publicado de forma destacada en una página pública de seguridad y en las instrucciones que acompañan al producto también es conforme. El requisito estricto es un canal publicado, operativo y humanamente accesible; el formato es una elección.
¿Puede el canal de recepción de CVD ser el mismo que la presentación a ENISA?
No. Son destinatarios distintos y obligaciones distintas. La recepción de CVD es el canal por el que investigadores y usuarios externos notifican vulnerabilidades al fabricante. La presentación a ENISA es la notificación regulatoria del fabricante a ENISA y al CSIRT coordinador, realizada a través de la Plataforma Única de Notificación. Quien informa no presenta a la SRP; lo hace el fabricante. Confundir ambas conduce o bien a no acusar recibo a quien informa (incumplimiento de la CVD), o bien a no notificar a ENISA cuando se confirma la explotación (exposición sancionadora seria).
¿Qué ocurre cuando un investigador externo notifica una vulnerabilidad aprovechada activamente?
Arrancan en paralelo dos relojes. El proceso de CVD rige la relación con quien informa: acusar recibo, triar, acordar un embargo, publicar una corrección, publicar un aviso y reconocer a quien informa. El proceso regulatorio rige la relación con ENISA y el CSIRT coordinador: una alerta temprana de 24 horas, 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, lo que puede ser el momento en que la evidencia del investigador hace creíble esa conclusión. Esperar a la certeza forense hará incumplir el plazo. Los dos procesos corren en paralelo y concluyen en superficies distintas.
¿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 CRA 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 más que 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 investigación dentro del alcance hace colapsar el canal y falla la mitad de "aplicar" del deber de política de CVD en la práctica.