Security.txt and a Vulnerability Disclosure Policy

When a researcher finds a flaw in your website, they need to know how to tell you. A vulnerability disclosure policy and a security.txt file provide that clear path. This guide explains both and how to set them up.

What a disclosure policy is

A vulnerability disclosure policy tells outsiders how to report security issues, what is in scope, and how you will respond. It sets expectations on timelines and promises not to pursue good-faith researchers. Clear rules turn potential conflict into helpful cooperation.

What security.txt does

Security.txt is a small text file placed at the well-known location on your website that lists contact details, preferred languages, encryption keys, and a link to your policy. It gives researchers a standard place to look, reducing the chance a report gets lost.

Writing the policy

Define the systems covered, the types of testing allowed and forbidden, how to submit reports, and how long you will take to acknowledge and fix issues. Include safe harbor language and make clear that no data should be accessed beyond what is needed to demonstrate the issue.

Handling reports

Assign an owner, monitor the reporting mailbox, acknowledge quickly, and track each issue to resolution. Communicate progress and, with permission, credit the researcher. Feed lessons into your development process.

Maintaining the setup

Update contacts when staff change, keep the expiry date in security.txt current, and test that the address works. Review the policy annually.

Key takeaways

• What a disclosure policy is: A vulnerability disclosure policy tells outsiders how to report security issues, what is in scope, and how you will respond. It sets expectations on timelines and promises not to pursue good-faith researchers.
• What security.txt does: Security.txt is a small text file placed at the well-known location on your website that lists contact details, preferred languages, encryption keys, and a link to your policy. It gives researchers a standard place to look, reducing the chance a report gets lost.
• Writing the policy: Define the systems covered, the types of testing allowed and forbidden, how to submit reports, and how long you will take to acknowledge and fix issues. Include safe harbor language and make clear that no data should be accessed beyond what is needed to demonstrate the issue.
• Handling reports: Assign an owner, monitor the reporting mailbox, acknowledge quickly, and track each issue to resolution. Communicate progress and, with permission, credit the researcher.
• Maintaining the setup: Update contacts when staff change, keep the expiry date in security.txt current, and test that the address works. Review the policy annually.

Putting it into practice

To apply this in your own organization, begin with a short assessment of where you stand on vulnerability disclosure policy today. Write down who owns it, which tools are involved, and the single biggest gap. Fix the highest-risk gap first, assign a clear date, and review progress after thirty days. Share what you learn with the team so improvements stick, and document the decisions you make so new staff can follow them. Revisit the topic every quarter, because threats, tools, and business needs change quickly, and small regular adjustments are far easier than large emergency fixes.

Frequently asked questions

Do small companies need this?

Yes. Any public website can receive reports, and a simple policy avoids confusion.

Is a bug bounty required?

No. A disclosure policy works without monetary rewards.

Final thoughts

A disclosure policy and security.txt file are inexpensive ways to make reports easy. Publish them, monitor the inbox, and respond promptly.