Vulnerability Disclosure

Vulnerability disclosure

A security report is a gift with a clock on it. The reporter has something users need fixed, and how you handle the first day decides whether researchers keep telling you or publish instead.

Method

1. Publish a private reporting path and honour it. A security policy naming where to report and what to expect, kept off the public tracker so a report does not disclose itself (see issue-triage).
2. Acknowledge quickly, assess honestly. Confirm receipt within days, then evaluate exploitability and impact rather than dismissing or catastrophising (see vulnerability-triage).
3. Agree a timeline with the reporter. A fix window with a disclosure date, adjusted for severity and complexity. Silence is what pushes researchers to publish unilaterally.
4. Fix on a private branch and prepare the release. Patch, tests, advisory text, and affected version ranges ready before anything public, since a public commit is an unannounced disclosure.
5. Publish an advisory users can act on. Affected versions, impact, the fixed version, and any workaround, in the ecosystem's advisory channel so scanners pick it up.
6. Credit the reporter as they prefer. Attribution is the currency of security research, and refusing it costs future reports.

Boundaries

• A disclosure process manages reports; it does not find vulnerabilities, which needs review and testing (see security-review).
• Embargo periods are a negotiation, not an entitlement, and reporters may publish on their own schedule.
• Coordinating across downstream distributors adds real time and should factor into the timeline for widely packaged projects.