security.txt - How security researchers report vulnerabilities securely

The number of security vulnerabilities has been continuously increasing for years, and hardly a day goes by without a new, critical vulnerability being present in the media. Not only the number, but also the way the actual information is handled has fundamentally changed over the last 30 years.

With the emergence of the first structures and security communities in the nineties, public platforms for discussing information security were created for the first time. Security researchers who had found a vulnerability reported it there to find recognition in the community. In the best case, the affected parties, whether manufacturers or organizations, were also present in these communities and thus had the opportunity to fix them.

By the beginning of the 2010s, information about vulnerabilities increasingly became a sought-after asset, not only for those affected but also for criminals, so-called threat actors. These exploited vulnerabilities to attack the affected parties, their customers, or both. This culminated in the emergence of ransomware : the victims' data is encrypted to then extort the key for a ransom.

All the more important is that security researchers who have discovered a vulnerability and want to report it receive information on how to reach the affected parties. It should be mentioned at this point that the vulnerability is already present at the time of discovery. The security researcher was only the (hopefully) first person to discover it.

Challenges when reporting a vulnerability

If someone has found a vulnerability in open-source software (Free and Open Source Software (FOSS)), reporting is usually easier. A large part of open-source software is hosted on public platforms such as GitHub and has documented communication channels such as mailing lists, forums or chat platforms. A vulnerability can be reported through this route, mostly even confidentially, and thus the remediation process can be initiated.

With proprietary and commercial software, the reporting path is not always so easy to find. While the giants of the industry such as Microsoft, Google and co. have well-documented reporting paths, the situation is different for smaller manufacturers. The challenge is even greater if it is not a classic piece of software, but a gap in a platform or an infrastructure system.

Consequences of a missing reporting path

If a security researcher cannot find a reporting path and gives up their effort, the actual problem persists and the information remains hidden. In the best case, no one else finds the vulnerability. In the worst case, someone with criminal energy exploits it – today even controlled by artificial intelligence (AI) – and extorts the affected parties or steals their data.

Alternatively, the security researcher can choose the path of full disclosure and publish all information about the vulnerability and possibly its exploitation directly on the internet or on social media. This puts the affected parties under pressure to fix the gap as quickly as possible to prevent it from being exploited by them or their customers. Further information on the different reporting paths and how aramido itself handles found vulnerabilities is described in our blog .

security.txt as a lifesaver

To simply counter the described consequences, a so-called security.txt can be stored. This is a small but effective method to give security researchers the crucial hint on reporting paths. As the name suggests, this is actually a simple text file. This is stored in a standardized path on the own website in the subdirectory /.well-known/, so finally under /.well-known/security.txt. aramido's security.txt is located here, for example: /.well-known/security.txt.

Example of a security.txt file

# If you would like to report a security issue
# you may report it to us via PGP or S/MIME
# encrypted mail or via our contact form
Contact: mailto:security@aramido.de
Contact: /en/kontakt
Contact: tel:+497214519910
Encryption: /pgp/aramido.security.asc
Encryption: openpgp4fpr:960EC6FEAAD4858CF54C5E942A492C40E17B729F
Encryption: /cert/aramido.security.pem
Preferred-Languages: de, en
Hiring: /en/jobs
Canonical: /.well-known/security.txt
Expires: 2027-03-25T00:00:00z

The most important element of the file is the specification of the contact options that a security researcher can use to report a vulnerability. In the simplest case, this can be an email address, but a web form or a telephone number are also possible. To ensure that the contact information is up to date, a validity date is given, usually one year after creation. In this interval, the file is checked and the date is set into the future again.

Formally, the security.txt is standardized by the RFC 9116 of the Internet Engineering Task Force. The information mentioned in the last section is mandatory; the following information can be added optionally:

• Information on how reports can be submitted encrypted
• Preferred language of the report
• Further links to guidelines for security reports, job portals and public acknowledgments

Should a security.txt always be published?

Yes. As soon as a domain is in use, i.e., the associated services are used – whether it is a website, email or something else – from an expert's point of view, we advise creating and publishing a security.txt. If no one reports anything, all the better. The opposite case is much worse for the reasons described above.