VDP vs bug bounty: building a safe disclosure program
Vulnerability disclosure and bug bounty programs differ. Design safe harbor, scope, triage, SLAs, rewards and a responsible launch process.
- AUTHOR
- Karol Rapacz / Penetration Tester (OSCP, PNPT)
- PUBLISHED
- 8 July 2026
- READING TIME
- 10 min read
- TOPIC
- AppSec
A Vulnerability Disclosure Program (VDP) and bug bounty both let researchers report flaws safely, but they are not identical. A VDP defines the channel, rules and protection for good-faith research. A bounty adds active testing and financial rewards for qualifying findings.
CISA BOD 20-01 explicitly distinguishes disclosure policy from a reward programme. Most organisations need a reliable VDP before they are operationally ready for a public bounty.
What a VDP should publish
- in-scope and excluded systems;
- permitted techniques and test limits;
- rules against accessing other people’s data or maintaining persistence;
- reporting channel and required evidence;
- secure transfer for sensitive material;
- acknowledgement and update timelines;
- coordinated-disclosure expectations;
- safe harbor for research following the policy.
/.well-known/security.txt makes the contact discoverable but does not replace the policy or triage team.
What bug bounty adds
A reward programme defines payout levels, qualifying classes, duplicate treatment, first-valid-report rules and tax conditions. It may be private for invited researchers or public.
Rewards should reflect demonstrated impact and evidence, not CVSS alone. Cross-tenant access, durable account takeover and RCE belong in different tiers from missing headers or self-XSS.
Build triage before launch
Do not invite public testing when reports enter an unattended inbox. Establish:
- a programme owner and backup;
- SLAs for acknowledgement, validation and updates;
- a safe reproduction environment;
- routing to product owners;
- duplicate and known-issue tracking;
- remediation and reward budgets;
- CVE assignment and customer communication where needed.
Make safe harbor specific
Researchers need to know which good-faith actions are authorised and when the organisation will not pursue legal action. Do not promise protection for supplier systems you do not own.
Exclude DoS, social engineering, physical access, mass scanning and unnecessary data extraction when the programme cannot safely support them. Avoid vague language that can be used to reject every meaningful finding after the fact.
Evaluating and communicating a report
A report should identify the asset, prerequisites, steps, evidence, impact and remediation idea. Triage verifies reproducibility, affected identities, data reach, automation potential and mitigating controls.
Communicate status even when remediation is slow. Silence pushes researchers towards public escalation. Retest the fix and coordinate publication language.
VDP or bounty?
Start with VDP when the reporting channel, team capacity or remediation process is immature. Move to a private bounty after triage stabilises. Launch publicly only when scope, budget and remediation scale with report volume.
VDP does not replace penetration testing, and bounty programmes do not guarantee systematic coverage. A strong programme combines a safe channel, scheduled assessments and an internal fix pipeline.
Safe harbor and report handling
The policy should state in-scope systems and techniques, prohibited actions, data handling and the organisation’s good-faith posture toward compliant research. Do not promise legal protection you cannot provide. The receiving team needs an encryption key, acknowledgement, triage and a channel for updating the researcher.
security.txt makes contact discoverable but does not replace the process. Test the mailbox and deadlines externally. Measure time to acknowledgement, triage, remediation and feedback; treat duplicates as evidence of a recurring defect class. A bounty is an addition to a VDP, not a condition for accepting reports.
Sources: CISA BOD 20-01, CISA CVD, RFC 9116.


