A text file that gets a vulnerability reported to you sooner

At the address /.well-known/security.txt there is a four line text file on our server. It says which address someone writes to if they find a security hole at our place, which languages we answer in and how long the information is valid. The file is a few hundred bytes, costs nothing per month and is set up in twenty minutes. It is the difference between a report that reaches a human being on the same day and a report that never happens.

What goes into the file

The format is laid down in RFC 9116, plain text, field by field. Two entries are mandatory, the rest is convenience:

• Contact: a mail address or a URL that reports go to. Several entries are allowed, the topmost counts as the preferred one.
• Expires: the date from which the file counts as out of date. That sounds like paperwork and is the most useful part, more on that below.
• Preferred-Languages: de, en saves the finder the guesswork.
• Policy: a page that says how you handle reports and how long you take to answer.
• Encryption: a public key, if you want to accept encrypted reports.

The file belongs on HTTPS and at exactly this path, because that is where automated tools look. A contact page with a form does not replace it: a finder who checks twenty domains requests the same path twenty times, not twenty different legal notices.

1.8 percent, and the rest says nothing

A study of German websites finds that only 1.8 percent provide a security.txt at all. With the other 98 percent, someone who has found something has to guess: legal notice, info@, contact form, LinkedIn. Every one of these routes leads to a person whose job is something other than security reports. And every one of these routes costs the finder time nobody pays them for.

That is the point at which a report dies. Not out of malice, but because the effort grows larger than the good intention.

The most expensive report is the one that reaches nobody

Work through the sequence once. Case one: someone finds a misconfigured share, writes to the address from your security.txt, gets an answer the same day, and the two of you sort it out in two days. Cost: half a working day and one change to a configuration.

Case two: the same share, no route for reporting. The finder gives up or writes about it publicly. In the worse course of events, a second person finds it who does not report at all. Now it no longer runs on your calendar but on somebody else's, plus deadlines from the General Data Protection Regulation, customer calls and a night in which someone gets woken up.

The difference between the two cases is four lines of text. That is not a security strategy, that is a doorbell.

Who reads the address

An address that nobody reads is worse than none, because it makes a promise that is not kept. At our place, the cloud, the mail server, the password manager, the Git server and this website run on a server we operate ourselves. The mailbox behind the address sits on that same mail server, it goes to both of us and it is on our phones as well. There are two of us, so responsibility is not the question, only reachability is.

We are open about how small this is: so far, not a single report has come in. That is not an achievement, that is statistics. The route is set up anyway, because you do not build it in the moment you need it.

In a larger operation the question is the same, just with more names: who opens the mailbox, who answers when that person is on holiday, and who is allowed to decide that a system goes offline on short notice. Those three lines belong in a document that is actually written down. When choosing the mailbox you have the same steps as everywhere: your own mail server, a hosted mailbox with a provider in Germany, or a service that manages reports as tickets. All that matters is that the address belongs to you, so it sits under your own domain. Then the provider behind it stays exchangeable.

Check automatically, decide by hand

Two things can be left to the machine. First, the reminder about the Expires date: our file is shipped together with the website and lives in the Git server, the date sits in the calendar as an appointment. If it runs out without anyone confirming the entries, that is a fault like an expiring certificate. Second, the pre-sorting of incoming reports: much of what arrives at a public security address is bulk mail and output from automated scanners without an actual finding.

What does not happen automatically is the judgement. Whether a report is a false alarm, whether a service is shut down immediately, a version rolled back or simply watched for now, is decided by a human. That is how we build our automations too: the system proposes, a human approves. With a security report, the wrong reaction is often more damaging than the hole itself.

Why this is pressing now

The number of vulnerabilities being found is rising, because searching has become cheaper. The head of Google Threat Intelligence says there are more zero days than ever thanks to AI. For you that means nothing dramatic, but something practical: the likelihood that someone finds something in your systems is higher today than it was two years ago. The only question is whether that someone knows where to write.

What you can do this week

1. Check whether there is anything at yourdomain.de/.well-known/security.txt. Probably not.
2. Create a text file with Contact, Expires and Preferred-Languages. As the contact, use an address under your own domain, not a personal mailbox.
3. Write down who reads that mailbox and who answers when that person is away.
4. Set the Expires date to at most one year out and put it in the calendar.

Unspectacular, and dependable for exactly that reason. If you want to know what such a mailbox and the rest of the operation could look like at your place, write to us.

Image caption: A robot screws a small brass bell onto a door frame next to a wooden door while a person holds the bell steady by hand; beside them stand a work light, a tin of screws and a coiled cable.