Coordinated Vulnerability Disclosure (CVD): what it is and how to implement it in your company
By Kike Gandia · Co-Founder & CEO, OSCP
Coordinated Vulnerability Disclosure (CVD), also known as responsible disclosure, is the process by which a security researcher who discovers a vulnerability reports it to the affected party before publishing it, and both sides coordinate the timeline for public disclosure. The international standard defining this process is ISO/IEC 29147.
Why CVD is preferable to full disclosure
Full disclosure means publishing the vulnerability immediately, without prior coordination with the affected party. For the researcher, it maximizes the impact of their finding. For the company, it's devastating: the vulnerability becomes public before a patch is available, which maximizes the window for exploitation.
CVD offers a balance: the researcher gets credit for the finding and the company gets time to patch before publication. The outcome is better for everyone: the researcher builds reputation, the company fixes the issue, and the security community gets the information once the risk has been mitigated.
Phases of the CVD process under ISO 29147
ISO 29147 defines the CVD process in the following phases:
1. Report receipt: the researcher notifies the affected party of the vulnerability through the channel defined in the VDP.
2. Acknowledgment: the affected party confirms receipt and assigns an identifier to the report.
3. Technical validation: the affected party verifies the vulnerability is real.
4. Resolution: the patch is developed and deployed.
5. Disclosure timeline coordination: the researcher and the company agree on a public disclosure date.
6. Publication: information about the vulnerability is published (CVE, advisory, researcher blog post).
The industry standard timeframe is 90 days from notification to publication, though it can vary depending on the complexity of the fix.
What to do when the researcher wants to publish before the patch
If the researcher insists on publishing before the patch is available, you have several options:
- Communicate the real status: explain why the patch is taking longer and propose a new disclosure date.
- Publish your own advisory: if the vulnerability is going to be published anyway, it's better for you to control the narrative with your own advisory that acknowledges the finding.
- Notify the CERTs: if the vulnerability is severe, notifying INCIBE-CERT or ENISA can help manage disclosure in a more orderly way.
What you should never do: legally threaten a researcher acting in good faith within the rules of your VDP. It destroys the program's reputation and discourages responsible disclosure.
CVE: when and how to request an identifier
If the reported vulnerability affects software you distribute or maintain, you should request a CVE (Common Vulnerabilities and Exposures). A CVE is a unique identifier that lets the community reference the vulnerability unambiguously.
You can request a CVE through:
• The MITRE CVE Program: cve.org
• CNAs (CVE Numbering Authorities): if you're a software vendor, you can become a CNA and issue your own CVEs.
• INCIBE-CERT acts as a CNA for vulnerabilities in Spanish products.
Publishing a CVE with credit to the researcher is a form of recognition highly valued in the community.
FAQ
How much time do I have to patch before the researcher publishes?
The industry standard is 90 days. Google Project Zero popularized this timeframe, which later became an industry reference. Some organizations use 60 or 120 days. What matters is that the timeframe is set in your disclosure policy before the first report ever arrives.
What if the vulnerability affects a third-party vendor rather than my own software?
If the vulnerability is in third-party software or infrastructure, your responsibility is to notify the affected vendor and coordinate with them. You can act as an intermediary between the researcher and the vendor, or forward the report directly to the relevant CERT if the vendor has no VDP.
What is a "safe harbor" in the context of a VDP?
Safe harbor is the clause in your VDP policy stating that you won't take legal action against researchers who discover and report vulnerabilities while acting within the program's rules. It's a fundamental element for building trust with the research community.
Related service
VDP and CVD management service