Publish a Security Reporting Policy
Give researchers a clear private contact route, scope, response expectations, and a machine-readable security.txt file.
A public reporting policy lets someone tell you about a possible vulnerability without guessing at a sales inbox. It should identify a monitored private contact and set expectations that your team can meet. RFC 9116 defines a security.txt format and location. The file is a contact aid, not permission to scan systems or access data.
Publish the contact contract
| Field | Decision to record |
|---|---|
| Contact | Monitored mailbox or secure form |
| Scope | Products, domains, and excluded assets |
| Evidence | Safe details to include without customer data |
| Response | Receipt target and update cadence |
| Disclosure | Coordination process and preferred timing |
| Owner | Team that handles and backs up the inbox |
Write the human-readable policy first. State what behavior is in scope, what tests are prohibited, and how to report an urgent issue. Do not promise a bounty, legal safe harbor, or response time that has not been approved. Add a path for encrypted reports only if the key is current and the team can use it. Do not ask researchers to send credentials or live customer records.
Check the public file and workflow
Place security.txt at /.well-known/security.txt. This is a fictional minimal file, not a live contact:
Contact: mailto:security@example.com
Expires: 2027-01-31T00:00:00Z
Replace both values with a monitored address and a future RFC 3339 expiry for the real domain. Serve the file over HTTPS as plain text. Assign a renewal owner before the expiry date. Send an internal test message and confirm that the primary and backup intake path receive it. A Contact field does not authorize testing.
Create an internal case template with receipt date, product, affected version, reproducible steps, impact, severity assessment, owner, and next update date. Acknowledge reports without promising a fix before triage. Preserve private evidence with access limits. Review the policy after product or domain changes. The public policy should reduce uncertainty for reporters while keeping the team's actual response process honest.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.