SaaS vulnerability disclosure policy and security.txt guide
Create a clear SaaS vulnerability disclosure policy, safe reporting channel, triage workflow, and RFC 9116 security.txt file for researchers.
In this guide
What is a vulnerability disclosure policy, and what does security.txt do?
A vulnerability disclosure policy (VDP) tells security researchers which systems are in scope, how to report a suspected product vulnerability, what testing is permitted and how the company coordinates a fix. It is a documented intake and response process, not necessarily a paid bug bounty. RFC 9116 defines the machine-readable security.txt file as a way to publish contact and policy details; the file points to the program but does not replace it or authorize testing by itself.
Separate product vulnerability reports from incident-response requests
A researcher may report a flaw in your product, while a customer may need urgent help with an active compromise or account incident. Publish a route for each and make sure on-call staff can recognize the difference. RFC 9116 explicitly treats vulnerability response and incident response as related but distinct processes.
State the assets, methods and limits that your team can support
List product domains, applications, APIs or other assets that you own or are authorized to include. Explain excluded third-party services, prohibited actions that could affect real users or availability, and how researchers can request clarification. Review the scope with legal, engineering and operations before publication.
Use a clear good-faith policy reviewed for your jurisdiction
Describe how the company intends to handle research conducted within the policy, and set boundaries that staff can actually honor. Do not promise blanket immunity from laws or claims, or offer a safe-harbor statement copied from a government template without counsel review. CISA's template is written for federal agencies; private SaaS companies should adapt it to their systems and legal context.
| In-scope asset | Allowed testing and limit | Report channel and backup | Triage owner and coverage | Customer or public update trigger |
|---|---|---|---|---|
| Public product and API | ||||
| Mobile app or client software | ||||
| Third-party hosted service |
What should a SaaS vulnerability disclosure policy include?
Publish practical scope and reporting instructions
Tell researchers what asset identifiers to include, which security contact to use, what information helps reproduce a finding and how to protect customer data. Invite minimal proof of concept and discourage destructive tests, social engineering, denial of service or access to data that is not theirs.
Set an intake and acknowledgement process that has an owner
Route submissions into a monitored queue with backups for leave and staff changes. Acknowledge receipt when possible, record when the report arrived, request only the information needed, and avoid demanding a particular severity score before investigating. Publish response targets only if the team can staff and measure them.
Explain coordinated remediation and recognition
Triage impact and affected versions, reproduce safely, assign a fix owner and coordinate customer or public communication. Explain how a researcher may ask about status or receive credit, while withholding details that could enable attacks before users can update. A VDP does not require paying a bounty; state reward terms separately if offered.
How do you publish and maintain a security.txt file?
Serve the file at the RFC 9116 well-known path
Publish a UTF-8 plain-text file at `/.well-known/security.txt` over HTTPS, with one field per line. RFC 9116 requires a Contact field and an Expires field; the expiry should be kept current so researchers can tell whether the information is stale. Validate the file after deployment and on every production domain in scope.
Point to the full policy and use language and encryption fields correctly
A Policy field can link to the complete VDP, and Preferred-Languages can tell researchers which languages your team can handle. If you publish an Encryption field, it points to a location where a key can be retrieved; RFC 9116 says not to put the key itself in that field. Keep contact endpoints monitored and protected against takeover.
Test for expiry, domain coverage and stale ownership
Add reminders before expiry, verify redirects and TLS, and confirm the listed mailbox or form still reaches a trained owner. Review the policy after acquisitions, domain changes, new product surfaces and support-process changes. Security.txt improves discoverability; it does not prove that a company operates a complete response program.
Vulnerability disclosure and security.txt questions
Does publishing security.txt give researchers permission to test?
No. RFC 9116 says the file is for disclosure information and does not itself imply permission to test. The policy must state its actual scope and terms, and researchers must follow them.
Is a vulnerability disclosure policy the same as a bug bounty?
No. A VDP provides a defined reporting and response path. A bug bounty is a separate program that offers rewards under specified eligibility and payment rules; a company can have either or both.
Does a VDP replace incident response?
No. Vulnerability reports about a product flaw and reports of an active intrusion need coordinated but distinct workflows. Publish a clear route for urgent incidents and make sure both channels reach responsible staff.
What fields must security.txt contain?
RFC 9116 requires Contact and Expires. Other fields, including Policy and Preferred-Languages, can add useful details. Follow the RFC format and keep the file's contact, links and expiry current.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- CISA Vulnerability Disclosure Policy TemplateCybersecurity and Infrastructure Security Agency
- IETF RFC 9116: A File Format to Aid in Security Vulnerability DisclosureInternet Engineering Task Force