Updated June 14, 20265 min read
Vulnerability Disclosure and security.txt for Company Websites
A practical security.txt and vulnerability disclosure workflow for small companies that want a credible security contact path.
Key Points
- security.txt gives researchers a predictable place to find a security contact.
- The mailbox behind that contact must be monitored and routed internally.
- A public policy reduces confusion before an incident happens.
What security.txt solves
Researchers and customers should not have to guess whether security issues belong in a contact form, a support inbox, or a social media message. A security.txt file creates a standard path for reporting vulnerabilities.
The file is small, but it signals operational maturity when it includes a real contact, canonical URL, policy URL, and preferred language.
Minimum practical setup
- Publish /.well-known/security.txt on the canonical domain.
- Use a monitored security mailbox, such as security@example.com.
- Link to a vulnerability disclosure policy or security page.
- Make sure support and contact teams know where to forward security reports.
Response workflow
The website is only the entry point. A company-grade setup also needs a response owner, severity triage, evidence capture, fix tracking, and a short communication template for acknowledging valid reports.
Common mistakes
- Publishing a security mailbox that nobody monitors.
- Using a personal email address instead of a company alias.
- Forgetting to update the canonical URL after a domain migration.
- Treating disclosure handling as a legal page only instead of an operational workflow.