Vulnerability disclosure policy
The public page that tells security researchers what they may test, where to report a hole, and how your team will respond.
See it
What it is
A vulnerability disclosure policy tells researchers where to send a security report, which systems they may test, what behavior is off-limits, what evidence you need, and what response they can expect. It is an open door, not necessarily a paid bug bounty. A security.txt file gives machines and humans a standard route to that policy and contact address.
Publish one as soon as your product is reachable from the internet. Put the human-readable policy somewhere stable, serve security.txt from '/.well-known/security.txt', route reports to a monitored mailbox or case system, and rehearse who acknowledges, triages, fixes, and replies.
The gotcha is publishing an address nobody owns. Silence pushes researchers toward public disclosure, while vague legal threats discourage the reports you wanted. Promise only response times you can meet, distinguish safe research from destructive testing, and remember that a policy is not permission to test third-party services you do not own.
Ask AI for it
Create a vulnerability disclosure policy and RFC 9116 security.txt for this product. Write exact in-scope assets, excluded third parties, allowed good-faith testing, prohibited destructive actions, privacy rules, report requirements, safe-harbor language, acknowledgement target, status-update cadence, and coordinated-disclosure process. Add SECURITY.md to the repo and serve '/.well-known/security.txt' with Contact, Expires, Canonical, Policy, and Preferred-Languages fields, using a monitored security email and an HTTPS policy URL. Validate the file against RFC 9116, assign an internal triage owner and backup, and add a calendar task to renew Expires before it lapses.