Week 9: Coordinated Vulnerability Disclosure

The CERT/CC + ISO/IEC 29147 framework. You draft a disclosure-ready report for a hypothetical novel finding. The format becomes the template for the capstone report.

Theme

Coordinated vulnerability disclosure (CVD) is the framework that turns a researcher's finding into a vendor's patch. The framework's existence is the difference between an industry where bugs get fixed quietly under coordination and an industry where bugs get traded in markets the defenders cannot see.

The framework's discipline is documented in two main references: CERT/CC's CVD Guide (the industry-practitioner document; free at vuls.cert.org) and ISO/IEC 29147 (the international-standards document; ISO; abstract free, full text purchasable). Both describe the same workflow: researcher discovers; researcher reports to vendor; vendor acknowledges and works toward patch; researcher and vendor coordinate timing of public disclosure; public disclosure happens with the patch or after an embargo expires.

The week's lab drafts a CERT/CC-grade disclosure report for a hypothetical novel finding (not the SB6141 CSRF; that one was disclosed in 2015). The hypothetical lets you practice the writing without the political pressure of an actual coordination. The format is what matters; the same structure becomes the capstone report in Week 12-13.

The discipline of CVD writing has three properties:

• Reproducibility. Another researcher reading the report can reproduce the finding on their own authorized lab target without asking you a question.
• Defensibility. The negative-scope section makes explicit what the report does NOT do; the report cannot be misread as an exploitation guide.
• Vendor-actionability. The remediation and mitigation sections give the vendor a starting point for the fix and the operator a starting point for risk reduction.

By the end of Week 9 you have drafted a CVD report with all 12 required sections; you understand the CVD timeline (notification, embargo, publication); you have a template you reuse for the capstone.

Schneier weave (~280 words, A Hacker's Mind Ch 15)

Schneier devotes Chapter 15 of A Hacker's Mind to the question of how systems coordinate trust between adversarial parties. His worked examples include the international postal system (where every country honors stamps from every other country despite the absence of an enforcing world authority), the inter-bank settlement system (where banks transact across jurisdictions despite each being subject to different national regulators), and the certificate-authority web (where browsers trust certificates issued by hundreds of CAs despite the trust being effectively unverifiable). The pattern: coordination between adversarial-or-indifferent parties requires shared procedures more than it requires shared values.

CVD is the same pattern applied to security research. The researcher and the vendor are not adversarial in goals (both want the bug fixed) but their incentives diverge on timing (researcher wants credit; vendor wants quiet patch). The CVD framework's purpose is to coordinate the timing without depending on goodwill: the embargo is a contractual mechanism; the publication-after-embargo is a default that creates pressure for the vendor to engage; the CVE number is a third-party identifier that anchors the conversation independent of either party.

The implication for the disclosure writer is that the report is the artifact that operates within this coordinated system. The report is read by the vendor (who needs to fix); by NVD analysts (who score it); by other researchers (who learn); by operators (who decide on mitigations); potentially by regulators (who develop policy). Each audience has different needs; the report's structure honors all of them.

Schneier's broader argument is that the discipline of writing for a multi-audience coordinated process is the discipline that distinguishes professional disclosure from drama. ADV-101 teaches the discipline directly because the capstone deliverable IS a disclosure report.

Reading list (~1 hour)

1. Schneier, A Hacker's Mind, Ch 15 ("Hacking Coordination"). Academy library; calibre id 677.
2. CERT/CC Coordinated Vulnerability Disclosure Guide at https://vuls.cert.org/confluence/display/CVD/. Read in full; ~30 pp; the practitioner document.
3. ISO/IEC 29147:2018 abstract at https://www.iso.org/standard/72311.html. The international-standards reference; abstract is free; the full text is purchasable; the abstract is sufficient for course needs.
4. Three published CERT/CC vulnerability notes (your choice; browse https://www.kb.cert.org/vuls/). Read three notes that cover different bug classes (one CSRF-class; one buffer-overflow; one logic-bug). Notice the format consistency and the per-CVE variation.
5. A bug-bounty disclosure example. Yaworski's Real-World Bug Hunting Ch 1-3 (academy library calibre id 47). Read for the reproduction-narrative voice.

Lecture outline (~50 min)

Part 1: The CVD timeline (10 min)

• T-0: Researcher discovers. Internal to the researcher's lab.
• T+0: Researcher notifies vendor. First contact; provides initial information; requests acknowledgment.
• T+0 to T+7 days: Vendor acknowledges. Within a few days; researcher follows up if no response.
• T+7 to T+90 days: Coordination phase. Vendor investigates; develops patch; researcher provides additional info on request. The 90-day window is industry default (Google Project Zero pioneered; CERT/CC adopted).
• T+90 or earlier: Public disclosure. Either coordinated with vendor patch release (preferred) or after embargo expires (default if vendor unresponsive).
• T+disclosure: CVE assignment. MITRE or NVD or sometimes the vendor assigns a CVE number; the number becomes the canonical identifier.
• Variations. Some industries (medical devices; ICS / SCADA) have longer embargoes (180+ days; even years). Some bugs need shorter (active exploitation in the wild).

Part 2: The CERT/CC report sections (20 min)

The CERT/CC vulnerability-note format has 12 sections. The lab's template:

1. Title. Single sentence. Names the product + the vulnerability class. Example: "Motorola SB6141 cable modem allows cross-site request forgery in administrative interface."
2. Summary. ~200 words. Plain English. What is the vulnerability; what can an attacker do; what is the impact; what does the vendor need to fix.
3. Affected products and versions. Specific product names; specific firmware version ranges. If unknown, say so.
4. Vulnerability description. ~500 words. The technical mechanism in detail. Cite the underlying CWE category.
5. Reproduction steps. Numbered; exact; reproducible. Include the HTTP requests verbatim; include the expected responses; include the observed effect.
6. Proof-of-concept code reference. Point to the tool's repository (or attached transcript). Note the safety controls.
7. CVSS v3.1. Vector + score + per-metric justification (from Lab 8 for SB6141; for the hypothetical finding, you score from scratch).
8. Remediation (vendor-side). What would fix this in the vendor's product? Specific. Cite the underlying CWE's standard remediations.
9. Mitigation (operator-side). What can affected operators do today (pre-patch) to reduce exposure?
10. Negative-scope statement. What the report does NOT do. The protection for the researcher.
11. Disclosure timeline. When did the researcher discover; when notify vendor; when publish.
12. References. CERT/CC link; vendor advisory link; researcher's blog if applicable; CVSS calculator URL; relevant CWE links.

Part 3: The Negative-Scope discipline (10 min)

• Why the negative-scope matters. A report can be read as instructions. The negative scope makes explicit "this is NOT an exploitation guide."
• What the negative scope typically excludes.
  • Post-exploitation: persistence, lateral movement, data exfiltration
  • Chaining: combining the bug with other vulnerabilities
  • Targeting: identifying victim devices in the wild
  • Weaponized payloads beyond the minimum required for reproduction
• Sample negative-scope language. "This report demonstrates the reproduction of the vulnerability on an authorized lab target. It does NOT demonstrate post-exploitation activities; it does NOT chain with any other vulnerabilities; it does NOT identify deployed instances of the vulnerable device; it does NOT include weaponized exploit code beyond the minimum required to demonstrate the vulnerable behavior. The reproduction was conducted under written authorization (see lab portfolio reference) on academy-owned or self-purchased hardware in an isolated lab network."
• Why this protects you. A defense attorney facing a hypothetical CFAA prosecution of academy work would point to the negative-scope as the explicit boundary of the research. "The researcher did NOT do these things, and the report documents that."

Part 4: The vendor-response failure modes (10 min)

• Vendor responds promptly. Best case; coordination proceeds.
• Vendor responds slowly. Researcher escalates: another email; CERT/CC mediation request.
• Vendor does not respond. After ~30 days of silence, the researcher proceeds with publication. The CVD framework defaults to publication.
• Vendor refuses to acknowledge. Researcher publishes anyway. The vendor's refusal is itself a story; the disclosure report can note "vendor refused to acknowledge despite N attempts."
• Vendor threatens legal action. Researcher consults the EFF Coders' Rights Project (https://www.eff.org/issues/coders); some jurisdictions have specific safe-harbor statutes for security research. The DMCA §1201 anti-circumvention exemption for security research (triennially renewed) is the U.S. safety valve.
• End-of-life vendor. No patch is coming. The disclosure helps operators decide on mitigation; the disclosure helps competing products learn from the failure. SB6141 falls in this category.

Disclosure-Ethics Sidebar

The CVD framework is the system that turns a finding into a fix. The discipline of writing within the framework is the discipline that lets the framework do its work.

Labs (~3 hr)

Lab 9: CVD Disclosure Draft (labs/lab-9-cvd.md)

• Goal: draft a CERT/CC-grade disclosure report for a HYPOTHETICAL novel finding (not the SB6141 CSRF; you make up a plausible vulnerability and write it up as if it were real)
• Time: ~3 hr
• Artifact: lab-9/disclosure-report.md in ~/adv-101/lab-9/

Independent practice (~5 hr)

1. Read five CERT/CC vulnerability notes from the last six months (1.5 hr). Browse https://www.kb.cert.org/vuls/. Pick five notes covering varied bug classes. Note the format consistency.
2. Read three bug-bounty disclosure reports (1 hr). HackerOne's public disclosure feed at https://hackerone.com/hacktivity?type=public. Bug-bounty disclosures are more narrative and less formal; compare to CERT/CC style.
3. Draft a 200-word negative-scope statement (45 min). Generic; not for a specific bug. The exercise: how do you frame "what this report does NOT do" so it protects without being defensive?
4. Schneier A Hacker's Mind Ch 16 (45 min). Continues the coordination theme; bridges to Week 10 ethics.
5. EFF Coders' Rights Project tour (45 min). At https://www.eff.org/issues/coders. The specific resource for security researchers facing legal pressure; bookmark.

Reflection prompts (~30 min)

1. The SB6141 is end-of-life. The CVD framework default is "publish if vendor unresponsive." How does end-of-life change the calculus?
2. Your Lab 9 hypothetical finding is your invention. Did writing it up surface design choices a real disclosure would face? Name two.
3. The CVSS score is in the report. Suppose your score is 8.3 and the vendor's score is 5.5. How do you handle the divergence in the report?
4. The negative-scope statement protects the researcher. Does it ALSO constrain the researcher's future work on this CVE? In what way?
5. One thing from this week you want to know more about?

Adversary Diary (Week 9)

New entries:

• CERT/CC CVD Guide at https://vuls.cert.org/confluence/display/CVD/.
• ISO/IEC 29147 abstract at https://www.iso.org/standard/72311.html.
• HackerOne public disclosure feed at https://hackerone.com/hacktivity?type=public.
• EFF Coders' Rights Project at https://www.eff.org/issues/coders.
• MITRE CWE list at https://cwe.mitre.org/data/index.html. The vulnerability-class taxonomy you cite in disclosure reports.

What would a reviewer ask?

1. "Your report's negative scope is two paragraphs. Walk me through how a defense attorney would use this in a hypothetical CFAA case."
2. "The vendor refused to acknowledge your hypothetical finding for 90 days. What's in your report's disclosure-timeline section?"
3. "Suppose your CVSS score is in the cohort middle (e.g., 7.0) and the vendor scores 4.0. How does the report present the disagreement?"

What comes next

Week 10 is ethics. CFAA, DMCA §1201, state-law variation, SDVOSB engagement rules. The lab is a 2-page personal ethics statement covering each. Week 10 closes the documentation arc (Weeks 8-10); Weeks 11-13 are capstone work.