Vulnerability Disclosure

---
name: vulnerability-disclosure
description: Receive, triage, fix, and announce security reports on a coordinated timeline that protects users. Use when running a project that could have security issues, or when you receive a report.
---

# 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.