[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:es:la-politica-de-divulgacion-coordinada-de-vulnerabilidades-que-exige-el-cra":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"es","la-politica-de-divulgacion-coordinada-de-vulnerabilidades-que-exige-el-cra","La política de divulgación coordinada de vulnerabilidades que exige el CRA: tres disposiciones, y una política de una página que las cumple","El anexo I, parte II, punto 5, del Reglamento de Ciberresiliencia exige a todo fabricante en el ámbito establecer y aplicar una política de divulgación coordinada de vulnerabilidades. El artículo 13, apartado 17, exige un punto de contacto único para las notificaciones, fácil de encontrar y no limitado a herramientas automatizadas; el anexo II, punto 2, exige el contacto y la ubicación de la política en la información al usuario; el anexo VII, punto 2, letra b), pone ambos en la documentación técnica. Qué pide cada disposición, qué debe decir una política y qué no debe prometer.","2026-09-11","\nDe los [ocho requisitos de gestión de vulnerabilidades](\u002Farticles\u002Fcra-annex-i-the-22-essential-requirements-as-a-checklist) del anexo I, parte II, del Reglamento de Ciberresiliencia, Reglamento (UE) 2024\u002F2847, la política de divulgación coordinada de vulnerabilidades es la que la mayoría de los pequeños fabricantes nunca han escrito y pueden escribir en una tarde. También es la que un investigador, un cliente y una autoridad de vigilancia del mercado buscarán por su nombre. Tres disposiciones la definen.\n\n## Disposición uno: la propia política, anexo I, parte II, punto 5\n\nLos fabricantes «establecerán y aplicarán una política de divulgación coordinada de vulnerabilidades». Dos verbos. **Establecer**: existe una política escrita y está publicada donde quien notifica pueda encontrarla. **Aplicar**: la organización la sigue, lo que significa que nombra a quien recibe las notificaciones, qué ocurre después y en qué plazo.\n\nEl punto 5 no prescribe el contenido. El punto 6, junto a él, hace parte del trabajo: los fabricantes «adoptarán medidas para facilitar el intercambio de información sobre posibles vulnerabilidades de su producto con elementos digitales y de los componentes de terceros que contenga, también facilitando una dirección de contacto para la notificación de las vulnerabilidades descubiertas en el producto». Y el punto 4 fija lo que ocurre una vez existe una corrección: las vulnerabilidades corregidas se divulgan públicamente, con una descripción, los productos afectados, el impacto, la gravedad y cómo remedian los usuarios, salvo que publicar hiciera más daño que bien, en cuyo caso la divulgación puede retrasarse hasta que los usuarios hayan podido actualizar.\n\n## Disposición dos: el punto de contacto único, artículo 13, apartado 17\n\nEl artículo 13, apartado 17, exige a los fabricantes designar un punto de contacto único «para que los usuarios puedan comunicarse directa y rápidamente con ellos, también para facilitar la notificación de vulnerabilidades». El punto de contacto debe ser «fácilmente identificable por los usuarios», incluirse en la información al usuario del anexo II, y «permitirá a los usuarios elegir su medio de comunicación preferido y no limitará dichos medios a herramientas automatizadas».\n\nEsa última cláusula descarta un contacto que sea solo un formulario web o solo un bot. Una dirección de correo de seguridad, junto al formulario o plataforma de recompensas que también use, la cumple. Una clave PGP u otra forma de enviar detalles de manera confidencial no la exige el texto, pero es lo que quien notifica esperará.\n\n## Disposición tres: dónde se publica y se archiva\n\n**Anexo II, punto 2**: la información al usuario del producto debe incluir «el punto de contacto único al que se puede notificar y en el que se puede recibir información sobre las vulnerabilidades del producto con elementos digitales, y donde puede consultarse la política del fabricante en materia de divulgación coordinada de vulnerabilidades». Así que la política tiene una ubicación pública, y la información al usuario apunta a ella.\n\n**Anexo VII, punto 2, letra b)**: la [documentación técnica](\u002Farticles\u002Fwhat-goes-in-the-cra-technical-file-annex-vii-point-by-point) contiene «la política de divulgación coordinada de vulnerabilidades, la prueba de que se facilita una dirección de contacto para la notificación de las vulnerabilidades». La política es un documento controlado con versión y fecha, no solo una página web.\n\nLa misma política es también lo que [el artículo 24](\u002Farticles\u002Fdoes-the-cra-apply-to-open-source-software) pide a los administradores de software de código abierto, en forma de una política de ciberseguridad documentada que fomente la gestión de vulnerabilidades y la notificación voluntaria.\n\n## Qué tiene que decir una política de una página\n\n1. **Ámbito.** Qué productos y versiones cubre la política, y el [período de soporte](\u002Farticles\u002Fhow-long-is-the-cra-support-period) durante el cual se actúa sobre las notificaciones.\n2. **Cómo notificar.** El punto de contacto único: como mínimo una dirección de correo, más cualquier formulario o plataforma; cómo enviar los detalles de forma confidencial; qué incluir (producto, versión, pasos para reproducir, impacto).\n3. **Qué puede esperar quien notifica.** Un acuse de recibo en un plazo declarado; una evaluación y una primera respuesta en un plazo declarado; actualizaciones mientras se gestiona la vulnerabilidad. Elija plazos que vaya a cumplir; una promesa de 48 horas que no puede cumplir es peor que cinco días laborables que sí cumple.\n4. **Cómo la gestiona.** Triaje, gravedad, corrección «sin demora» (punto 2), una actualización de seguridad separada de las funcionales cuando sea viable, y la divulgación conforme al punto 4 una vez disponible la actualización. Cuando quien notifica es también la fuente de una vulnerabilidad explotada activamente, los [relojes del artículo 14](\u002Farticles\u002Fwhat-you-have-to-report-under-the-cra-the-two-triggers-defined) corren en paralelo y la política debe decirlo.\n5. **Divulgación y crédito.** Cuándo y cómo publica las vulnerabilidades corregidas, si da crédito a quien notifica, y el motivo para retrasar la publicación (punto 4: cuando el riesgo de seguridad de publicar supere el beneficio, hasta que los usuarios puedan actualizar).\n6. **Puerto seguro.** Una declaración de que la investigación de buena fe dentro de los términos de la política no será objeto de acciones legales por su parte. No lo exige el Reglamento, y es lo que hace que los investigadores le notifiquen a usted en lugar de hablar de usted.\n7. **Responsable y versión.** Quién es responsable de la política, su versión y fecha, y dónde está publicada la versión vigente.\n\n## Qué no debe prometer\n\nNo una recompensa, salvo que tenga un programa. No una corrección para una fecha que no controla. No una confidencialidad que no pueda mantener, ya que el artículo 14 puede exigir notificar al CSIRT e informar a los usuarios. Y no una afirmación de que el producto no tiene vulnerabilidades: el punto 2, letra a), de la parte I trata de las vulnerabilidades explotables conocidas en la comercialización, y todo el sentido de una política de divulgación es que se encontrarán nuevas.\n\nPublíquela en una URL estable, ponga esa URL en la información al usuario, archive la versión fechada con la documentación técnica y ponga la dirección de contacto en los mismos tres sitios. Son tres disposiciones cumplidas con una página.\n\n## Fuentes\n\n- Reglamento (UE) 2024\u002F2847, anexo I, parte II, puntos 2, 4, 5 y 6; artículo 13, apartado 17 (citado); anexo II, punto 2 (citado); anexo VII, punto 2, letra b) (citado); artículo 24 para los administradores; artículo 14 para los relojes de notificación. Leído en el texto del Diario Oficial en EUR-Lex el 11 de septiembre de 2026.\n\nEsto no es asesoramiento jurídico. Las tres disposiciones son lo bastante cortas para pegarlas en el preámbulo de la propia política, que es donde un lector atento las buscará.\n",1789383976652]