Un recordatorio entre sysadmins: sin security.txt no hay canal para avisar de un fallo
El aviso señala que dos dominios del gobierno australiano no publican el fichero que indica a quién reportar una vulnerabilidad, justo después de una queja por falta de notificación.
El gobierno australiano se quejó de que OpenAI no le avisó por un canal adecuado después de que un agente suyo accediera a uno de sus sitios. El recordatorio que ha corrido esta semana entre administradores de sistemas le da la vuelta al asunto: según quien lo publicó, ni servicesaustralia.gov.au ni data.gov.au sirven un archivo security.txt. Tanto la queja como la ausencia del fichero son afirmaciones suyas, sin verificación independiente.
Un fichero estático que decide a quién escribes
security.txt no es un producto ni una herramienta que haya que instalar. Es un archivo de texto plano que se publica en /.well-known/security.txt, normalizado hace años en el RFC 9116, y que describe cómo contactar con el equipo de seguridad de un dominio. Lleva dos campos obligatorios, Contact y Expires, y varios opcionales: la clave PGP para cifrar el envío, la política de divulgación, si se acredita a quien reporta o en qué idiomas atienden.
El coste de tenerlo es un fichero estático servido por el mismo servidor web que ya está en marcha, sin lógica ni dependencias. Por eso chirría que falte en dominios grandes: no hay una razón técnica, simplemente nadie lo ha añadido al despliegue. Cualquiera puede comprobar si su organización lo tiene pegando la ruta en el navegador.
Qué pasa cuando no está
Si el fichero no existe, quien encuentra un fallo tiene que improvisar: mirar el WHOIS, rellenar un formulario genérico de atención al ciudadano o escribir a un correo que quizá no lee nadie del equipo correcto. En un incidente con un agente automatizado, que hace peticiones por su cuenta y a un ritmo que ninguna persona mantiene, esa fricción se traduce en horas o en que el aviso no llegue.
Conviene ser claro con el alcance: un security.txt no evita el incidente ni arregla un acceso indebido. Lo que hace es que la notificación tenga un destinatario definido antes de que haga falta, en lugar de negociarse a posteriori y por vía pública.
El detalle práctico que más se olvida es el campo Expires, obligatorio. Un fichero caducado es casi peor que no tenerlo, porque el estándar permite que un investigador lo ignore. Si vas a revisarlo, mira también que el contacto apunte a un buzón que alguien lea de verdad y no a una lista que se quedó sin dueño tras la última reorganización. La especificación y la ruta exacta están en securitytxt.org.
