Not everyone who looks for a vulnerability in a system intends to exploit it. Some just want to contribute and report the problem to whoever can fix it. But how do you find the right channel and the right person?

I ran into this difficulty myself several times during my career. There was no indication of how to report a vulnerability, and I usually got no response from the organization, which was perhaps more frightened by the news than by the vulnerability itself, perhaps thinking I was going to harm them!

With that in mind, we implemented a coordinated vulnerability disclosure process at IMAGIX, with a policy for receiving reports and a publicly available record of the researchers whose contributions have helped improve our services.

Anyone who finds a flaw needs to know whom to tell

For someone on the outside, the first difficulty is practical. A website’s contact address usually leads to general customer service, and whoever reads the message may not know what a vulnerability is or whom to pass it on to. A technical report sent that way may get an automated reply, go unanswered for days, or reach the people who can act too late.

The second difficulty is uncertainty about the reaction, as in the experiences I mentioned above. The person reporting does not know whether the company will thank them, ignore them, or treat the report as a threat. Without any public indication of how the organization handles this, many researchers give up on reporting, and the flaw remains available to a malicious individual who has no intention of telling anyone.

A file at a predictable address

The security.txt file solves the first difficulty. Defined by RFC 9116, published in 2022, it is a plain text file that any organization can publish, always at the same path on its domain: /.well-known/security.txt. Someone who wants to report something does not need to search the website; knowing the domain is enough.

Despite its simplicity, the mechanism is still rarely used. A survey published in January 2025 found the file on about 1.25% of the world’s top one million domains, and fewer than half of those files followed the specification.

The file says where to report and the policy sets the conditions

The RFC itself makes clear that security.txt does not replace a disclosure policy. It says where to report. The conditions of the collaboration belong in a separate document, referenced by the Policy field.

In IMAGIX’s policy, those conditions cover four points:

  • what to send: the affected system, a description of the issue and its potential impact, the steps to reproduce it, and supporting evidence with sensitive data removed;
  • what not to do: violate anyone’s privacy, destroy data, disrupt services, use social engineering, or access accounts and data without authorization;
  • what is out of scope: automated scans without evidence of impact, denial-of-service tests, and reports based only on outdated software versions;
  • what to expect: acknowledgment of the report within five business days, severity assessment, feedback to the reporter, and coordinated disclosure after remediation.

The policy also sets out conditions: research conducted in good faith, within these rules, and without causing harm is treated as authorized security research. That guarantee is what allows a researcher to report without fear of being treated as an intruder.

Coordinated disclosure: fix first, then make it public

Coordinated disclosure is the agreement that the details of a flaw only become public after it is fixed, or after a reasonable deadline agreed between whoever found it and whoever needs to fix it. The person who found it waits, and the organization that received the report commits to investigating, responding, and fixing.

The agreement protects both parties and, above all, the people who use the system. Publishing the details of a flaw that is still open hands the information to those who want to exploit it before a fix exists. Staying silent indefinitely, on the other hand, leaves the reporter with no assurance that the report was taken seriously.

The process is described in international standards: ISO/IEC 29147 covers how to receive reports and disclose vulnerabilities, and ISO/IEC 30111 covers how the organization investigates and fixes what it has received.

Transparency without making attacks easier

A company can be transparent about the existence of fixed vulnerabilities, about its response processes, and about recognizing researchers, without disclosing information that makes attacks easier. The Hall of Fame is where IMAGIX applies this principle, and it serves two purposes at once.

The first is recognition. Security researchers build their reputation through the work they are able to show, and a public record, with the name of the person who reported and a description of what was found, is a concrete way of recognizing that work.

The second is accountability. Each entry states that a problem existed, in which part of the services, and that it was fixed. For anyone who entrusts data to a system, such as a healthcare service, this shows that problems are found and that there is someone to respond when that happens. For anyone thinking of reporting something, it shows that previous reports were received, investigated, and fixed.

If you have found something, the Vulnerability Disclosure Policy explains what to send and where.

References

#Information security#Vulnerability disclosure#Transparency