No toda persona que busca una vulnerabilidad en un sistema pretende explotarla. Algunas solo quieren contribuir y comunicar el problema a quien puede resolverlo. Pero ¿cómo encontrar el canal y el responsable correctos?
Yo mismo tuve esa dificultad varias veces durante mi carrera. No había ninguna indicación de cómo notificar una vulnerabilidad y generalmente no recibía respuesta de la organización, que tal vez se asustaba más con la noticia que con la propia vulnerabilidad, tal vez pensando que yo iba a perjudicarlos.
Por eso implementamos en IMAGIX un proceso de divulgación coordinada de vulnerabilidades, con una política para recibir informes y un registro público de los investigadores cuyas contribuciones ayudaron a mejorar nuestros servicios.
Quien encuentra una falla necesita saber a quién avisar
Para quien está afuera, la primera dificultad es práctica. La dirección de contacto de un sitio suele llevar a la atención general, y quien lee el mensaje puede no saber qué es una vulnerabilidad ni a quién reenviarla. Un informe técnico enviado por ese camino puede recibir una respuesta automática, quedarse días sin respuesta o llegar tarde a quien puede actuar.
La segunda dificultad es la incertidumbre sobre la reacción, como en las experiencias que mencioné arriba. Quien informa no sabe si la empresa va a agradecer, ignorar o tratar el informe como una amenaza. Sin ninguna indicación pública de cómo la organización maneja esto, muchos investigadores desisten de avisar, y la falla sigue disponible para un individuo malintencionado que no tiene intención de avisar a nadie.
Un archivo en una dirección previsible
El archivo security.txt resuelve la primera dificultad. Definido por la RFC 9116, publicada en 2022, es un archivo de texto simple que cualquier organización puede publicar siempre en la misma ruta de su dominio: /.well-known/security.txt. Quien quiere informar algo no necesita buscar en el sitio, basta con conocer el dominio.
A pesar de ser sencillo, el recurso todavía se usa poco. Un relevamiento publicado en enero de 2025 encontró el archivo en cerca del 1,25% del millón de dominios más visitados del mundo, y menos de la mitad de esos archivos seguía la especificación.
El archivo dice dónde informar y la política define las condiciones
La propia RFC deja claro que el security.txt no sustituye una política de divulgación. Indica dónde informar. Las condiciones de la colaboración quedan en un documento propio, indicado por el campo Policy.
En la política de IMAGIX, esas condiciones cubren cuatro puntos:
- qué enviar: el sistema afectado, la descripción del problema y de su posible impacto, los pasos para reproducirlo y evidencias sin datos sensibles;
- qué no hacer: violar la privacidad de alguien, destruir datos, interrumpir servicios, usar ingeniería social o acceder a cuentas y datos sin autorización;
- qué queda fuera de alcance: escaneos automatizados sin evidencia de impacto, pruebas de denegación de servicio e informes basados únicamente en versiones desactualizadas de software;
- qué esperar: confirmación de la recepción en un plazo de cinco días hábiles, evaluación de la gravedad, respuesta a quien informó y divulgación coordinada después de la corrección.
La política también establece condiciones: la investigación realizada de buena fe, dentro de esas reglas y sin causar daño, es tratada como investigación de seguridad autorizada. Es esa garantía la que permite a un investigador informar sin temor a ser tratado como un intruso.
Divulgación coordinada: corregir antes de hacer público
La divulgación coordinada es el acuerdo de que los detalles de una falla solo se hacen públicos después de la corrección, o después de un plazo razonable acordado entre quien la encontró y quien debe corregirla. Quien la encontró espera y quien la recibió se compromete a investigar, responder y corregir.
El acuerdo protege a ambas partes y, sobre todo, a quien usa el sistema. Publicar los detalles de una falla todavía abierta entrega la información a quien quiere explotarla antes de que exista una corrección. Mantener silencio indefinidamente, por otro lado, le quita a quien informó cualquier garantía de que su informe fue tomado en serio.
El proceso está descrito en normas internacionales: la ISO/IEC 29147 trata de cómo recibir informes y divulgar vulnerabilidades, y la ISO/IEC 30111 trata de cómo la organización investiga y corrige lo que recibió.
Transparencia sin facilitar ataques
Una empresa puede ser transparente sobre la existencia de vulnerabilidades corregidas, sobre sus procesos de respuesta y sobre el reconocimiento de investigadores, sin divulgar información que facilite ataques. El Salón de la Fama es donde IMAGIX aplica ese principio, y cumple dos funciones a la vez.
La primera es reconocer. Los investigadores de seguridad construyen su reputación con el trabajo que pueden mostrar, y un registro público, con el nombre de quien informó y la descripción de lo que se encontró, es una forma concreta de reconocer ese trabajo.
La segunda es rendir cuentas. Cada entrada informa que existió un problema, en qué parte de los servicios, y que fue corregido. Para quien confía datos a un sistema, como un servicio de salud, esto muestra que los problemas se encuentran y que hay alguien que responde cuando eso ocurre. Para quien piensa informar algo, muestra que los informes anteriores fueron recibidos, investigados y corregidos.
Si usted encontró algo, la Política de Divulgación de Vulnerabilidades explica qué enviar y adónde.
Referencias
- Foudil E, Shafranovich Y. RFC 9116: A File Format to Aid in Security Vulnerability Disclosure. IETF, 2022.
- ISO/IEC 29147:2018. Information technology — Security techniques — Vulnerability disclosure.
- ISO/IEC 30111:2019. Information technology — Security techniques — Vulnerability handling processes.
- URIports. Follow-up on security.txt adoption: progress and pitfalls in 2025. 2025.
