A vulnerability report needs a coordination plan.

What is coordinated vulnerability disclosure?#

Coordinated vulnerability disclosure, or CVD, is the process of communicating a suspected security weakness to the people able to investigate it, agreeing useful follow-up, and preparing information that supports remediation. It is not simply sending an email or publishing a technical finding. A report can be acknowledged without being validated; a fix can be released without reaching every affected installation; and a public explanation can be accurate while still exposing information that should have remained private.

Separate four questions at the outset: who may receive the report, who may authorize testing, who owns the remediation decision, and who should receive subsequent public information. One organization may perform several roles, but the decisions remain distinct. This guide proposes a practical engineering workflow rather than a universal deadline or legal safe-harbor policy. It applies to authorized assessments and careful handling of incidental discoveries, not to continued investigation of systems you have no permission to examine.

Find the right channel without expanding the test#

A reporting channel tells you where to send information; it does not tell you which experiments you may perform. RFC 9116 specifies security.txt for publishing contact and disclosure information. For web services, the standardized location is /.well-known/security.txt over HTTPS. Contact and Expires are required fields. The file does not imply testing permission, and its host scope does not automatically extend to parent domains or subdomains.

Read the linked policy and confirm the recipient before transmitting sensitive material. In an existing engagement, use the agreed escalation path even if a public mailbox is also available. For an incidental observation, record the minimum context needed to describe what happened and pause. Ask the owner to validate further behavior or establish an explicit scope. An unanswered message is a communication problem, not additional authority. A redirect, stale contact or unexpected encryption key warrants verification through an independently established channel before sharing details.

Write a report another engineer can verify#

A verifiable vulnerability report identifies the affected component and version, expected security boundary, observed deviation, relevant environment and minimal evidence. CERT/CC's reporting guidance supports providing enough technical context for a recipient to investigate. The useful distinction is between describing a consequence and asserting a consequence you have not demonstrated. A response containing another test tenant's fixture supports a specific isolation finding; it does not establish access to every tenant or prove that production records were exposed.

Organize the report around a short claim followed by evidence and uncertainty. State what identity was used, what permission it should have had, what synthetic object was involved, and which observation contradicted the intended policy. Include timestamps, request identifiers and sanitized screenshots when they help an owner locate the event. Keep authentication tokens and customer records out of the report. If an exact reproduction requires sensitive details, describe the dependency privately and agree how the owner will validate it rather than distributing an unrestricted evidence bundle.

Choose a response path based on evidence and ownership#

Treat coordination decisions as explicit transitions, not automatic reactions to a severity label. Ask whether the owner can reproduce the observation, whether a deployment is actually affected, and whether another party maintains the relevant component. The following table is a proposed planning aid. It deliberately avoids fixed publication periods because urgency, available mitigations, active incidents and downstream distribution can materially change the decision.

Record an owner and next review point for every unresolved transition. A vendor may need to distinguish a product defect from a local configuration issue before assigning engineering work. A researcher may need to explain why a test fixture represents a real boundary. Those questions should narrow uncertainty without prompting additional unapproved access. If communication stalls, document the attempts and consider a suitable coordinator; do not assume that every coordinator accepts every category of report.

Keep coordination operational, not performative#

FIRST's multi-party guidance addresses communication among finders, vendors, coordinators and other stakeholders. Its relevance is the need to manage expectations across participants, not a universal timetable that can be applied without context. In practice, a coordination record should show the report identifier, acknowledged recipient, current technical understanding, open questions and the next agreed update. Track technical validation separately from acknowledgement so an automated receipt does not become apparent confirmation.

Use dated updates that report changes rather than repeated requests for status. If a mitigation is available, ask what it protects and what remains affected. If a retest is requested, identify the version, environment, permitted identities and desired evidence. Multi-party cases need clear information-sharing limits: one recipient's permission to receive sensitive details does not authorize unrestricted forwarding. Agree how participants will resolve publication disagreements and which operational contact can respond if an urgent safety concern emerges while the ordinary remediation work continues.

Fictional worked example: a test-tenant export issue#

Consider the fictional product Harbor Desk, a support platform with an explicitly authorized staging assessment. The assessment owner provides two test tenants, North and South, containing only invented support records. During an ordinary export check, a North operator receives an export row labelled with a South fixture identifier. The assessor stops that line of testing after preserving the single synthetic row, the event time and the non-secret export request identifier. No production account or additional tenant is inspected.

The initial report says: a North staging identity received one South test record through the export workflow. It names the tested build, intended tenant boundary and fixture identifiers. It explicitly does not claim that production is affected or that all exports bypass authorization. The owner verifies the observation in its own staging logs and identifies an export worker that trusted a tenant identifier from an earlier queued job without rechecking the requesting principal. This causal explanation is fictional; it illustrates how minimal evidence can support investigation without expanding assessment authority.

Fictional worked example: remediation, retest and communication#

Harbor Desk's proposed correction checks the principal, tenant and export resource together when the worker executes. The team also reviews whether already queued jobs need cancellation or revalidation. A staging regression uses the same two fixtures: North can export North's record, North cannot export South's record, and a denied export produces no artifact containing South's data. The assessor receives a narrow retest authorization for the changed worker and these cases; approval does not extend to unrelated reporting features.

The owner then determines which released versions contain the same worker behavior and whether its deployment controls reduce exposure. That is an owner-led investigation, not a claim inferred from the staging test. Participants draft a publication account describing the boundary, affected conditions they actually verified, remediation and remaining unknowns. Sensitive logs stay in the agreed evidence channel. The fictional exercise is complete only when the scoped verification and communication decisions are recorded; a merged patch alone would leave the deployment and publication questions unanswered.

Publish information that helps defenders act#

A useful disclosure account explains what boundary failed, which conditions or versions are known to be affected, what mitigation or update is available, and what the investigation did not establish. CERT/CC distinguishes public awareness from the work of getting remediation deployed. Publishing a technically accurate description does not by itself ensure that the right operators learn of the issue or apply a correction. Choose distribution channels around the audience that can take action, not just the audience that will read a dramatic headline.

Before publication, compare the draft against the private record. Remove secrets, private identifiers, unnecessary operational details and evidence beyond the agreed release. Use conditional language for unverified downstream impact. Identify fictional demonstrations as fictional and laboratory observations as laboratory observations. Attribution and acknowledgement should follow the participants' agreement where possible, but neither substitutes for technical accuracy. A short, bounded explanation with clear defender actions is more useful than an impressive account that leaves readers guessing about affected deployments.

Verification checklist, limits and next steps#

Start by reviewing one report template and one escalation path with the people who will use them. Run a tabletop exercise using a synthetic finding, not a live third-party weakness. Check whether an on-call engineer can locate the evidence, understand the claim, identify the authorizing owner and explain the next decision. Rehearse an unreachable contact and a disagreement over impact so the process does not depend on a perfectly cooperative scenario.

Coordination cannot guarantee a particular response time, legal protection, complete remediation or safe publication. Product ownership may be distributed, evidence may remain incomplete and different stakeholders may reasonably prioritize risks differently. Preserve those limits in the record. The next useful improvement is usually a clearer handoff or a better validation contract, not a larger evidence collection. Treat permission, confidentiality, remediation and communication as continuing responsibilities throughout the case.

• Confirm the current policy, recipient and secure evidence channel before sending details.
• State the authorized environment and separate observation, interpretation and unknown impact.
• Keep minimal sanitized evidence and an agreed retention or deletion plan.
• Record acknowledgement, validation owner and next update as separate events.
• Obtain specific retest authority for the changed version and behavior.
• Review affected downstream participants before setting a publication plan.
• Check that public wording gives defenders an action without exposing private material.