Coordinated Vulnerability Disclosure: Track the Handoff

Coordinated vulnerability disclosure is the process of communicating a security issue to the responsible organization and managing the response before broader publication. A good report is only the beginning. The handoff also needs a verified recipient, scope, follow-up plan and careful treatment of affected users.

CISA's 2020 announcement of a federal vulnerability-disclosure directive describes the requirement for covered US federal agencies to publish disclosure policies. That requirement should not be generalized to every private business worldwide. For your target, read its actual policy and applicable requirements before testing or reporting.

Verify authorization and scope first

A public website is not automatic permission to perform every security test. Look for an official disclosure policy, program scope and contact channel. Check what testing is permitted and what is excluded.

If scope is unclear, seek clarification through the designated route before continuing. Do not rely on a copied policy from another organization or a third-party directory when the owner provides more specific instructions.

Record the policy version or review date. A researcher should be able to explain the permission and boundaries used during the work, especially if the organization changes its program later.

Keep evidence proportionate

Collect enough evidence to explain the issue without unnecessarily accessing other people's data. Use your own test accounts and controlled examples where possible.

Do not expand the test merely to make the report more dramatic. A minimal demonstration can establish a boundary failure without extracting a large dataset or interfering with service.

Keep sensitive findings restricted. Screenshots, tokens and internal URLs can expose affected systems if shared carelessly. Redact irrelevant personal information while retaining the context needed by the recipient to reproduce the issue.

Send through a verified channel

Use the official program or security contact. Confirm that the domain and destination belong to the organization before sending sensitive details. An unverified address supplied in a random comment is not an adequate disclosure path.

For the report structure itself, use the separate security bug-report guide. This article focuses on managing the handoff, so the report should remain concise and attached to a clear communication record.

Include how the recipient can contact you and whether you have any planned public communication. Avoid threats or pressure tactics. A cooperative process is more likely to keep the discussion centered on protecting users.

Track acknowledgments and follow-ups

Create a private timeline with submission date, acknowledgment, questions, remediation information and verification outcome. An automated receipt is evidence that the system accepted a submission, not proof that an engineer has assessed it.

Follow the program's stated timelines where available. If no response arrives, use a reasonable follow-up through the same verified channel. Do not invent a universal deadline that every organization is legally required to meet.

Keep messages factual. “I have not received an acknowledgment” is different from “the company refuses to fix the issue.” The first describes what you observed; the second adds a motive you may not know.

Agree on safe verification

When the organization reports a fix, confirm whether you are authorized to retest and under what conditions. Use the smallest approved test that addresses the original finding.

A blocked demonstration does not always establish that every variant is resolved. State exactly what you checked. If further investigation is needed, communicate that limitation rather than declaring either complete safety or total failure.

For a fictional authorization issue, retesting might use the same two controlled accounts from the original report. Do not switch to unrelated real users simply to gain additional evidence.

Coordinate publication carefully

Public disclosure can help users understand risk and remediation. Its timing and content should consider the program, unresolved exposure and any applicable obligations.

Separate technical explanation from sensitive operational detail. A useful advisory can describe impact, affected conditions and mitigation without publishing credentials or unnecessary personal records.

If the report involves disputed facts, describe the disagreement accurately. Do not claim a vendor confirmed severity, exploitation or a root cause unless its response actually supports that statement.

Preserve a useful final record

Keep the original report, communication timeline and verified outcome in a controlled location. Note remaining questions and the limits of any retest. This record is valuable to both the reporter and the organization when similar issues appear later.

Duck Cloud's text utilities can help compare sanitized draft advisories. They do not provide legal authorization or determine when disclosure is appropriate.

If communication moves to another channel, verify the new contact through the original official route. A sensitive finding should not be redirected to an unknown recipient merely because a message requests it.

Conclusion

Manage vulnerability disclosure as a careful handoff, not just a message with an exploit attached. Verify scope and recipient, collect proportionate evidence and track the response. Clear coordination protects affected users while keeping the technical record accurate.