La política de divulgación y el archivo security.txt

La divulgación coordinada es un acuerdo entre quien encuentra una vulnerabilidad y quien puede corregirla: el investigador avisa en privado, la empresa confirma y corrige, y los dos acuerdan cuándo se publica. La fecha de publicación protege a la vez a los usuarios, que acaban sabiendo qué pasó y qué hacer, y al investigador, que no queda atado a un silencio sin fin. Las normas internacionales ISO/IEC 29147 (cómo recibir avisos y publicar) e ISO/IEC 30111 (cómo se tramitan por dentro) describen ese proceso.

Una política de divulgación de vulnerabilidades pone eso por escrito: por dónde se avisa, qué puede probar el investigador y qué no, qué se compromete a hacer la empresa y en qué plazos, cuándo se publica y cómo se reconoce a quien avisó. Un programa de recompensas añade un pago por los fallos válidos, pero se apoya en la misma política. Sin ella, pagar solo atrae más reportes a un canal que nadie sabe atender.

El archivo security.txt (RFC 9116) es la forma estándar de decir dónde avisar. Se publica en /.well-known/security.txt, por HTTPS y como texto plano en UTF-8. Solo dos campos son obligatorios: Contact, que aparece una o más veces, y Expires, exactamente una vez. Si hay varios Contact, el orden importa: el primero es el preferido y quien reporta empieza por él. Los demás campos son opcionales: Policy enlaza la política, Encryption enlaza la llave para cifrar (no la contiene), Acknowledgments la página de agradecimientos, Preferred-Languages los idiomas en que se aceptan reportes, Canonical las direcciones donde vive el archivo. Se recomienda además firmarlo.

Que el archivo exista no dice nada de si funciona. Abre el laboratorio, lee security-txt-well-known.txt y después prueba-de-contactos.txt, donde el equipo mandó un mensaje de prueba a cada contacto declarado.

Expires dice hasta cuándo es fiable lo que pone el archivo. La recomendación es que esa fecha quede a menos de un año, para obligar a revisarlo. Pasada la fecha, quien lo lee debe tratarlo como información vieja y no fiarse de ella: el propio estándar considera preferible no tener archivo que tener uno caducado. Un investigador cuidadoso que lo encuentre vencido puede pensar que el canal está abandonado y buscar otra vía, o publicar.

Compara el Expires del archivo de /.well-known con la fecha de la revisión que aparece en encargo.txt.

El estándar admite, por compatibilidad con sitios antiguos, una copia en la raíz del sitio o una redirección desde ella. Pero si hay archivo en los dos sitios, manda el de /.well-known. Una copia en la raíz que nadie mantiene es peor que ninguna: confunde a quien la encuentra primero y le da contactos que ya no existen.

Lee security-txt-raiz.txt, cabeceras.txt y la línea de la prueba que le corresponde.

Una política que sirve dice cuándo contestará la empresa (en días, no «cuando haya disponibilidad») y cuándo se podrá publicar. Las cláusulas que prohíben publicar para siempre, incluso después de corregido, suelen tener el efecto contrario al que buscan: los investigadores serios no aceptan quedar callados sin fecha y prefieren no reportar o publicar por su cuenta. Lee politica-borrador.txt con esa vara.