7.2 — Coordinated Vulnerability Disclosure

1. What Is Coordinated Vulnerability Disclosure

Coordinated Vulnerability Disclosure (CVD) is the process through which security vulnerabilities are reported, verified, remediated, and publicly disclosed in a manner that balances the interests of all stakeholders: the vendor who must fix the vulnerability, the researchers who discover it, and the public who is affected by it.

The term “coordinated” replaced the older term “responsible disclosure” because the process requires cooperation between multiple parties, not just “responsibility” on the part of the reporter. The reporter has a responsibility to give the vendor time to fix the issue. The vendor has a responsibility to fix the issue promptly and communicate transparently.

Why CVD Matters

Without a CVD process:

• Researchers have no safe channel to report findings. They may resort to full public disclosure, posting on social media, or selling vulnerabilities on the black market.
• Vendors have no systematic way to receive and triage external reports. Vulnerability reports sent to generic support email addresses are frequently lost, ignored, or deprioritized.
• The public bears the risk. Uncoordinated disclosure either leaves vulnerabilities unpatched (if researchers stay silent) or exposes users to exploitation (if researchers disclose before a fix is available).
• Legal ambiguity creates chilling effects. Without safe harbor provisions, researchers fear prosecution under computer fraud laws, reducing the volume of good-faith security research.

CIS Control 16.2 Requirements

CIS 16.2 requires organizations to:

• Establish a process to accept and address software vulnerability reports.
• Provide an external reporting mechanism.
• Designate a named responsible party.
• Define intake, assignment, remediation, and remediation testing processes.
• Set severity ratings and timing metrics.
• Review the process annually.

CISA Secure by Design Goals 5 and 6

CISA’s Secure by Design pledge (2024, reinforced in 2025-2026) includes specific disclosure goals:

Goal 5 — Vulnerability Disclosure Policy: Software manufacturers should publish a vulnerability disclosure policy that:

• Authorizes testing against all products.
• Commits to not recommending or pursuing legal action against reporters acting in good faith.
• Provides a clear reporting mechanism.
• Is consistent with industry best practices and international standards.

Goal 6 — CVEs: Software manufacturers should:

• Issue CVEs in a timely manner for vulnerabilities, including those discovered internally.
• Include CWE classification in CVE records.
• Report accurately and completely.
• Demonstrate a year-over-year trend toward issuing CVEs more promptly.

---

2. The Vulnerability Disclosure Policy (VDP)

A VDP is the foundation of coordinated vulnerability disclosure. It is a public document that tells the world how to report security vulnerabilities to your organization and what to expect when they do.

VDP Components

Scope Definition:

Clearly define what systems, products, and services are covered by the VDP.

In Scope:
- All web applications hosted at *.example.com
- Mobile applications (iOS and Android) published by Example Corp
- API endpoints documented at api.example.com
- Open-source projects maintained by Example Corp on GitHub

Out of Scope:
- Third-party services integrated with our platform (report to the vendor)
- Physical security of our offices
- Social engineering of our employees
- Denial of service testing against production systems
- Systems belonging to our customers

Safe Harbor:

Safe harbor provisions are the single most important element of a VDP. Without them, researchers will not report.

Safe Harbor:
We consider security research conducted in accordance with this policy
to be authorized activity. We will not pursue civil or criminal action
against researchers who:

- Make a good-faith effort to avoid privacy violations, data
  destruction, and disruption to our services.
- Only interact with accounts they own or with explicit permission
  of the account holder.
- Do not exploit a security vulnerability beyond the minimum
  necessary to demonstrate its existence.
- Report vulnerabilities to us before disclosing them publicly.
- Allow us a reasonable time to remediate before public disclosure.

We will not file a complaint under the Computer Fraud and Abuse Act
(CFAA) or equivalent laws against researchers who follow this policy.
If legal action is initiated by a third party against a researcher
for activities conducted in accordance with this policy, we will take
steps to make it known that the researcher's actions were authorized.

This language aligns with the DOJ’s 2022 revised CFAA enforcement policy, which directs prosecutors not to charge good-faith security research.

Reporting Channels:

Provide multiple secure reporting options:

• Encrypted email: security@example.com with PGP/GPG public key published on the website and on public keyservers.
• Web form: HTTPS-secured form at example.com/security/report. Use a dedicated form, not a general support ticket system.
• Bug bounty platform: If you operate a program through HackerOne, Bugcrowd, or similar, link directly to the program page.
• security.txt: Publish a /.well-known/security.txt file per RFC 9116 with contact information, preferred languages, encryption key location, and policy URL.

Example security.txt:

Contact: https://example.com/security/report
Contact: mailto:security@example.com
Encryption: https://example.com/.well-known/pgp-key.txt
Preferred-Languages: en
Policy: https://example.com/security/vdp
Hiring: https://example.com/careers/security
Expires: 2027-03-19T00:00:00.000Z

Expected Report Content:

Guide reporters on what to include:

• Description of the vulnerability (what it is, where it exists).
• Detailed reproduction steps (environment, tools, exact sequence).
• Potential security impact (what an attacker could achieve).
• Proof of concept (code, screenshots, video) if available.
• Suggested remediation if the reporter has ideas.
• Reporter’s contact information for follow-up communication.

Prohibited Activities:

Clearly state what is not permitted:

• Social engineering (phishing, vishing, pretexting) against employees.
• Physical intrusion or access attempts.
• Denial of service (DoS/DDoS) attacks.
• Automated scanning that could impact service availability.
• Accessing, modifying, or deleting data that is not your own.
• Placing backdoors in systems for any reason.
• Pivoting to other systems after demonstrating initial access.

Response Timeline Commitments:

Phase	Timeline	Description
Acknowledgment	5 business days	Confirm receipt of the report and assign a tracking ID
Initial triage	10 business days	Assess validity and severity, assign to remediation team
Status update	Monthly	Provide at least monthly updates on remediation progress
Fix target	Varies by severity	Critical: 30 days, High: 60 days, Medium: 90 days
Public disclosure	90 days	Coordinate public disclosure 90 days after report

The 90-day disclosure timeline follows the standard established by Google Project Zero and widely adopted by the security research community. This timeline:

• Gives vendors sufficient time to develop, test, and deploy a fix.
• Provides a definite deadline that prevents indefinite delays.
• Can be extended by mutual agreement in exceptional circumstances.
• May be shortened if evidence of active exploitation emerges.

Recognition:

• Hall of Fame: Public acknowledgment on a security page for researchers who report valid vulnerabilities.
• Advisory credit: Named credit in security advisories for the researcher who reported the vulnerability.
• Bounty programs: Monetary rewards for qualifying findings (if applicable, link to the bounty program).

---

3. The CVE Assignment Process

What Is a CVE

A CVE (Common Vulnerabilities and Exposures) identifier is a unique, standardized reference for a publicly known cybersecurity vulnerability. CVE IDs take the format CVE-YEAR-NNNNN (e.g., CVE-2025-53773).

CVE assignment is not optional. CISA Secure by Design Goal 6 requires software manufacturers to issue CVEs in a timely manner, including for internally discovered vulnerabilities.

CVE Numbering Authorities (CNAs)

A CNA is an organization authorized to assign CVE IDs for vulnerabilities within a defined scope. As of 2026, there are over 400 CNAs worldwide.

Who should become a CNA:

• Any organization that regularly discovers or receives reports about vulnerabilities in its own products.
• Open-source projects with a significant user base.
• Security companies that discover vulnerabilities in third-party products.

How to become a CNA:

1. Review the CNA rules at https://www.cve.org/ResourcesSupport/AllResources/CNARules.
2. Submit an application through the CVE Program website.
3. Identify a root CNA (typically MITRE or a regional/industry-specific root).
4. Define your scope (typically: your own products and services).
5. Designate at least two CNA contacts.
6. Commit to assigning CVEs within 72 hours of confirming a vulnerability.
7. Commit to publishing CVE records with required fields.

CNA responsibilities:

• Assign CVE IDs for vulnerabilities within scope.
• Populate CVE records with required fields: description, affected versions, references, CWE, CVSS.
• Publish CVE records within a reasonable timeframe (before or concurrent with public advisory).
• Update CVE records when new information becomes available.
• Maintain communication with reporters about CVE assignment status.

CVE Record Requirements

A CVE record must include:

• CVE ID: The unique identifier.
• Description: Clear, factual description of the vulnerability. Avoid marketing language. Include the vulnerability type, the affected component, and the impact.
• Affected products/versions: Specific product names and version ranges.
• References: Links to the advisory, patch, and any related resources.
• CWE: The weakness type classification.
• CVSS score: Severity assessment using CVSS (4.0 preferred, 3.1 acceptable).

---

4. Responsible Disclosure vs. Full Disclosure

The security community has debated disclosure models for decades. Understanding the positions informs policy design.

Coordinated (Responsible) Disclosure

The researcher reports the vulnerability privately to the vendor. The vendor is given a defined period (typically 90 days) to develop and release a fix. Public disclosure occurs after the fix is available or after the disclosure deadline, whichever comes first.

Arguments in favor:

• Gives vendors time to protect users before vulnerability details are public.
• Reduces the window of exploitation.
• Encourages positive vendor-researcher relationships.
• Aligns with the principle of minimizing harm.

Arguments against:

• Vendors may use the disclosure period to delay or suppress fixes.
• Without a hard deadline, some vendors never fix vulnerabilities.
• Users cannot make informed risk decisions until disclosure occurs.
• Power imbalance: vendors have legal resources that researchers do not.

Full Disclosure

The researcher publishes the vulnerability details publicly, immediately, with no advance notice to the vendor. The rationale is that public pressure forces vendors to fix vulnerabilities faster, and users can take protective action immediately.

Arguments in favor:

• Maximum transparency for affected users.
• Eliminates the risk of vendor suppression.
• Historical evidence: some vendors only fix vulnerabilities after public disclosure.
• Users can implement their own mitigations immediately.

Arguments against:

• Exposes users to exploitation before a fix is available.
• Attackers can weaponize the disclosure faster than vendors can fix.
• Does not account for the complexity of developing and testing fixes.
• Burns bridges between researchers and vendors.

Industry Consensus

The security industry has largely converged on coordinated disclosure with a defined timeline as the standard:

• Google Project Zero: 90 days, with a 14-day grace period if a fix is in progress at day 90.
• ZDI (Zero Day Initiative): 120 days.
• CERT/CC: 45 days.
• Microsoft: Acknowledges 90 days as the standard.

The hard deadline is critical. Without it, coordinated disclosure degenerates into indefinite secrecy. The deadline creates urgency and accountability while giving vendors reasonable time to fix the issue.

---

5. Bug Bounty Programs

Bug bounty programs formalize and incentivize external vulnerability discovery by offering monetary rewards for qualifying findings.

Platform Options

Platform	Model	Notable Features
HackerOne	Managed or self-service	Largest researcher community, triage-as-a-service, compliance programs
Bugcrowd	Managed or self-service	CrowdMatch for researcher selection, vulnerability rating taxonomy
Synack	Managed (researchers vetted)	Vetted researchers, on-demand pen testing, continuous coverage
Intigriti	Managed or self-service	Strong EU presence, GDPR-aligned, triage service
YesWeHack	Managed or self-service	European platform, government and defense programs

Program Types

Private programs:

• Invitation-only, limited to vetted researchers.
• Lower volume, higher quality findings.
• Appropriate for organizations new to bug bounties.
• Can restrict scope to specific areas of concern.

Public programs:

• Open to all researchers.
• Higher volume of submissions (including noise and duplicates).
• Broader coverage of the attack surface.
• Requires robust triage capability.
• Greater brand visibility in the security community.

Reward Tiers

Reward amounts vary by severity, impact, and program budget. Industry benchmarks:

Severity	Typical Range	Example Finding
Critical	$5,000 - $50,000+	Remote code execution, authentication bypass, full data breach
High	$2,000 - $15,000	SQL injection, SSRF with internal access, privilege escalation
Medium	$500 - $5,000	Stored XSS, IDOR with limited data exposure, CSRF on sensitive action
Low	$100 - $1,000	Reflected XSS, information disclosure, missing security headers
Informational	$0 - $100	Best practice recommendations, low-impact findings

Top-tier programs (Google, Apple, Microsoft) offer significantly higher rewards, with some critical findings commanding $100,000 or more. These programs attract elite researchers and generate correspondingly high-quality findings.

Scope Management

Scope must be clearly defined and actively maintained:

In-scope assets:

• List specific domains, applications, APIs, and products.
• Specify which environments can be tested (production with limitations, dedicated staging).
• Define which vulnerability types are in scope.

Out-of-scope assets:

• Third-party integrations and services.
• Systems you don’t own or control.
• Physical security, social engineering.
• Denial of service testing.

Rules of engagement:

• Testing must not disrupt service for other users.
• Data access should be limited to the researcher’s own test accounts.
• Automated scanning must be rate-limited.
• Chaining vulnerabilities is encouraged but each step must be demonstrated.
• Duplicate policy: first valid report receives the bounty.

Triage and Response SLAs

Bug bounty programs must have dedicated triage capacity:

• Acknowledgment: Within 1 business day (platform-managed programs typically auto-acknowledge).
• Initial triage: Within 5 business days. Assess validity, severity, and uniqueness.
• Bounty decision: Within 10 business days of triage. Communicate reward amount and rationale.
• Payment: Within 30 days of bounty decision. Faster payment improves researcher satisfaction and program reputation.
• Fix timeline: Per organizational SLAs by severity.

Legal Framework

• The bug bounty program’s terms must include safe harbor provisions aligned with the VDP.
• Participants agree to the rules of engagement as a condition of participation.
• Intellectual property: findings belong to the organization once reported. Researchers retain the right to discuss the finding publicly after the disclosure timeline expires.
• Tax implications: bounty payments are taxable income. Platforms typically handle 1099/W-8BEN reporting.

---

6. Security Advisory Publication

When a vulnerability is fixed and ready for disclosure, the organization publishes a security advisory.

Advisory Content

A complete security advisory includes:

• Advisory ID: Unique identifier for internal tracking.
• CVE ID(s): Associated CVE identifiers.
• Title: Concise description of the vulnerability.
• Severity: CVSS score and rating (Critical/High/Medium/Low).
• Affected versions: Specific product versions and configurations affected.
• Description: Technical description of the vulnerability, sufficient for users to understand the risk but not a step-by-step exploitation guide.
• Impact: What an attacker could achieve by exploiting this vulnerability.
• Mitigation: Temporary measures users can take before upgrading.
• Fix: Version number containing the fix, with upgrade instructions.
• Timeline: Discovery date, report date, fix date, disclosure date.
• Credit: Acknowledgment of the researcher who reported the vulnerability (with their permission).
• References: Links to patches, related advisories, CWE entries.

Distribution Channels

• Vendor security page: Dedicated security advisory page on the product website.
• GitHub Security Advisories (GHSA): For open-source projects. Integrates with Dependabot for automatic consumer notification.
• Email lists: Security-specific mailing list for customers and partners.
• RSS/Atom feed: Machine-readable advisory feed.
• OSV (Open Source Vulnerability) database: For open-source vulnerabilities.
• NVD: CVE publication automatically feeds into the National Vulnerability Database.

Advisory Formats

CSAF (Common Security Advisory Framework): OASIS standard for machine-readable security advisories. CSAF 2.0 (current) supports automated processing and is required by some government agencies. Format: JSON with defined schema.

VEX (Vulnerability Exploitability eXchange): A profile of CSAF that communicates the exploitability status of a vulnerability in a specific product. VEX statements can assert: not affected, affected, fixed, or under investigation. VEX is particularly important for SCA/SBOM consumers who need to know whether a vulnerability in a dependency actually affects a specific product.

OSV (Open Source Vulnerability) format: Google-originated format for open-source vulnerabilities. Used by OSV.dev, GitHub, and various SCA tools. JSON format with a focus on affected version ranges and package ecosystem metadata.

---

7. Multi-Party Coordinated Vulnerability Disclosure

When a vulnerability affects multiple vendors (e.g., a vulnerability in a protocol, shared library, or common component), multi-party CVD is required.

Challenges

• Notification timing: All affected vendors should be notified simultaneously to prevent information leakage.
• Disclosure coordination: All vendors need to align on a disclosure date, which may be delayed by the slowest vendor.
• Embargo management: More parties in an embargo increase the risk of leak.
• Different remediation timelines: Some vendors can fix in days; others need months.
• Communication overhead: Coordinating across organizations, time zones, and communication styles.

CERT/CC’s Role

The CERT Coordination Center (CERT/CC) at Carnegie Mellon University’s Software Engineering Institute serves as a neutral coordinator for multi-party CVD:

• Receives vulnerability reports from researchers.
• Identifies all affected vendors.
• Notifies vendors under embargo.
• Coordinates disclosure timelines.
• Publishes advisories when vendors fail to respond.
• Maintains a 45-day disclosure policy.

Best Practices for Multi-Party CVD

1. Identify a coordinator early. CERT/CC, a national CERT, or the researcher can serve as coordinator.
2. Use secure communication channels. Encrypted email, dedicated portals, or platforms designed for CVD coordination.
3. Set a firm disclosure date. All parties agree to a date. If some vendors cannot fix by the date, they must communicate this and explain their mitigation strategy.
4. Prepare advisories in advance. Draft advisories before the disclosure date so all parties can publish simultaneously.
5. Accept that not all vendors will respond. Some vendors ignore notifications. The coordinator should document attempts to contact unresponsive vendors and proceed with disclosure on schedule.

---

8. AI Considerations in Vulnerability Disclosure

The intersection of AI and vulnerability disclosure creates new challenges that existing frameworks were not designed to address.

AI-Discovered Vulnerabilities

AI tools are now capable of autonomously discovering security vulnerabilities in software. This is not theoretical — it is happening at scale:

Claude’s OSS vulnerability research: Anthropic demonstrated that Claude could discover over 500 high-severity vulnerabilities in open-source software. These were real, previously unknown vulnerabilities in widely used projects. This capability raises fundamental questions about the disclosure process.

AI fuzzing at scale: Google’s OSS-Fuzz, augmented with AI, has found thousands of vulnerabilities through AI-directed fuzzing. The AI generates more effective test cases by learning from previous crashes and code structure.

AI code review: AI-powered code review tools (CodeRabbit, Qodo, Copilot code review) are identifying security issues at scale during the development process, before the code reaches production.

Disclosure Challenges for AI-Discovered Vulnerabilities

Volume challenge: If an AI system can discover vulnerabilities faster than human teams can triage and fix them, the traditional disclosure model breaks down. A single AI agent could generate hundreds of vulnerability reports per day, overwhelming the receiving organization’s capacity to respond. This is not a hypothetical — it is an active concern in the security community.

Potential approaches:

• Rate-limit AI-generated disclosures to match vendor remediation capacity.
• Prioritize AI-discovered vulnerabilities by severity and exploitability before reporting.
• Batch similar findings (e.g., “the same SQL injection pattern exists in 47 endpoints”) rather than reporting each individually.
• Provide AI-generated fix suggestions alongside vulnerability reports to accelerate remediation.

Attribution challenge: When an AI discovers a vulnerability, who gets credited? The AI system? The organization that operates the AI? The person who directed the AI to look? This matters for:

• CVE credit and acknowledgment.
• Bug bounty rewards (platforms generally require a human participant).
• Legal liability if the AI’s testing caused damage.
• Academic and professional reputation.

Current practice is evolving, but the emerging consensus is:

• The human operator or organization directing the AI is the credited party.
• The AI tool may be mentioned in the methodology section (“discovered using automated analysis with [tool name]”).
• Bug bounty platforms generally accept AI-assisted findings but may adjust rewards or require human verification.

Ethical considerations:

• Consent: Is it ethical for an AI to scan software for vulnerabilities without the vendor’s permission? The same question applies to human researchers, but AI scales the impact dramatically.
• Weaponization risk: AI-discovered vulnerability details could be used for offensive purposes. Should there be additional safeguards on AI-discovered vulnerabilities?
• Autonomy: Should an AI system be permitted to submit vulnerability reports without human review? What if the human operator is unavailable?
• Bias in discovery: AI tools may be better at finding certain types of vulnerabilities than others, potentially creating false confidence in areas where the AI has blind spots.

AI-Generated Vulnerability Reports

AI can also improve the quality and consistency of vulnerability reports:

• Automatically generate detailed reproduction steps.
• Classify vulnerabilities by CWE type.
• Suggest CVSS scores with rationale.
• Generate proof-of-concept code.
• Draft advisory text.
• Identify related vulnerabilities that may share the same root cause.

However, AI-generated reports must be human-reviewed before submission. AI can hallucinate vulnerability details, generate incorrect reproduction steps, or misclassify severity. A false or inaccurate vulnerability report wastes vendor resources and damages the credibility of the reporting entity.

---

9. Standards and Frameworks

ISO/IEC 29147: Vulnerability Disclosure

ISO/IEC 29147 provides guidelines for vendors on receiving and publishing vulnerability information. Key elements:

• Receiving reports: Establish a point of contact, publish a VDP, acknowledge reports, protect reporter confidentiality.
• Coordinating disclosure: Communicate with reporters throughout the process, negotiate disclosure timelines, involve coordinators for multi-party issues.
• Publishing advisories: Advisory content requirements, distribution methods, timing considerations.
• Internationalization: Support for multiple languages and communication across cultures.

ISO/IEC 30111: Vulnerability Handling Processes

ISO/IEC 30111 provides guidelines for the internal handling of vulnerabilities once received. Key elements:

• Policy: Define organizational policy for vulnerability handling, including roles, responsibilities, and authorities.
• Process: Establish processes for verification, analysis, remediation, and disclosure of vulnerabilities.
• Vendor organizational preparedness: Ensure the organization has the people, processes, and technology to handle vulnerabilities effectively.
• Interaction with other processes: Integrate vulnerability handling with incident response, change management, release management, and customer communication.

CERT Guide to Coordinated Vulnerability Disclosure

The CERT/CC Guide to CVD (SEI-2017-SR-022, updated periodically) is the most comprehensive practical reference for CVD. It covers:

• Roles in CVD: finder, reporter, vendor, coordinator, deployer.
• Communication in CVD: establishing contact, maintaining confidentiality, handling unresponsive vendors.
• Coordination: multi-party coordination, embargo management, disclosure timing.
• Special cases: zero-day vulnerabilities, vulnerabilities in critical infrastructure, vulnerabilities affecting government systems.

---

10. Building Your CVD Program

Implementation Roadmap

Phase 1 (Month 1-2): Foundation

• Draft and publish a VDP.
• Implement security.txt on all web properties.
• Set up a secure reporting channel (encrypted email, web form).
• Designate a responsible party and backup.
• Create an internal SOP for handling external vulnerability reports.
• Train the security team on the CVD process.

Phase 2 (Month 3-4): Operationalize

• Integrate external vulnerability reports into the vulnerability tracking system.
• Establish SLAs and escalation procedures.
• Create response templates (acknowledgment, status updates, resolution, advisory).
• Conduct a tabletop exercise with a simulated vulnerability report.
• Apply to become a CVE Numbering Authority (CNA).

Phase 3 (Month 5-6): Scale

• Evaluate bug bounty platforms and launch a private program.
• Develop security advisory publication process and templates.
• Implement CSAF/VEX for machine-readable advisories.
• Establish relationships with CERT/CC and relevant national CERTs.
• Create metrics and dashboards for CVD program performance.

Phase 4 (Ongoing): Mature

• Expand bug bounty to public program based on maturity.
• Regularly review and update VDP, SLAs, and processes.
• Track metrics: time to acknowledgment, time to fix, researcher satisfaction.
• Participate in industry CVD working groups and standards development.
• Address AI-specific disclosure challenges as they emerge.

---

Key Takeaways

1. A published VDP is a requirement, not an option. CIS 16.2, CISA Secure by Design, and ISO/IEC 29147 all require it. Organizations without a VDP are telling researchers to either stay silent or go public.
2. Safe harbor provisions are the foundation of researcher trust. Without explicit legal protections, researchers will not report to you.
3. The 90-day disclosure timeline is an industry standard. It balances vendor remediation time with public safety. Hard deadlines create accountability.
4. CVE assignment is a vendor responsibility. CISA Secure by Design Goal 6 requires timely, accurate CVE issuance. Becoming a CNA gives you control over this process.
5. Bug bounty programs are a force multiplier. External researchers find vulnerabilities that internal testing misses, often at a lower cost per finding than traditional pen testing.
6. AI is transforming vulnerability discovery. AI-discovered vulnerabilities at scale will challenge existing disclosure processes. Organizations must prepare for higher volumes and faster cycles.
7. Multi-party CVD is the hardest coordination problem. Use neutral coordinators (CERT/CC) when multiple vendors are affected.

---

Practical Exercise

Scenario 1: VDP Development Your organization does not currently have a vulnerability disclosure policy. Draft a complete VDP using the template in Section 2. Include all required sections: scope, safe harbor, reporting channels, expected content, prohibited activities, timelines, and recognition.

Scenario 2: Disclosure Coordination A security researcher reports a critical vulnerability in your product’s OAuth implementation. They can steal OAuth tokens from any user by manipulating the redirect URI. They tell you they plan to present this at a security conference in 45 days.

1. Draft the acknowledgment response.
2. Assess whether 45 days is sufficient for remediation.
3. If not, how would you negotiate a timeline extension?
4. Draft the CVE record fields for this vulnerability.
5. Draft the security advisory that will be published when the fix is released.
6. Determine which distribution channels the advisory should use.

Scenario 3: AI Disclosure Challenge Your security team deploys an AI tool that discovers 200 SQL injection vulnerabilities across 15 different open-source projects your organization uses. These are all in upstream dependencies, not your code.

1. How do you prioritize which to report first?
2. Do you report to each project individually, or coordinate through CERT/CC?
3. How do you handle attribution in the CVE records?
4. What if some projects are unmaintained and no one responds?
5. How do you manage the volume without overwhelming your own team?

---

References

• CIS Controls v8, Safeguard 16.2: Software Vulnerability Reporting and Response
• CISA Secure by Design Goals 5 and 6
• ISO/IEC 29147:2018 — Vulnerability Disclosure
• ISO/IEC 30111:2019 — Vulnerability Handling Processes
• CERT/CC Guide to Coordinated Vulnerability Disclosure (SEI-2017-SR-022)
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt)
• FIRST CVSS v4.0 Specification
• Google Project Zero Disclosure Policy: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html
• CISA Vulnerability Disclosure Policy Template: https://www.cisa.gov/vulnerability-disclosure-policy-template
• OASIS CSAF 2.0: https://oasis-open.github.io/csaf-documentation/

Study Guide

Key Takeaways

1. VDP is a requirement, not optional — CIS 16.2, CISA Secure by Design Goal 5, and ISO/IEC 29147 all mandate a published policy.
2. Safe harbor is the foundation of researcher trust — Without explicit legal protections, researchers will not report vulnerabilities to you.
3. 90-day disclosure timeline is the industry standard — Google Project Zero established it; balances vendor time with public safety; hard deadline prevents indefinite delay.
4. CVE assignment is a vendor responsibility — CISA Goal 6 requires timely CVE issuance including internally discovered vulnerabilities with CWE classification.
5. Bug bounty programs are a force multiplier — External researchers find what internal testing misses; Critical rewards typically $5K-$50K+.
6. AI is transforming vulnerability discovery volume — AI can generate hundreds of reports per day; disclosure processes must adapt to this scale.
7. VEX communicates exploitability status — Tells SBOM consumers whether a dependency vulnerability actually affects a specific product.

Important Definitions

Term	Definition
CVD	Coordinated Vulnerability Disclosure — structured process for reporting, remediating, and disclosing vulnerabilities
VDP	Vulnerability Disclosure Policy — public document defining how to report vulnerabilities and what to expect
Safe Harbor	Legal protections for good-faith security researchers; organization will not pursue legal action
security.txt	File at /.well-known/security.txt per RFC 9116 with security contact information
CNA	CVE Numbering Authority — organization authorized to assign CVE IDs; 400+ worldwide in 2026
VEX	Vulnerability Exploitability eXchange — communicates whether a vulnerability in a dependency affects a product
CSAF	Common Security Advisory Framework — OASIS standard for machine-readable security advisories
Full Disclosure	Publishing vulnerability details publicly with no advance vendor notice
ISO/IEC 29147	Standard for vulnerability disclosure — receiving and publishing vulnerability information
ISO/IEC 30111	Standard for internal vulnerability handling processes once reports are received

Quick Reference

• VDP Response Timeline: Acknowledge 5 business days, Initial triage 10 business days, Monthly updates, Fix varies by severity
• Disclosure Timelines: Google Project Zero 90 days (+14 grace), ZDI 120 days, CERT/CC 45 days
• Bug Bounty Rewards: Critical $5K-$50K+, High $2K-$15K, Medium $500-$5K, Low $100-$1K
• CVE Record Fields: ID, description, affected versions, references, CWE, CVSS score
• Common Pitfalls: No safe harbor provisions, no published VDP, ignoring researcher reports, delayed CVE assignment, not becoming a CNA

Review Questions

1. Draft a complete safe harbor provision for a VDP that aligns with DOJ’s 2022 CFAA enforcement policy.
2. A researcher plans to present a critical OAuth vulnerability at a conference in 45 days — how do you negotiate a timeline extension?
3. Your AI tool discovers 200 SQL injections across 15 open-source projects — how do you prioritize, coordinate, and handle attribution?
4. What is the difference between coordinated disclosure and full disclosure, and what is the industry consensus on which is preferable?
5. Design a phased implementation roadmap for building a CVD program from zero, including VDP, CNA application, and bug bounty launch.