In depth
Responsible disclosure (also called coordinated vulnerability disclosure, CVD) is the practice of reporting a security vulnerability privately to the affected vendor first, agreeing a remediation timeline, and only publishing technical detail once a fix is widely available — or, in cases where the vendor refuses to act, after a defined disclosure deadline expires. The model balances two competing interests: users deserve to know about vulnerabilities that affect them, and vendors need lead time to ship a fix before adversaries operationalise the issue. Modern frameworks are codified in ISO/IEC 29147:2018 (Vulnerability disclosure) and ISO/IEC 30111:2019 (Vulnerability handling processes), and elaborated in CERT/CC's CVD guidance.
The canonical workflow: researcher discovers a vulnerability, locates the vendor's security contact (security.txt at the well-known URL, /security page, security@vendor email, or a bug bounty platform), submits a detailed report with reproduction steps and impact analysis, the vendor acknowledges receipt within a published SLA (typically 72 hours), the parties agree a remediation timeline (typical 90 days, but adjustable for complex fixes), the vendor ships a fix, both parties coordinate the public advisory and CVE assignment. The 90-day clock is the Google Project Zero default and has become an industry norm; mature researchers extend it on request when good-faith progress is visible.
The hard cases are when the vendor does not respond, refuses to fix, or threatens the researcher with legal action. Strong safe-harbour language (CFAA-compliant, DMCA-compliant, anti-SLAPP-compliant) on the vendor's disclosure programme is the contractual mechanism that protects researchers and encourages them to report rather than to drop a zero-day. The disclose.io open-source framework provides ready-to-adopt safe-harbour clauses. Where the vendor is unresponsive, escalation paths include national CERTs (CISA, NCSC, CERT-In, JPCERT/CC), MITRE for CVE assignment, and ultimately public disclosure after the agreed deadline.
For organisations on the receiving side, a responsible disclosure programme is the lowest-cost security feedback loop available: friendly researchers report bugs you would otherwise pay a pentester or a bounty hunter to find. See the AxVeil responsible disclosure programme and the related explainer on bug bounty vs. pentest.
The canonical workflow: researcher discovers a vulnerability, locates the vendor's security contact (security.txt at the well-known URL, /security page, security@vendor email, or a bug bounty platform), submits a detailed report with reproduction steps and impact analysis, the vendor acknowledges receipt within a published SLA (typically 72 hours), the parties agree a remediation timeline (typical 90 days, but adjustable for complex fixes), the vendor ships a fix, both parties coordinate the public advisory and CVE assignment. The 90-day clock is the Google Project Zero default and has become an industry norm; mature researchers extend it on request when good-faith progress is visible.
The hard cases are when the vendor does not respond, refuses to fix, or threatens the researcher with legal action. Strong safe-harbour language (CFAA-compliant, DMCA-compliant, anti-SLAPP-compliant) on the vendor's disclosure programme is the contractual mechanism that protects researchers and encourages them to report rather than to drop a zero-day. The disclose.io open-source framework provides ready-to-adopt safe-harbour clauses. Where the vendor is unresponsive, escalation paths include national CERTs (CISA, NCSC, CERT-In, JPCERT/CC), MITRE for CVE assignment, and ultimately public disclosure after the agreed deadline.
For organisations on the receiving side, a responsible disclosure programme is the lowest-cost security feedback loop available: friendly researchers report bugs you would otherwise pay a pentester or a bounty hunter to find. See the AxVeil responsible disclosure programme and the related explainer on bug bounty vs. pentest.