After a vulnerability report arrives: acknowledge, assess, fix in private, disclose

Goal

Turn a private report into a fixed release and a public advisory without the details leaking before users can update, and without the reporter losing patience and publishing first.

Prerequisites

A reporting channel that is already published (security.txt or a SECURITY file, linked); a private place to develop a fix (a temporary private fork or a private advisory draft); the list of people who can publish a release; and, ideally, a CVE Numbering Authority contact identified in advance, as the OpenSSF guide advises. The OpenSSF guide states that in a small project of one to five maintainers, the maintainers themselves may be the vulnerability management team.

Steps

1. Acknowledge receipt before assessing anything. The OpenSSF guide says to do this quickly, within one to two days; GitHub's guidance says the same and adds that it sets the tone for the rest of the exchange.
2. Assess with the reporter's steps and versions. The guide's classification: working as intended, ordinary bug, feature request, or vulnerability, where a vulnerability compromises confidentiality, integrity or availability. Tell the reporter the outcome and why; a hardening suggestion is not a vulnerability and can move to a normal issue.
3. Agree an embargo period. The guide notes that reporters usually state one, that 90 days is the longest default entertained by the groups it lists, and that ongoing communication is what keeps reporters willing to extend.
4. Develop and test the fix privately; identify every affected version and which supported lines receive the fix. Keep the patch minimal so that updating is easy; do not bundle API changes.
5. Reserve a CVE identifier through the CNA and draft the description. Ask the reporter whether and how they want to be credited; the guide calls omitting credit inappropriate unless the reporter declines.
6. Pick a release day when people can update during working hours; the guide suggests Monday to Wednesday and avoiding widely observed holidays.
7. Release, then publish the advisory: affected versions, fixed versions, workaround if any, credit. GitHub's guidance stresses marking the release explicitly as a security fix so downstream consumers notice it.
8. Record the timeline (report, acknowledgement, fix, disclosure) for the next review of the process.

Expected result

The reporter receives dated answers at every step; users learn about the issue from the project's own advisory and a fixed release at the same time.

Limits and test basis

Steps and time windows are taken from the cited guides; no incident is described and no timing is measured. Projects with distributors may need an embargo list, which the OpenSSF guide treats as optional and costly.

Publish the advisory with the release

Once the fix is pushed to a public branch, the diff discloses the vulnerability to anyone reading commits, and for a library the published advisory is what triggers dependency-scanner alerts in downstream projects. Write the advisory in full during the private fix phase: affected versions, fixed versions, workaround, credit as agreed with the reporter. Then publish the release and the advisory as one step, minutes apart at most, preferably from one script that tags, uploads the package and publishes the advisory. The only ordering constraint is that the advisory must not name a fixed version before it is installable.