Coordinating Vulnerability Disclosure (CVD) is a process where finders of security vulnerabilities report them to affected vendors or coordinators so that fixes can be developed and deployed before details are made public. This document covers the protocol in detail, the process to follow, and practical examples.

---

What is Coordinating Vulnerability Disclosure (CVD)?

Definition

CVD is a structured, time-bound process in which:

1. A reporter (researcher, user, or automated system) discovers a potential vulnerability.
2. The reporter privately notifies the affected vendor or a designated coordinator.
3. The vendor (or coordinator) validates, prioritizes, and develops a fix.
4. All parties coordinate on timing of patches and public disclosure.
5. Public disclosure happens after a fix (or mitigation) is available, reducing harm to users.

CVD is sometimes called responsible disclosure or coordinated disclosure. It sits between full secrecy (no disclosure) and immediate full disclosure (publishing without giving the vendor time to fix).

Why CVD matters

Stakeholder	Benefit
Users	Get patches before attackers learn about the bug; less exposure.
Vendors	Time to fix and ship updates; avoid surprise public disclosure.
Reporters	Clear process, recognition, and (often) safe-harbour or reward programs.
Ecosystem	Fewer 0-days in the wild; better trust and collaboration.

Key principles

• Confidentiality: Details stay private until an agreed disclosure date (or until a fix is available).
• Good faith: Reporters avoid weaponising the bug; vendors respond seriously and on time.
• Coordination: Timing of patches, advisories, and public reports is agreed in advance.
• Credit: Reporters are acknowledged (unless they prefer anonymity).

---

CVD protocol: main components

1. Scope and expectations

Before or at the start of the process, parties should align on:

• In-scope: Which products, versions, and vulnerability types are covered.
• Out-of-scope: Known issues, duplicate reports, purely theoretical issues without impact.
• Timelines: How long the vendor has to respond, validate, and release a fix; when disclosure can occur.
• Communication: Preferred channel (encrypted email, portal, PGP), who is the point of contact, and how often to sync.
• Recognition: Whether the reporter will be credited and in what form (e.g. advisory, Hall of Fame).

2. Roles

Role	Responsibility
Reporter / Finder	Discovers the issue, reports privately, avoids public disclosure until agreed.
Vendor / Maintainer	Validates the report, develops and releases a fix, coordinates disclosure.
Coordinator	Optional third party (e.g. CERT, vendor program) that receives reports and facilitates between reporter and vendor.
Downstream / Deployers	Apply patches and mitigations; may need early notification under embargo.

3. Typical timeline (example)

A common approach is 90–120 days from initial report to public disclosure, with flexibility for complexity:

• Day 0: Reporter sends private report to vendor/coordinator.
• Within 1–7 days: Vendor acknowledges and confirms receipt.
• Within 14–45 days: Vendor validates and provides initial assessment (e.g. confirmed, duplicate, out of scope).
• By ~90 days (or agreed date): Vendor releases fix (or mitigation) and notifies reporter.
• Disclosure: Reporter and vendor publish advisories/reports on an agreed date; reporter may publish after the fix is available.

Extensions can be agreed if a fix needs more time; disclosure is usually delayed until the fix is available.

---

CVD process: step-by-step

End-to-end flow from discovery to public disclosure.

Phase 1: Discovery and reporting

1. Discover a potential vulnerability (code, config, design, or dependency).
2. Document clearly: affected product/version, steps to reproduce, impact, and (if possible) a suggested fix or mitigation.
3. Find the right contact: vendor security page, security@ email, bug bounty or CVD program (e.g. HackerOne, Bugcrowd, vendor-specific).
4. Send the report through the designated channel (encrypted if possible). Include:
   • Summary and severity (e.g. critical/high).
   • Affected versions and environment.
   • Step-by-step reproduction.
   • Impact and attack scenario.
   • Any proof-of-concept (handled as confidential).

+------------------+     private report      +------------------+
|    Reporter      | ----------------------> | Vendor /         |
| (researcher,     |   (encrypted preferred) | Coordinator      |
|  automated)      |                         |                  |
+------------------+                         +------------------+

Phase 2: Triage and validation

1. Vendor acknowledges receipt (e.g. within 1–7 days).
2. Triage: Assign priority (e.g. critical / high / medium / low) and owner.
3. Validate: Reproduce the issue and confirm it is in scope and not a duplicate.
4. Communicate back: Tell the reporter whether the report is accepted, duplicate, or out of scope, and give a rough timeline if accepted.

Phase 3: Fix and release

1. Develop a fix (code change, config change, or mitigation).
2. Test the fix and any backports (e.g. supported branches).
3. Release via normal release process (patch release, security advisory, CVE if applicable).
4. Notify the reporter and (if applicable) key downstream or deployers under embargo.

Phase 4: Coordinated disclosure

1. Agree on disclosure date and format (vendor advisory, CVE, reporter blog, etc.).
2. Prepare materials: advisory, CVE description, reporter write-up (if any).
3. Publish on the agreed date: vendor first (or same day) so that patch availability is clear.
4. Credit the reporter as agreed (name, handle, or anonymous).

Report --> Triage --> Validate --> Fix --> Release --> Agree date --> Public disclosure
                \_____________________________/
                         (confidential)

---

How to follow CVD (practical guidance)

If you are the reporter

1. Check the vendor’s policy
   Look for a security or vulnerability disclosure page (e.g. https://vendor.com/security or security.txt). Prefer their stated channel and process.

2. Use security.txt when available
   Many sites expose /.well-known/security.txt with Contact:, Expires:, and optional Preferred-Languages: and Canonical:.

3. Report privately first
   Do not publish details, PoC, or exploit code until the vendor has had time to fix (or you have agreed otherwise).

4. Be clear and factual
   Describe impact, steps, and environment. This speeds up validation and prioritisation.

5. Honour the timeline
   Stick to the agreed disclosure date; if the vendor needs more time and you agree, extend rather than disclosing early.

6. Consider a coordinator
   If the vendor is unresponsive or you prefer a neutral party, use a CERT (e.g. CERT/CC, national CERT) or a program that runs CVD (e.g. some bug bounties).

If you are the vendor

1. Publish a clear policy
   State how to report (email, portal), what you consider in/out of scope, and what reporters can expect (acknowledgement, timeline, credit).

2. Acknowledge quickly
   Send an automated or manual acknowledgement within a few days so the reporter knows the report was received.

3. Triage and communicate
   Assign severity, confirm or reject, and give a rough timeline. Keep the reporter updated on major steps (e.g. “fix in progress”, “release planned for X”).

4. Fix and release
   Prioritise based on severity and exploitability; backport where needed. Prefer releasing a fix before or on the disclosure date.

5. Coordinate disclosure
   Agree with the reporter on the date and content of advisories; assign CVE if appropriate; credit the reporter as agreed.

If you use a coordinator (e.g. CERT)

• Reporter sends the report to the coordinator.
• Coordinator forwards to the vendor (or multiple vendors if it’s a shared dependency), keeps the reporter anonymous if requested, and tracks timelines.
• Vendor works with the coordinator and (if allowed) the reporter; coordinator helps align on disclosure date and format.

---

Examples

Example 1: Researcher finds a bug in an open-source library

• Discovery: A security researcher finds a path traversal in a popular npm package used by many applications.
• Report: They look up the project’s GitHub security policy and report via the “Security” tab (private). They include: package name and version, steps to reproduce, impact (e.g. read arbitrary files), and a minimal PoC.
• Vendor (maintainer): Maintainer acknowledges in 2 days, confirms in 1 week, develops a fix and releases a patch in 4 weeks. They ask the researcher to wait 2 more weeks so downstream can update.
• Disclosure: On the agreed date, maintainer publishes a GitHub advisory and CVE; researcher publishes a short blog post with credit. Both link to the fixed version.

Example 2: Internal team finds a vulnerability in your own product

• Discovery: Your own penetration test or code review finds a critical auth bypass in your SaaS product.
• Internal CVD: Treat it like an external report: log it, assign owner, set a fix and disclosure timeline. If you plan to mention it in a security advisory or release notes, decide the disclosure date in advance.
• Fix and release: Develop and test the fix, deploy to production, release updated clients if needed.
• Disclosure: Publish an advisory and/or release notes on the chosen date. No external reporter to credit, but the process (triage, fix, coordinated release) is the same.

Example 3: Multi-vendor / supply-chain issue (coordinator involved)

• Discovery: A researcher finds a vulnerability in a widely used firmware component supplied by Vendor A and used in products from Vendors B and C.
• Report to coordinator: Researcher reports to a national CERT or similar coordinator, with technical details and impact.
• Coordinator: CERT validates, notifies Vendor A and (as appropriate) B and C, sets an embargo and target disclosure date. Reporter stays anonymous to vendors if requested.
• Vendors: Vendor A develops a fix for the component; B and C integrate the fix and prepare their own advisories. All under embargo until the agreed date.
• Disclosure: On the agreed date, CERT and all vendors publish advisories and CVEs; researcher is credited in the CERT advisory (or remains anonymous).

Example 4: Vendor is unresponsive

• Report: Researcher reports a high-severity issue to a small vendor via email. No response after 14 days; reminder at 30 days still no response.
• Escalation: Researcher contacts a CERT (e.g. CERT/CC) and forwards the report. CERT also tries to contact the vendor and sets a disclosure deadline (e.g. 90 days from original report).
• Outcome: If the vendor never responds, CERT may publish a limited advisory (e.g. “Vendor unresponsive; users should consider mitigations or alternative products”) and the researcher may publish their own write-up after the deadline, following the coordinator’s guidance.

---

Summary

Aspect	Takeaway
CVD	Private report → vendor fix → coordinated public disclosure.
Process	Report → Triage → Validate → Fix → Release → Agree date → Disclose.
Reporter	Use vendor/CERT process, report privately, document clearly, honour agreed timing.
Vendor	Publish a policy, acknowledge and triage quickly, fix and release, then disclose with credit.
Timeline	Often 90–120 days to fix and disclose; extend by agreement if needed.
Coordinators	CERTs and CVD programs can receive reports, contact vendors, and align disclosure.

Following a clear CVD protocol reduces risk for users, gives vendors time to fix, and makes security research more predictable and collaborative. Define your policy, use a consistent process, and coordinate disclosure so that fixes are available when details go public.