Security researchers discover vulnerabilities in company software every day. They test websites, APIs, mobile apps, open-source projects, cloud endpoints, and SaaS products. Some are professional researchers. Some are customers. Some are independent hobbyists. If they find a weakness in your systems, the next question is simple: how should they report it?
If your company does not have a clear vulnerability disclosure policy, researchers may not know who to contact, what information to include, what testing is allowed, or whether your company will treat them as helpful or hostile. That uncertainty creates risk for everyone.
A good policy gives researchers a safe, professional reporting path. It tells them what is in scope, what is out of scope, how quickly you will respond, and what behavior is allowed. It also helps your engineering and security teams receive better reports, fix vulnerabilities earlier, and avoid surprise public disclosure.
What Happens When Researchers Find Vulnerabilities Without a Policy
Many startups and growing companies assume they are too small to need a disclosure process. That assumption is dangerous. Security researchers and automated scanners do not only test large enterprises. They scan the internet, package registries, GitHub repositories, exposed APIs, cloud storage, login pages, and public assets at scale.
If a researcher finds a vulnerability and cannot find a reporting channel, several bad outcomes are possible. They may disclose the issue publicly to get attention. They may contact random employees on LinkedIn or Twitter. They may send details to a generic support inbox that never reaches engineering. They may sell the finding to a broker. Or they may simply give up, leaving your company unaware of the risk.
None of those outcomes is ideal. A disclosure policy does not make your software secure by itself, but it creates a controlled path for vulnerability reports. That path can be the difference between responsible remediation and public embarrassment.
For engineering teams, the practical benefit is clarity. When a valid report arrives, the team already knows where it goes, who triages it, what response time is expected, and how to communicate with the researcher.
What a Vulnerability Disclosure Policy Is (and Isn’t)
A vulnerability disclosure policy is a public document that explains how external researchers can report security vulnerabilities to your organization. It is sometimes called a responsible disclosure policy or coordinated vulnerability disclosure policy.
A VDP typically explains:
- How to report a vulnerability.
- Which systems, domains, APIs, apps, and services are in scope.
- Which activities are out of scope.
- What researchers should avoid, such as data access or service disruption.
- What your company commits to, such as response timelines and good-faith handling.
- Whether researchers may receive credit.
- Whether legal safe harbor applies to good-faith research.
A VDP is not the same as a bug bounty program. A bug bounty program pays researchers for valid findings. A VDP gives researchers a safe reporting process but does not necessarily include payment. Most small companies should start with a VDP before launching a paid bounty program.
A VDP is also not a replacement for secure development, dependency scanning, penetration testing, code review, or incident response. It is a communication and coordination mechanism. You still need internal processes to validate, prioritize, fix, and verify reported issues.
Writing Your VDP — Section by Section
A strong VDP does not need to be long. It needs to be clear. Researchers should quickly understand what they can test, how to report, and what behavior keeps them protected under your policy.
Scope
The scope section tells researchers which assets are covered. Be specific. If everything under your main domain is allowed, say that. If only certain products or APIs are in scope, list them.
Example scope:
- https://example.com
- https://app.example.com
- https://api.example.com
- Official mobile applications published by your company.
- Company-owned open-source repositories under your GitHub organization.
A clear scope protects both sides. Researchers know where testing is allowed, and your company avoids receiving reports about systems you do not own or cannot fix.
Out of Scope
The out-of-scope section is just as important. It prevents researchers from using harmful testing methods or reporting issues your team does not want handled through the VDP.
Common out-of-scope items include:
- Social engineering, phishing, or impersonation of employees or customers.
- Physical attacks against offices, devices, or employees.
- Denial-of-service testing or load testing.
- Spam, brute force, credential stuffing, or automated high-volume scanning.
- Accessing, modifying, deleting, or exfiltrating data that does not belong to the researcher.
- Third-party services, vendors, or infrastructure not controlled by your company.
- Reports without practical security impact.
Keep this section firm but respectful. The goal is to guide good-faith researchers, not scare them away.
Safe Harbor — Protecting Researchers Who Act in Good Faith
Safe harbor is one of the most important parts of a responsible disclosure policy. It tells researchers that your company will not pursue legal action against them for good-faith research that follows the policy.
This matters because security research can involve activities that look suspicious to automated systems: unusual requests, parameter testing, authentication checks, or controlled proof-of-concept testing. Without safe harbor, researchers may fear that reporting a vulnerability could expose them to legal risk.
A practical safe harbor clause should say that your company will not initiate legal action for research conducted in good faith, within scope, without privacy violations, without service disruption, and with prompt reporting. It should also require researchers to stop testing and notify you immediately if they accidentally access sensitive data.
This is not legal advice. Your legal team should review the final language, especially if you operate in regulated industries or multiple jurisdictions.
Your Commitments to Researchers
Researchers are more likely to report responsibly when they know what to expect. Your policy should include response commitments.
A good starting point is:
- First response: within 72 hours.
- Triage update: within 7 business days.
- Remediation updates: at reasonable intervals for valid reports.
- Credit: public recognition if the researcher wants it and disclosure is coordinated.
Do not promise timelines you cannot meet. If your team is small, it is better to commit to a realistic first response than to publish aggressive timelines you will miss.
How to Submit a Report
The submission section should be simple and direct. Include a dedicated email address such as security@example.com. If possible, provide a PGP key for encrypted reports. You can also include a web form, bug tracking portal, or vulnerability reporting platform.
Ask researchers to include:
- A clear description of the vulnerability.
- Steps to reproduce.
- Affected URL, endpoint, package, or component.
- Potential impact.
- Screenshots, logs, or proof-of-concept details where safe.
- Their preferred contact information.
- Whether they want public credit.
The easier you make reporting, the more likely you are to receive useful, actionable reports.
security.txt — Publishing Your VDP the Standard Way
security.txt is the standard way to publish vulnerability reporting information. RFC 9116 defines a machine-readable format that organizations can place at a known location to help researchers find disclosure contacts and policy information. The common location is:
https://example.com/.well-known/security.txt
RFC 9116 says the file is intended to help security researchers when disclosing vulnerabilities and defines a text format for organizations to publish disclosure information. :contentReference[oaicite:1]{index=1}
Here is a simple security.txt template:
Contact: mailto:security@example.com
Expires: 2027-12-31T23:59:59.000Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security
Acknowledgments: https://example.com/security/thanks
Use Contact to list the reporting email or URL. Use Policy to link to your full disclosure policy. Use Expires to show that the file is maintained. Use Canonical to point to the official location. If you publicly thank researchers, use Acknowledgments.
Adding security.txt is a low-effort, high-value signal. It tells researchers, scanners, and enterprise customers that your company has a real vulnerability reporting process.
VDP vs Bug Bounty — Which Should Your Company Start With?
A VDP and a bug bounty program are related, but they are not the same.
| Program Type | What It Does | Payment | Best For |
|---|---|---|---|
| VDP | Gives researchers a safe way to report vulnerabilities. | No payment required. | Startups, SaaS companies, growing engineering teams, and companies without a mature security program. |
| Bug bounty | Invites researchers to find and report vulnerabilities for rewards. | Paid rewards for valid findings. | Teams with mature triage, budget, legal review, and remediation capacity. |
Small companies should usually start with a VDP. A paid bug bounty can generate many reports quickly, including duplicates, low-impact findings, and edge cases. If your team cannot triage and fix reports consistently, a bounty program can create operational overload.
Start with a VDP, build internal triage and remediation processes, then consider a private bug bounty when your team is ready.
A VDP Template You Can Use Today
Use this template as a starting point. Ask your legal team to review it before publishing.
Vulnerability Disclosure Policy
Introduction
We take the security of our systems and users seriously. If you believe you have found a security vulnerability in our products or services, we encourage you to report it to us responsibly.
### Scope
The following systems are in scope:
- https://example.com
- https://app.example.com
- https://api.example.com
- Company-owned applications and services listed on this page
### Out of Scope
The following activities are not permitted:
- Social engineering, phishing, or impersonation
- Physical attacks
- Denial-of-service or load testing
- Accessing, modifying, deleting, or exfiltrating data that is not yours
- Testing third-party services we do not control
- Automated high-volume scanning that may disrupt service
Safe Harbor
We will not pursue legal action against researchers who act in good faith, follow this policy, avoid privacy violations, avoid service disruption, and promptly report vulnerabilities to us. If you accidentally access sensitive data, stop testing immediately and notify us.
Our Commitments
We will acknowledge valid reports within 72 hours.
We will investigate and triage reports as quickly as possible.
We will keep reporters informed of meaningful remediation progress.
We may provide public credit if the reporter requests it and disclosure is coordinated.
Researcher Commitments
Please avoid harming users, disrupting services, accessing data that does not belong to you, or publicly disclosing details before we have had time to investigate and remediate.
How to Submit
Email security@example.com with:
- Description of the vulnerability
- Steps to reproduce
- Affected URL, endpoint, package, or component
- Potential impact
- Screenshots or proof-of-concept details where safe
- Your contact information
- Whether you would like public credit
Disclosure
Please do not disclose the vulnerability publicly until we have completed investigation and remediation or agreed on a coordinated disclosure timeline.
This template gives researchers enough information to report safely while giving your company enough structure to respond professionally.
How Vulert Fits Into Your Security Process
A disclosure policy helps external researchers report vulnerabilities in your systems. But many vulnerabilities do not come from researchers. They come from open-source dependencies that receive new CVEs after you install them.
Vulert helps teams monitor open-source dependencies continuously. It analyzes manifest files and SBOMs to detect known vulnerabilities across direct and transitive dependencies. Vulert checks against 458,000+ CVEs and provides fix guidance, safe versions, and CLI commands where available.
This complements your VDP. A researcher may report an application bug through your policy, while Vulert alerts you when a dependency in your codebase becomes vulnerable. Together, they help you discover and fix issues before they become incidents.
Vulert supports files such as package-lock.json, yarn.lock, pom.xml, build.gradle, requirements.txt, composer.lock, go.sum, Gemfile.lock, Cargo.lock, pubspec.lock, mix.lock, *.csproj, packages.lock.json, and SBOM formats such as SPDX and CycloneDX.
Key Takeaways
- Researchers need a clear path: Without a policy, vulnerability reports may be delayed, misrouted, or publicly disclosed too early.
- A VDP is not a bug bounty: A VDP defines reporting rules; a bug bounty adds paid rewards.
- Scope matters: Clearly list which domains, APIs, apps, and services are covered.
- Safe harbor builds trust: Good-faith researchers are more likely to report responsibly when legal expectations are clear.
- security.txt improves discoverability: Publish reporting details at /.well-known/security.txt.
- VDP plus monitoring is stronger: External reports and continuous dependency scanning cover different parts of your security process.
Frequently Asked Questions
1. Is a vulnerability disclosure policy legally required?
In many cases, a VDP is not universally required by law, but it may be expected by enterprise customers, compliance programs, security frameworks, or industry-specific regulations. Some jurisdictions and product categories increasingly expect coordinated vulnerability disclosure processes. Ask legal counsel if you operate in a regulated market.
2. What is safe harbor in a VDP?
Safe harbor is language that says your company will not pursue legal action against researchers who act in good faith, stay within scope, avoid privacy violations, avoid service disruption, and report vulnerabilities responsibly.
3. How quickly must I respond to a vulnerability report?
A common first-response target is within 72 hours. You can set a different timeline, but it should be realistic and clearly published. Faster acknowledgment builds trust with researchers.
