Saltar al contenido
folhas.io
secure by design para productos conectados· Artículos

Artículos

Divulgación coordinada de vulnerabilidades: el canal que el CRA obliga a mantener abierto

Las obligaciones de notificación a las autoridades ya son aplicables, pero son la mitad del circuito. El anexo I, Parte II, exige la otra mitad: un canal público para recibir informes de vulnerabilidades, con política, punto de contacto y proceso detrás. Cuesta poco montarlo, y hay norma para casi todo.

Publicado
Actualizado

Nota de actualización (23 oct 2026). Hemos añadido la sección «Del lado de quien integra», sobre la comunicación de vulnerabilidades a quien mantiene los componentes (artículo 13, apartado 6), con el ejemplo de las correcciones de PHP de octubre de 2026.

Desde el 11 de septiembre de 2026, un fabricante que sepa de una vulnerabilidad aprovechada activamente en su producto tiene plazos contados en horas para avisar a las autoridades — el artículo sobre la notificación de 24 y 72 horas describe ese circuito al detalle. Ese circuito es el de salida. El reglamento dibuja también el de entrada: cómo llega al fabricante la información sobre una vulnerabilidad, desde fuera, por el camino más corto posible.

Qué pide el anexo I, Parte II

Los requisitos de tratamiento de vulnerabilidades del CRA pasan a ser exigibles con la aplicación plena, el 11 de diciembre de 2027, para los productos con elementos digitales introducidos en el mercado a partir de entonces. La lista es corta y concreta:

  • Inventariar los componentes y las vulnerabilidades del producto, con una SBOM en formato legible por máquina (el artículo 01 trata de cómo generarla sin mentir);
  • Tratar y corregir vulnerabilidades sin demora, con actualizaciones de seguridad distribuidas de forma segura y sin coste para el usuario;
  • Probar la seguridad del producto con regularidad;
  • Divulgar públicamente las vulnerabilidades corregidas, con información útil para quien opera el producto;
  • Tener una política de divulgación coordinada de vulnerabilidades, publicada y aplicada en la práctica;
  • Facilitar la comunicación de vulnerabilidades desde fuera, con un punto de contacto público.

Quien espere a diciembre de 2027 para abrir el canal lo abrirá con el resto de la conformidad encima de la mesa, el peor momento para escribir política con calma.

El mínimo que ya funciona

La puerta de entrada tiene norma propia y cabe en un fichero de texto. El security.txt (RFC 9116) vive en /.well-known/, apunta un contacto, una clave PGP para informes cifrados y una fecha de caducidad que obliga a revisitarlo. El contacto debe ser una dirección dedicada, que sobreviva a salidas de personas y a buzones personales.

La política publicada no necesita ser larga. Bastan tres cosas: el ámbito (qué productos y versiones), lo que el fabricante promete (confirmación de recepción en un plazo definido, referencia pública cuando salga la corrección), y lo que pide a quien informa (un margen razonable antes de la divulgación pública, no acceder a datos de terceros durante la investigación). La divulgación coordinada no es un programa de recompensas: la mayoría de los informes serios llega de investigadores y de clientes que solo quieren una respuesta competente.

Para quien quiera ir más allá del mínimo, la interfaz con el exterior está normalizada en la ISO/IEC 29147 y el proceso interno en la ISO/IEC 30111. Las dos se escribieron para encajar, y la lectura es más corta de lo que parece.

Flujo de la divulgación coordinada: quien descubre una vulnerabilidad (investigador, cliente o integrador, escáner de terceros) entra por un canal público compuesto por security.txt, clave PGP, política publicada y triaje con responsable; del canal salen dos destinos: la corrección y el aviso a los usuarios, y, si hay explotación activa, la notificación de alerta temprana a las autoridades, en 24 horas, conforme al artículo 14.
Un canal, dos destinos. El triaje es la pieza que decide si un informe sigue el circuito normal de corrección o dispara los plazos del artículo 14.

El proceso detrás de la dirección

Un informe que entra necesita cuatro cosas, por este orden: confirmación de recepción, triaje con responsable y plazo, decisión sobre la gravedad, y un registro de todo ello que sobreviva a la memoria de quien lo atendió.

En el triaje es donde los dos circuitos se tocan. Un informe externo puede ser exactamente la señal que dispara el artículo 14: si describe explotación activa, la empresa acaba de «tener conocimiento» y el reloj de las 24 horas corre desde la conclusión de ese triaje. Quien atiende el canal de entrada tiene que saber reconocer lo que lleva plazos de salida.

El resto del proceso es lo esperable: corregir, distribuir la actualización por el canal seguro, publicar el aviso con la vulnerabilidad corregida, y dar crédito a quien informó, si lo desea.

Del lado de quien integra

El fabricante que recibe informes también tiene que enviarlos. A partir de la aplicación plena, el artículo 13, apartado 6, obliga al fabricante que detecte una vulnerabilidad en un componente integrado en su producto, incluido uno de código abierto, a comunicarla a quien fabrica o mantiene ese componente y a compartir la corrección, si la desarrolla. Las orientaciones de la Comisión de 27 jul 2026, C(2026) 5252, no vinculantes, piden que esa comunicación siga los canales y la política de divulgación del propio proyecto, y entienden que no es exigible cuando el fabricante puede confirmar que el mantenedor ya conoce la vulnerabilidad.

El caso de PHP en octubre de 2026, que analiza el artículo 09, muestra el otro lado del mismo circuito. El proyecto preanunció las correcciones la víspera, las distribuciones Linux y los proveedores de soporte extendido las recibieron antes del lanzamiento, y quien integra PHP sin pasar por ninguno de ellos solo las tuvo con el lanzamiento público. Para los componentes críticos, esto pide dos cosas preparadas de antemano: seguir los avisos de seguridad de cada proyecto del que depende el producto y saber por qué distribución o proveedor llega cada componente. El aviso que el fabricante publica después tiene que permitir identificar el producto afectado, y un documento VEX (afectado, no afectado, corregido, en investigación) da esa información en formato legible por máquina.

Por dónde empezar

Nuestro punto de partida está a la vista: el security.txt de este sitio, con clave PGP publicada, y la política de divulgación que lo acompaña son el embrión del canal de nuestro propio producto, y la entrada 001 del diario fijó esa decisión antes de existir producto en el mercado. Para un fabricante con producto a la venta, el orden práctico es el mismo y cabe en un trimestre: dirección dedicada y security.txt esta semana, política corta publicada después, proceso de triaje con responsable y un ensayo en la agenda antes de que acabe el trimestre.

Un canal abierto antes del primer informe es infraestructura. Abierto después, es gestión de crisis.

Fuentes