Bug-bounty or responsible-disclosure channel
Demonstrate that the organization maintains an accessible, documented, and monitored channel for external security researchers to report vulnerabilities responsibly, with evidence of active triage and response processes.
Description
What this control does
A bug-bounty or responsible-disclosure channel provides external security researchers with a documented, safe method to report vulnerabilities in the organization's systems, applications, or services without fear of legal retaliation. This typically includes a public security.txt file, a dedicated email address or web form, clear scope definitions, and a commitment to respond within defined timeframes. The channel reduces the window of exposure for zero-day vulnerabilities and demonstrates organizational maturity in crowdsourced security testing.
Control objective
What auditing this proves
Demonstrate that the organization maintains an accessible, documented, and monitored channel for external security researchers to report vulnerabilities responsibly, with evidence of active triage and response processes.
Associated risks
Risks this control addresses
- External researchers discover vulnerabilities but withhold or publicly disclose them because no safe reporting mechanism exists, leading to exploitation by threat actors
- Security findings are reported to generic contact channels (marketing, support) where they are ignored, misrouted, or delayed, extending the window of exploitability
- Legal threats or unclear safe-harbor language deter researchers from reporting vulnerabilities, causing critical flaws to remain unreported
- Lack of scope definition leads researchers to test production systems inappropriately, causing service disruptions or compliance violations
- Duplicate or low-quality submissions overwhelm security teams without triage process, causing legitimate critical findings to be deprioritized or missed
- Absence of acknowledgment or feedback loops discourages repeat reporting, reducing the volume and quality of community-driven vulnerability intelligence
- Undisclosed vulnerabilities reach dark-web forums or exploit marketplaces before internal teams become aware, enabling targeted attacks against the organization
Testing procedure
How an auditor verifies this control
- Identify the organization's published responsible disclosure or bug-bounty channel by checking /.well-known/security.txt, /security.txt, main website security pages, and HackerOne, Bugcrowd, or similar platform profiles.
- Review the disclosure policy documentation for completeness: in-scope assets, out-of-scope systems, safe-harbor language, prohibited testing activities, expected response timeframes, and contact method (PGP key if email-based).
- Verify DNS and HTTPS configuration for security.txt or disclosure page ensures accessibility and authenticity (valid certificate, no broken links, current PGP key if provided).
- Interview the security operations or product security team to confirm ownership, monitoring frequency, escalation procedures, and SLA for initial acknowledgment and triage.
- Sample three to five recent vulnerability submissions (last 6-12 months) and trace each through intake, triage, remediation, and researcher communication to validate the process functions as documented.
- Examine the ticketing or case-management system (Jira, ServiceNow, bug-bounty platform) to confirm unique queue or workflow exists for vulnerability disclosures separate from general support requests.
- Test the disclosure channel by submitting a benign test report (with prior authorization) or simulate researcher contact to verify acknowledgment is received within the published SLA.
- Review legal and communications guidance provided to the security team to confirm safe-harbor protections are understood and researchers are not subjected to threatening or adversarial responses.
Where this control is tested