First Contact: The Critical Hours Between Disclosure and Patch

The advisory is embargoed, the reporter is waiting, and somewhere a maintainer's phone is buzzing. What happens next — in the first day after a critical vulnerability is disclosed — determines whether a project suffers an incident or a catastrophe.

We reviewed postmortems, mailing list archives, and published incident timelines from several high-profile open-source responses, including the log4shell aftermath and the xz-utils disclosure window. The pattern that emerges is remarkably consistent: projects that fare well don't move faster. They move in a pre-decided order.

Hour Zero: Verify Before You Panic

The first mistake is also the most common — treating the report as confirmed fact. Every experienced security responder we spoke with described the same opening move: reproduce the vulnerability in isolation before saying anything to anyone.

This step looks slow. It isn't. A false positive that escalates to a GitHub Security Advisory wastes the project's credibility and burns goodwill it will need later. Conversely, a report that sits unverified for twelve hours because a maintainer assumed someone else would look at it is how weekend incidents become week-long ones.

The projects with mature processes maintain a private channel — a security mailing list or a restricted advisory draft — where the reporter and the core team can talk without the world watching. If that channel doesn't exist when the CVE drops, building it under pressure is where hours disappear.

Hours Two Through Eight: The Triage Conversation

Once the bug is confirmed, three decisions dominate, and each one has a cost:

Severity calibration. Is this critical because it is genuinely exploitable, or because the reporter's scanner scored it an 9.8? Overstating severity triggers unnecessary emergency upgrades across thousands of downstream consumers. Understating it leaves real systems exposed. The honest answer, arrived at calmly, beats the dramatic one.

Fix scope. The minimal patch that closes the hole is rarely the fix the maintainer always wanted to write. Discipline here means shipping the small change now and deferring the refactor. Postmortems repeatedly show that "while we're in there" edits are where regressions — and second incidents — come from.

Backport map. Which released versions receive a fix? Every active branch still deployed in the wild deserves an answer, even if the answer is "no patch, upgrade or mitigate." Projects that publish an explicit support matrix during an incident get fewer angry issues than projects that go quiet and hope people figure it out.

The Advisory Is a Product

A recurring theme across postmortems: the code fix is rarely the thing users judge. The advisory is.

A good advisory, published through GitHub Security Advisories or a coordinated CVE disclosure, answers four questions in the first paragraph: what's broken, who's affected, what's the workaround, and when is the patch coming. Everything else — root cause analysis, credits, commit hashes — can follow.

The teams that handled their worst days best treated disclosure as a release engineering task, not a communications task. They drafted the advisory alongside the patch, tested the upgrade path on a real deployment, and coordinated timing with major downstream packagers — the Debian security team, Red Hat's product security, the Homebrew maintainers — so ecosystem-wide fixes landed in the same news cycle rather than trailing by days.

Hour Twenty-Four: The Part Everyone Forgets

By the end of the first day, most teams are exhausted and tempted to declare victory. The postmortems say otherwise. The highest-leverage remaining work is unglamorous:

• Publishing the fixed release to every distribution channel the project has ever used, including the ones the maintainers forgot about
• Monitoring issue trackers for upgrade failures, which surface within hours and often reveal that the patch broke a legitimate use case
• Writing down, while memory is fresh, what the team wishes had existed before the disclosure — the runbook, the private channel, the support matrix

That last item is the entire thesis. Projects that respond well to their first CVE do so because someone, in a calm moment, wrote down what to do. If your project doesn't have a security policy file and a private reporting channel today, that's the fix worth shipping this week — before you need it.