Coordinated Vulnerability Disclosure: A Complete Guide

Coordinated vulnerability disclosure is the process by which a security researcher who discovers a vulnerability works with the vendor to fix it before public disclosure. When it works, users get a patch before attackers get an exploit. When it fails, the vulnerability becomes a zero-day with no fix available.

The process is straightforward in theory and messy in practice. Timelines slip. Vendors go silent. Researchers get frustrated. Legal threats fly. This guide covers how to run the process effectively from both sides.

For Vulnerability Reporters

Finding the Right Contact

The first challenge is figuring out where to send the report. In order of preference:

1. SECURITY.md file in the project's repository. This is the standard location for vulnerability reporting instructions.
2. security@domain email address. Many organizations use this convention.
3. Bug bounty platform. If the vendor has a program on HackerOne, Bugcrowd, or Intigriti, use it.
4. GitHub Private Security Advisory. For open source projects on GitHub, you can create a private advisory that notifies maintainers.
5. CERT/CC. If you cannot reach the vendor, CERT/CC (cert.cc) acts as a neutral coordinator.

Never report security vulnerabilities through public channels (issue trackers, forums, social media) unless all private channels have been exhausted and a reasonable deadline has passed.

Writing the Report

A good vulnerability report includes:

Summary. One paragraph describing the vulnerability, its impact, and the affected software.

Technical details. Step-by-step instructions to reproduce the vulnerability. Include:

• The affected version(s)
• The environment (OS, runtime version, configuration)
• Exact steps to reproduce
• The expected behavior versus the observed behavior
• The security impact (what can an attacker do?)

Proof of concept. A minimal demonstration that confirms the vulnerability. This should be the simplest possible reproduction, not a weaponized exploit. The goal is to help the vendor confirm and fix the issue, not to demonstrate offensive capability.

Suggested fix. If you have insight into how the vulnerability should be fixed, include it. This accelerates the vendor's response. Be aware that your suggested fix may not be the approach the vendor takes.

Your timeline. State your disclosure timeline: "I plan to publicly disclose this vulnerability 90 days from this report, or sooner if a fix is released."

Disclosure Timelines

The industry-standard disclosure timeline is 90 days from the initial report. This is the timeline used by Google Project Zero and generally accepted as reasonable.

Shorter timelines may be appropriate when:

• The vulnerability is being actively exploited in the wild
• The vulnerability is trivial to discover (and therefore likely already known to attackers)
• The vendor has a history of delayed or non-responsive behavior

Longer timelines may be appropriate when:

• The fix is complex and requires significant engineering effort
• The vulnerability affects critical infrastructure where uncoordinated disclosure could cause harm
• The vendor is actively working on a fix and communicating progress

Handling Non-Responsive Vendors

If the vendor does not respond to your initial report:

1. Wait one week. Then send a follow-up to the same contact.
2. Try alternative contacts. Use a different communication channel (email, bug bounty platform, CERT/CC).
3. Wait two more weeks. Send a final notice stating your disclosure timeline.
4. Involve a coordinator. Contact CERT/CC or a relevant CSIRT to mediate.
5. Disclose. If 90 days have passed with no response, you are generally justified in public disclosure.

Document every communication attempt. If disclosure becomes contentious, this documentation protects you.

For Vendors Receiving Reports

Acknowledgment

Acknowledge receipt of every vulnerability report within 48 hours. Even if you cannot assess the validity immediately, confirm that you received it and provide a timeline for initial assessment.

An acknowledgment email should include:

• Confirmation that the report was received
• A tracking number or reference for the report
• The timeline for initial assessment (typically 5-10 business days)
• Contact information for follow-up

Triage and Assessment

Assess the report within the stated timeline:

1. Verify the vulnerability. Can you reproduce it? If not, ask the reporter for clarification.
2. Assess severity. Calculate a CVSS score. Determine the impact on your users.
3. Determine scope. Which versions are affected? Which deployment configurations?
4. Estimate fix timeline. How long will it take to develop, test, and release a fix?

Communicate the assessment back to the reporter. If you disagree with the reporter's severity assessment, explain why. If the fix will take longer than the reporter's disclosure timeline, negotiate an extension with a concrete delivery date.

Fix Development

Develop the fix with confidentiality:

• Work on the fix in a private branch or forked repository
• Limit knowledge of the vulnerability to the minimum necessary team
• Prepare the advisory, changelog entry, and release notes before the fix is released
• Coordinate the release date with the reporter

Release and Disclosure

On the agreed disclosure date:

1. Release the patched version
2. Publish the advisory
3. Submit to CVE and advisory databases
4. Notify the reporter that the fix is published
5. Thank the reporter publicly (with their permission)

Building a Vulnerability Response Process

Organizations that receive vulnerability reports regularly should formalize their process:

• Dedicated intake channel. security@domain, bug bounty platform, or GitHub Private Advisories
• Triage team. Named individuals responsible for initial assessment
• SLAs. Defined timelines for acknowledgment (48 hours), triage (5 business days), and fix (based on severity)
• Communication templates. Pre-written templates for acknowledgment, assessment, fix notification, and advisory publication
• Legal review. Ensure your legal team understands the disclosure process and will not threaten reporters

CVE Assignment

When to Request a CVE

Request a CVE for any vulnerability that:

• Affects publicly available software
• Has a security impact (not just a bug)
• Affects users who need to take action (update, reconfigure, etc.)

How to Request a CVE

1. If you are a CNA (CVE Numbering Authority): Assign the CVE yourself. Major software vendors and some open source projects are CNAs.
2. If you are not a CNA: Submit a request through the CVE.org web form, or through a relevant CNA (GitHub is a CNA for open source projects on its platform).
3. Through CERT/CC: CERT/CC can assign CVEs for vulnerabilities they coordinate.

Request the CVE early in the process so it is available when the advisory is published. CVE assignment can take days or weeks.

Legal Considerations

For Reporters

• Safe harbor. Many organizations include safe harbor language in their vulnerability disclosure policies, promising not to pursue legal action against good-faith reporters. Check before reporting.
• CFAA considerations. In the United States, the Computer Fraud and Abuse Act creates legal risk for security research. Stay within the scope of the vendor's disclosure policy or bug bounty terms.
• Documentation. Keep records of all communications. If a vendor becomes adversarial, documentation is your defense.

For Vendors

• Do not threaten reporters. Legal threats against good-faith researchers are counterproductive and create negative publicity. They also discourage future reports, leaving you blind to vulnerabilities.
• Publish a disclosure policy. A clear policy with safe harbor language encourages responsible reporting.
• Legal review of the policy. Have your legal team review and approve the policy before publication.

How Safeguard.sh Helps

Safeguard.sh supports both sides of the disclosure process. For organizations receiving vulnerability reports, Safeguard provides the dependency data needed to quickly assess impact: which versions are affected, which customers use those versions, and what the remediation path looks like. For organizations monitoring for disclosures, Safeguard correlates newly published CVEs against your dependency inventory within minutes of publication, ensuring that coordinated disclosures translate into rapid remediation across your portfolio.