Skip to main content

Coordinator Model

1. Purpose​

This document defines what PCL means when it acts as a vulnerability disclosure coordinator or publication intermediary.

The coordinator role is deliberately limited. PCL may reduce communication, evidence, and publication risk; it does not become the owner of the affected system, the reporter’s lawyer, the vendor’s agent, or the authority that retroactively approves research conduct.

2. What PCL May Do​

PCL may:

  • receive and screen reports;
  • help reporters remove unnecessary sensitive data;
  • assess whether a report is mature enough for vendor coordination;
  • contact a vendor or maintainer through an appropriate channel;
  • refer a case to a CERT, CNA, platform, regulator, or maintainer group when appropriate;
  • draft sanitized advisories or reports;
  • maintain a coordination timeline;
  • publish public artifacts after review;
  • decline unsafe or unauthorized material.

3. What PCL Does Not Do​

PCL does not:

  • authorize testing of third-party systems;
  • provide legal representation;
  • promise legal protection;
  • guarantee vendor response;
  • guarantee CVE assignment;
  • guarantee bounty eligibility;
  • host exploit code;
  • pressure vendors through public shaming;
  • publish unreviewed researcher allegations;
  • act as a marketplace for vulnerabilities;
  • accept responsibility for unauthorized reporter conduct.

4. Case Acceptance Criteria​

PCL may accept a coordination case when the following are sufficiently clear:

  • affected party;
  • reporter authorization basis;
  • technical claim;
  • evidence quality;
  • sensitive-data handling status;
  • likely user risk;
  • coordination channel;
  • publication objective;
  • reporter expectations;
  • legal or safety constraints.

A case may be rejected when any of those elements cannot be clarified safely.

5. Vendor Contact Posture​

Vendor contact should be specific, low-noise, and defensible. An initial vendor report should normally include:

  • who is contacting the vendor;
  • why the vendor is believed to be affected;
  • a short technical summary;
  • affected version or surface if known;
  • minimized evidence;
  • requested next action;
  • coordination contact;
  • planned follow-up interval;
  • reporter attribution preference.

Do not include irrelevant background, threats, public-disclosure ultimatums, bounty demands, or unnecessary exploit mechanics.

6. Multi-Party Coordination​

A case may need third-party coordination when:

  • multiple vendors are affected;
  • an open-source dependency is involved;
  • exploitation is active;
  • public safety or critical infrastructure may be affected;
  • the reporter and vendor cannot communicate safely;
  • no vendor contact exists;
  • a CVE, CNA, or CERT process is likely necessary.

PCL may refer the matter or participate in a coordination process. Referral should preserve confidentiality and minimize sensitive evidence.

7. Publication Posture​

PCL publication should serve defenders and affected users. Publication is not a punishment mechanism.

A public artifact should answer:

  • what is affected;
  • what risk exists;
  • what evidence supports the claim;
  • what remediation or mitigation exists;
  • what coordination occurred;
  • what uncertainty remains.

Publication should avoid material that primarily helps attackers or escalates conflict.

8. Conflicts and Independence​

PCL should disclose or avoid conflicts that would materially affect credibility. Relevant conflicts may include employment, consulting relationships, vendor sponsorship, personal disputes, bounty eligibility, or prior participation in the affected project.

When conflict cannot be avoided, the case should receive independent review or be referred out.

Authorization Boundary​

Only the responsible system owner can authorize testing of a third-party system. PCL review, coordination, or publication does not create or expand that authorization.