Every piece of software has vulnerabilities. The question is not whether external researchers will find them — they will. The question is what happens next. A vulnerability disclosure program (VDP) gives researchers a clear, safe channel to report what they find. Without one, your vulnerabilities get disclosed on Twitter, sold to exploit brokers, or silently exploited.
Why You Need a VDP
In 2021, CISA issued Binding Operational Directive 20-01, requiring all federal civilian agencies to maintain a vulnerability disclosure policy. This was not bureaucratic overreach — it was recognition that external researchers are a critical part of the security ecosystem.
The math is simple: your security team, no matter how talented, cannot find every bug. External researchers bring different perspectives, different tools, and different motivations. A VDP harnesses that energy productively.
Organizations without VDPs face real consequences:
- Researchers go public. Without a reporting channel, researchers often disclose vulnerabilities publicly, sometimes with zero-day exploits. This is not malice — they simply have no alternative.
- Researchers face legal risk. Without a safe harbor policy, researchers who find vulnerabilities in your systems may fear prosecution under the CFAA (Computer Fraud and Abuse Act). This discourages reporting.
- You miss critical intelligence. Vulnerabilities that go unreported are vulnerabilities that get exploited.
Anatomy of a Good VDP
Clear Scope
Define exactly what is in scope and what is not. Researchers should not have to guess whether your production API, staging environment, or mobile app is fair game.
## In Scope
- *.example.com (production web applications)
- api.example.com
- Example iOS and Android applications
## Out of Scope
- Physical security
- Social engineering of employees
- Third-party services (e.g., our support ticket system)
- Denial of service testing
Safe Harbor Language
This is the most important part of your VDP. Researchers need legal assurance that reporting a vulnerability will not result in prosecution, a cease-and-desist letter, or account termination.
Good safe harbor language:
We consider security research conducted under this policy to be:
- Authorized under the Computer Fraud and Abuse Act (CFAA)
- Authorized under the Digital Millennium Copyright Act (DMCA)
- Exempt from restrictions in our Terms of Service
We will not initiate legal action against researchers who:
- Make a good faith effort to avoid privacy violations
- Do not exploit vulnerabilities beyond what is necessary to demonstrate the issue
- Report findings promptly through our designated channel
Reasonable Response Times
Commit to specific response timelines:
- Acknowledgment: Within 2 business days
- Triage: Within 5 business days
- Status update: At least every 14 days
- Resolution target: 90 days for critical issues
If you commit to these timelines, honor them. Nothing alienates researchers faster than submitting a critical vulnerability and hearing nothing for three weeks.
Reporting Channel
Make reporting easy. At minimum, provide a security@yourdomain.com email address. Better options include:
- A dedicated web form on your security page
- Integration with platforms like HackerOne, Bugcrowd, or Intigriti
- A security.txt file at
/.well-known/security.txt(RFC 9116)
# /.well-known/security.txt
Contact: security@example.com
Encryption: https://example.com/pgp-key.asc
Preferred-Languages: en
Policy: https://example.com/security-policy
Expires: 2023-01-01T00:00:00.000Z
VDP vs. Bug Bounty
A VDP and a bug bounty program are not the same thing.
VDP: "Please report vulnerabilities to us. We will acknowledge your contribution and fix the issue." No monetary reward is required, though recognition and swag are common.
Bug bounty: "Please report vulnerabilities to us. We will pay you based on severity." Monetary rewards range from $50 for low-severity issues to $100,000+ for critical vulnerabilities at major tech companies.
Start with a VDP. You do not need a bug bounty program to get value from external researchers. Many researchers report vulnerabilities simply because they want to help, they want recognition, or they want to build their reputation.
If your VDP is successful and you want to attract more researchers, consider adding monetary rewards. But a VDP with good safe harbor and responsive communication will attract more researchers than a bug bounty with poor communication.
Common Mistakes
Not Having a VDP at All
The most common mistake. If a researcher cannot find your security contact information within 60 seconds, you have a problem.
Threatening Researchers
In 2022, multiple companies still responded to vulnerability reports with legal threats. This is counterproductive. Word travels fast in the security research community, and threatening one researcher ensures that the next researcher will not bother reporting.
Ignoring Reports
Acknowledging a report and then going silent is almost worse than not having a VDP. Researchers invest significant time in finding and documenting vulnerabilities. Respect that investment with timely communication.
Overly Narrow Scope
If your VDP only covers a single subdomain that nobody uses, researchers will not bother. Cover your primary attack surface.
No Feedback Loop to Engineering
A VDP that results in vulnerability reports sitting in an inbox without action is theater. Ensure that reports flow into your bug tracking system with appropriate prioritization.
Measuring VDP Effectiveness
Track these metrics:
- Reports received per month — is your program attracting researchers?
- Time to first response — are you meeting your SLA?
- Time to triage — how quickly do reports get assessed?
- Time to resolution — how quickly are confirmed vulnerabilities fixed?
- Researcher satisfaction — are researchers submitting multiple reports? (repeat reporters indicate trust)
- Unique valid vulnerabilities — is the program finding real issues?
How Safeguard.sh Helps
Safeguard.sh integrates vulnerability disclosure workflows into your supply chain security posture. When external researchers report vulnerabilities in components you use, our platform correlates those reports with your SBOM data to determine impact across your application portfolio. Safeguard.sh also tracks the remediation lifecycle, ensuring that disclosed vulnerabilities are patched within your organization's SLA and that fixes are verified before closure.