security.txt Is Not a Security Programme

Someone finds a security weakness on your website and wants to report it responsibly. They find only a general contact form, a sales inbox, or no relevant contact at all.

The message may land in spam. Support may mistake it for marketing. It may be forwarded to an agency that stopped maintaining the site months ago. The vulnerability remains in place while the report searches for an owner.

A security.txt file can solve that first problem. It gives people and automated tools a clear route for reporting security findings. It does not solve the larger problem: what happens after the report arrives?

The myth: “We have security.txt, so we are prepared”

RFC 9116 defines security.txt as a machine-readable format for vulnerability disclosure information. For web services, the file belongs at /.well-known/security.txt, must be served over HTTPS, and includes at least a contact and an expiry date.

That is useful. It creates a predictable entry point and reduces the chance that a good-faith report disappears inside an organisation.

The RFC also makes the boundary clear: the file complements a disclosure process. It does not replace one.

A technically perfect file provides little value when:

• nobody monitors the mailbox,
• the listed person has left the organisation,
• reports are never acknowledged,
• no technical owner is assigned,
• there is no triage target or response window,
• external suppliers cannot be reached,
• the reporter receives no update after remediation.

In that situation, security.txt is a well-signposted mailbox that nobody empties.

What a valid security.txt should provide

1. The correct location

The authoritative file should be available at https://your-domain.example/.well-known/security.txt. A legacy /security.txt path may redirect for compatibility, but it should not become a second conflicting source.

2. A working contact

The Contact field must point to a channel that is genuinely monitored, such as a dedicated email address or secure reporting form.

Test it regularly from outside the organisation. A mailbox is not operational merely because it exists in the mail system.

3. A current expiry date

Expires is mandatory. It states when the information should be considered stale. RFC 9116 recommends setting it less than one year into the future.

That creates a useful maintenance checkpoint: are the contact, policy, and encryption details still correct?

4. A clear scope

A Policy link can explain which systems are covered, which testing practices are acceptable, and how the disclosure process works. The file generally applies to the host from which it was retrieved, not automatically to every subdomain.

5. A secure communication option

The Encryption field can point to a key or secure channel for sensitive details. That option is useful only when the key is current and somebody inside the organisation can actually decrypt the report.

6. A canonical address

The Canonical field helps confirm the intended location. When used, it must correctly include the URL from which the file was retrieved.

Seven operational questions that matter more than the file

NIST describes vulnerability disclosure as a framework for receiving, assessing, managing, and communicating vulnerability reports. That full chain needs to exist behind the published contact.

1. Who reads new reports?

Use a monitored queue rather than one personal mailbox. Cover holidays, illness, and staff changes.

2. How quickly is receipt acknowledged?

A brief acknowledgement tells the reporter that the message arrived and reduces the pressure to escalate through public or unrelated channels.

3. Who validates the technical finding?

Not every report is complete or correct. Someone needs to identify affected systems, reproduce the behaviour, and request additional information safely.

4. How are severity and urgency assessed?

A minor header observation needs a different response from a publicly exploitable authentication bypass. Prioritisation should consider exposure, exploitability, potential data impact, and existing controls.

5. Who can initiate the fix?

For externally maintained websites, responsibility may sit with the company, agency, hosting provider, or SaaS vendor. Unclear ownership often causes more delay than the technical work.

6. How is sensitive information handled?

Reports may contain exploit steps, screenshots, account details, or other sensitive material. They should not be copied casually into public tickets, broad chat channels, or long forwarding chains.

7. How is the case closed?

After remediation, the team should document reproduction, deployment, regression testing, and communication. CERT/CC describes coordinated disclosure as collaboration between reporters and affected parties to reduce harm and provide mitigations.

Red flags in existing files

Review your security.txt as an external reporter would:

• The path returns an HTML error page instead of plain text.
• The server returns 200, but the body is the generic homepage.
• The expiry date is in the past.
• The contact address bounces.
• The policy points to a deleted or private page.
• A former agency contact is still listed.
• The main domain and subdomains publish conflicting instructions.
• A redirect ends on an unrelated domain.
• The encryption key is unavailable or unusable internally.
• There is no internal ticket, escalation, or ownership model.

A formally valid file with organisationally invalid information is particularly deceptive. Automated checks may mark it as present while genuine reports still disappear.

A pragmatic minimum process for small teams

A small business does not need a full security operations centre to handle reports responsibly. A lightweight process can include:

1. A dedicated address or form with at least two responsible recipients.
2. An automatic acknowledgement that does not promise a specific fix.
3. A private internal ticket with a timestamp.
4. Initial technical triage within a defined window.
5. One named person coordinating work and communication.
6. A secure channel for additional evidence.
7. A documented decision on priority, remediation, and disclosure.
8. Regression testing after the fix.
9. A closing update to the reporter where appropriate.
10. A quarterly test of the file, mailbox, policy, and escalation path.

The process does not need to be elaborate. It needs to be discoverable, monitored, and repeatable.

What Website-Pflichtencheck would inspect

A technical and operational review should not stop at confirming that /.well-known/security.txt exists. It can examine:

• the path, HTTPS delivery, status, and Content-Type,
• required fields, expiry, and canonical location,
• whether contact routes are reachable,
• consistency across the main domain and relevant subdomains,
• redirects and external dependencies,
• the currency of policy and encryption information,
• ownership after agency or staff changes,
• intake, escalation, documentation, and closure of a controlled test case.

The goal is not a decorative best-practice file. The goal is a reliable route from “someone found something” to “we understood, prioritised, and fixed it properly.”

A vulnerability report is useful only when the organisation can receive and process it. security.txt shows people the door. The process behind it determines whether anyone answers.