Who does what in coordinated disclosure: the five roles

Coordinated vulnerability disclosure involves finders, vendors, coordinators, deployers and policy makers. The CERT Guide defines it as gathering information from finders, coordinating sharing among stakeholders, and disclosing vulnerabilities and mitigations to stakeholders including the public. Most failures happen at handoffs between these roles.

The five roles

The CERT Guide to Coordinated Vulnerability Disclosure names these roles:

1. Finders or researchers, who discover vulnerabilities.
2. Vendors, who produce fixes. Vendor PSIRTs, product security incident response teams, handle this work.
3. Coordinators, who manage sharing of information between parties. The CERT Coordination Center is the example the guide gives.
4. Deployers, organizations that run the affected software and need a way to reduce risk.
5. Policy makers, who write disclosure policy.

One person can fill several roles. A developer who finds a bug in a library they use is a finder and a deployer.

What each role owns

Finder: a clear report, an honest publication plan, and patience. See what to put in a report.

Vendor: acknowledge, validate, fix, and publish an advisory. See advisory contents.

Coordinator: reach the right vendor, keep the timeline, and mediate. CISA's public process lists tracking the timeline and mediating between reporter and vendor when needed, among its coordination tasks.

Deployer: keep an inventory, watch advisories for what you run, and apply fixes or mitigations. This is the role people forget, since it comes last. See the four patching scenarios.

Where it breaks

• The finder cannot find a contact, and the report is never read. See reporting to a vendor with no contact.
• The vendor fixes quietly and the advisory is vague, so deployers do not know they are affected.
• Multiple vendors share a component, and no one coordinates the release.
• Deployers learn about the issue from the news, not from their own monitoring.

What deployers can do

Since the deployer sits at the end, small steps help most:

1. Know what is in your software. An SBOM gives you the list.
2. Subscribe to advisories for your key components.
3. Decide in advance how fast you respond to each severity.
4. Record decisions, including when you choose to wait.

Safeguard's SBOM and dependency scanning, zero-day discovery and reachability analysis support the deployer role for code you ship. Autonomous remediation, which opens fix pull requests, is off by default.

Handoffs worth writing down

Agree in advance who sends the first message, who confirms receipt, and who publishes the advisory. Name a backup for each. When a finder reports to a vendor, the vendor should say within a short, stated time that it has the report. When a coordinator is involved, the vendor and finder should both know whether the coordinator or the vendor owns the public advisory, and whether a CVE ID will be requested by the vendor or by the coordinator.

Deployers can ask vendors the same question: where will you publish advisories, and how will we be told? If the answer is vague, build your own monitoring for the product.

A note on timelines

The CERT page referenced here does not state a default timeline. Different groups use different clocks, from 90 days to a few days. See disclosure deadlines compared.

Quick check

Sources

• CERT Guide to Coordinated Vulnerability Disclosure
• CISA Coordinated Vulnerability Disclosure process

Last reviewed: 19 October 2026.