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

Desde el 11 de septiembre de 2026, un fabricante que sepa de una vulnerabilidad explotada 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 alerta temprana de 24 horas a las autoridades 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

El canal vale el proceso que lo atiende. 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. Nada de esto es exótico; todo esto falla cuando se improvisa.

Por dónde empezar

Nuestro punto de partida está a la vista: el security.txt de este sitio, con clave PGP publicada, es 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