Security researchers discover vulnerabilities in software every day. What happens next — how that information travels from the researcher to the vendor to the public — has significant consequences for the organizations running that software. A well-structured vulnerability disclosure program (VDP) or bug bounty program creates a legal, structured channel for researchers to report findings, ensures vendors receive actionable information with time to remediate before public disclosure, and reduces the probability that vulnerabilities are instead sold to brokers or disclosed immediately on full-disclosure mailing lists.
This post covers the disclosure landscape, legal frameworks, program structure, platform options, and compliance requirements — written for security-conscious organizations considering whether to establish a program.
The Disclosure Landscape
Three models govern how vulnerability information flows:
Coordinated Vulnerability Disclosure (CVD)
CVD (also called responsible disclosure) is the industry standard. The researcher reports the vulnerability privately to the vendor, the vendor is given a defined remediation period (industry norm: 90 days, established by Google Project Zero), and the vulnerability is disclosed publicly after the patch is available or the deadline expires. CVD serves the public interest: users receive patches before attackers can exploit disclosed vulnerabilities, and researchers receive attribution. CISA operates a CVD program for critical infrastructure and government systems.
Full Disclosure
The researcher publicly discloses the vulnerability without prior notification to the vendor. This approach maximizes pressure on vendors to remediate quickly but exposes users to exploitation before patches are available. The Full Disclosure mailing list (seclists.org) and Exploit-DB are common publication venues. Full disclosure is generally considered hostile to vendors but has legitimate use when vendors are unresponsive after reasonable notification attempts.
Bug Bounty Programs
Bug bounties add financial incentives to the CVD model. Researchers receive monetary rewards for qualifying findings, creating a market for vulnerability research directed at specific targets. Rewards align researcher attention to the vendor's priority targets and provide compensation commensurate with finding severity.
Legal Frameworks: Safe Harbor and the CFAA
The Computer Fraud and Abuse Act (CFAA), 18 U.S.C. § 1030, criminalizes unauthorized access to computer systems. Security researchers face genuine legal exposure when testing systems without explicit authorization — even with benign intent. High-profile CFAA prosecutions (Aaron Swartz, Weev) and threats against researchers have created a chilling effect on legitimate security research.
A well-drafted VDP policy provides safe harbor language — a contractual commitment from the organization not to pursue civil or criminal action against researchers who operate within the program's defined scope and rules. Essential elements of safe harbor language:
- Explicit statement that the organization authorizes testing of in-scope systems under defined conditions
- Commitment not to initiate or support legal action against researchers acting in good faith within scope
- Acknowledgment that testing within scope constitutes authorized access under the CFAA
- Clear definition of what constitutes good-faith behavior (no data exfiltration beyond proof-of-concept, no DoS, no social engineering of employees)
The Department of Justice issued guidance in 2022 indicating it will not prosecute good-faith security research, but a formal safe harbor in your VDP policy provides stronger protection for researchers and signals your organization's intent to the research community.
security.txt: The RFC 9116 Standard
Before researchers can report vulnerabilities, they need to know how to reach your security team. RFC 9116 defines the security.txt standard — a plain-text file at /.well-known/security.txt that specifies your disclosure contact, policy URL, encryption key, acknowledgment URL, and preferred language. This is the first thing a responsible researcher will look for. If your organization does not have a security.txt, researchers may resort to LinkedIn DMs, generic contact forms, or public disclosure out of frustration.
Minimum required fields per RFC 9116: Contact: (email or web form URL) and Expires: (date after which the file should be considered stale). Strongly recommended: Policy: (link to full VDP policy), Encryption: (PGP key for encrypted reports), Acknowledgments: (hall of fame URL).
Program Scope Definition
Scope definition is the most operationally important element of a disclosure program. Poorly defined scope leads to researcher frustration (testing systems you did not intend), legal ambiguity, and wasted triage time on out-of-scope findings.
In-scope assets should be explicitly listed: specific domains, IP ranges, mobile application package IDs, API endpoints. Wildcard scope (*.yourdomain.com) maximizes coverage but requires sufficient triage resources to handle the corresponding report volume.
Out-of-scope findings should be enumerated: denial of service attacks, social engineering of employees, physical security testing, findings in third-party systems not under your control, volumetric resource exhaustion, findings requiring unlikely user interaction.
Prohibited test types must be explicit: no production data exfiltration (provide test accounts), no automated scanning without prior approval, no findings disclosure before remediation.
Response SLAs
Response SLAs set expectations for researchers and create internal accountability:
- Acknowledge receipt: Within 24 hours. A researcher who receives no response may assume the report was lost and begin considering public disclosure.
- Triage and validity determination: Within 7 days. Confirm whether the finding is valid, in scope, and new (not a duplicate).
- Remediation: Within 90 days for valid findings. Communicate status updates at 30-day intervals if remediation will take longer. Negotiate extensions proactively with researchers rather than going silent.
- Disclosure coordination: After remediation, coordinate with the researcher on public disclosure timing. Offer co-disclosure credit.
Bug Bounty Platforms
Running a bug bounty program in-house requires significant triage resources — filtering duplicates, assessing severity, managing researcher communication. Bug bounty platforms provide managed triage, researcher communities, payment processing, and dispute resolution:
- HackerOne: Largest researcher community (over 2 million registered security researchers, per HackerOne's platform/community page, hackerone.com/platform/community, 2026). Offers managed triage (HackerOne Response), program management, and CVE coordination. Pricing: platform fees plus bounty payments. Used by Uber, Spotify, Goldman Sachs, the U.S. Department of Defense.
- Bugcrowd: Strong in financial services and healthcare verticals. Offers Crowdcontrol (self-managed), managed programs, and penetration testing-as-a-service integration. Competitive pricing for mid-market organizations.
- Intigriti: European-based platform with strong EU researcher community. GDPR-compliant infrastructure. Good choice for organizations with EU operations.
- Federacy: Designed for startups and mid-market, lower cost than HackerOne/Bugcrowd, no platform fees for basic VDP programs.
Reward Structures
Bounty amounts should reflect finding severity and your organization's risk appetite. Most programs set reward bands tied to a severity taxonomy — typically CVSS ranges or a platform's own priority scale (for example, Bugcrowd's P1–P4 Vulnerability Rating Taxonomy) — rather than any single industry-wide dollar table:
- Critical (authentication bypass, remote code execution on production systems): your highest-value tier, the payouts that attract serious researchers to hard targets
- High (significant data exposure, privilege escalation): substantial rewards below the critical band
- Medium (limited data exposure, CSRF, stored XSS): moderate rewards
- Low (information disclosure, minor misconfigurations): nominal rewards or recognition only
Set the actual figures against your own risk appetite and budget, and benchmark them against published platform data (HackerOne and Bugcrowd both report payout statistics) rather than a fixed cross-industry table.
Compliance Requirements
NYDFS 23 NYCRR 500 Section 500.16 requires covered entities to have a disclosed vulnerability disclosure policy. PCI DSS v4.0 Requirement 6.3.1 requires an inventory of all in-scope software components and a process to manage known vulnerabilities. A formal VDP addresses both requirements. Establishing a VDP also demonstrates due diligence under SEC cybersecurity disclosure rules for public companies.
Fortress MSSP assists organizations in establishing VDP policies, implementing security.txt, and evaluating bug bounty platform options. For guidance on disclosure program structure and safe harbor language review, contact our team. Learn more about our security posture services at our about page.