A report-a-vulnerability section should give a working contact, link a disclosure policy, say what researchers can expect, and say what you ask of them. Back it with a security.txt file that names the same contact and an expiry date. Test the contact regularly.
Start with the file
RFC 9116 defines security.txt, a machine-parsable format that helps organizations describe their vulnerability disclosure practices so researchers can report problems more easily. The file is served from a well-known path on your site, over HTTPS. Two fields are required: Contact, which says how to report, and Expires, which says when the data goes stale.
The RFC also defines optional fields that map well to a trust page section.
| Field | Use on the page |
|---|---|
| Contact | The address or form to report to |
| Expires | A review date for the contact data |
| Policy | Link to the disclosure policy |
| Encryption | Key for encrypted reports |
| Preferred-Languages | Languages you can handle |
| Canonical | Where the file is meant to live |
| Hiring | Link to security roles, if you wish |
The RFC recommends signing the file with an OpenPGP cleartext signature, and using Canonical alongside it, so the signature authenticates the file's location.
What the page section should say
- Where to report. The same contact as in the file.
- What is in scope. Products, domains, and issue types.
- What is out of scope. Social engineering, denial of service, third-party services you do not control.
- What you will do. Acknowledge within a stated time, keep the reporter updated, and aim to fix.
- What you ask. Give reasonable time to fix, avoid accessing customer data, and do not publicize before coordination.
- Credit. Whether you will name reporters and how.
Write promises you can keep. If you cannot acknowledge in two days, do not say you will.
Keep it live
The RFC says not having a security.txt file may be preferable to having stale information, because reports can go to the wrong place. It also says to keep contact methods current, accessible, controlled by your organization, and secure. In practice:
- Use a role address, not a person's address.
- Make sure more than one person reads it.
- Send a test report each quarter and time the response.
- Set the Expires date to match your review rhythm, and put a reminder on the calendar.
Handle what arrives
Plan the path before the first report. Who triages? Who decides severity? Who talks to the reporter? Who decides on a fix and a notice? Keep a short runbook and practice it once. When a fix ships, publish an advisory with the status words customers understand, as covered in the post on status words for a vulnerability notice.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow a finding from discovery to closure. A reported vulnerability needs the same path.
Where Safeguard fits
Safeguard's autonomous remediation can open fix pull requests for dependency issues. It is off by default, and every category starts on Manual. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is security.txt mandatory?
No. RFC 9116 is informational. It is a helpful, widely understood way to publish your contact, but only if you keep it current.
Should the contact be a person or a role?
A role address read by several people, so reports are not lost when someone is away or leaves.
Sources
Last reviewed: 19 October 2026.
