The polished version of a security disclosure — the kind that ends up on a vendor's blog or in a CVE database — looks clean. The bug was found, reported, fixed, and disclosed. Everyone behaves professionally. The end.
The actual version is messier. There are weeks of waiting. There are emails that go unanswered. There are arguments about CVSS scores. There are escalations to people who don't want to be escalated to. And then, at the end, there's a brief public moment when everyone agrees on the polished version and pretends the rest didn't happen.
I want to walk you through one of these timelines from the inside. The disclosure is real. The names are softened. The dates are shifted but proportional. If you've never coordinated a serious disclosure, this is what it actually looks like, day by day.
Day 0 — Monday morning
We find the bug during a routine review of a popular open-source library. It's a deserialization issue. Exploitable, reproducible in five minutes against the library's example code, affects every project that uses the library — which, based on download stats, is on the order of millions.
The first conversation is internal. Three of us in the office crowded around one laptop, taking turns trying to make the proof-of-concept not work. It works every time. We move from "is this real" to "is this as bad as it looks" to "this is as bad as it looks."
We start drafting the report.
Day 0 — Monday afternoon
We look up the project's security contact. The project has a SECURITY.md file in the GitHub repository. There's a PGP key. There's a security email. There's a 90-day disclosure expectation, which matches our default.
(About 60% of projects we report bugs to in the open-source ecosystem have this. The other 40% require us to dig through commit history, find the maintainer's email, and hope they read it. The 60% is a recent improvement; five years ago it was closer to 30%.)
We send the initial report. It contains: what the bug is, why it matters, the affected versions, reproduction steps, and a minimal proof-of-concept that demonstrates the bug without weaponizing it (we don't include "and here's how you turn this into RCE on every server running this library" in the first email).
The report says, in the last paragraph: "Our standard disclosure timeline is 90 days from this report (Date + 90). We're flexible if the fix is complicated, but we'd appreciate confirmation of receipt within five business days."
The clock has started.
Day 3 — Thursday
No response. This is normal. Open-source maintainers have day jobs. We've sent the report on a Monday; the maintainer probably triages security emails on weekends or holidays.
Day 6 — Sunday evening
We get an automated reply from the security email: "We've received your report and will respond within 7 business days." This is a good sign — the project has an actual triage process. About 70% of well-organized projects have something like this. The other 30% involve us wondering for a week whether the email got through.
Day 9 — Wednesday
The maintainer responds. They confirm they can reproduce the bug. They thank us for the careful disclosure. They acknowledge the 90-day timeline.
Their question is one we get often: "What CVSS score do you have for this?" We had given them our internal assessment (8.8, High) — they push back, saying the attack requires a specific configuration not all users have, which would drop the impact. We agree to revisit the CVSS together after they've scoped the affected versions more precisely.
This is not the conversation most security writing prepares researchers for. The disagreement about severity is normal and largely productive. We want the score to be defensible. They want it to be accurate. The middle is usually where both sides land.
Day 16 — Wednesday
Status update from the maintainer. They have a candidate fix. They want to test it against several edge cases before committing. They estimate two more weeks. This is fast — we've had vendors take six months on simpler fixes. We acknowledge and ask to be looped in on the patch when it's ready, so we can verify it actually addresses the bug.
Day 28 — Monday
The maintainer sends us a draft fix in a private branch. We review it. The fix is correct — it patches the original vector. We notice, in passing, that the same library has a second vector for a related attack class that the fix doesn't address. We flag it. The maintainer thanks us and adds it to the patch.
This is the part of disclosure that doesn't show up in the polished public version. The patch that ships is often better than the patch that would have shipped if the researcher hadn't kept reviewing.
Day 35 — Monday
The maintainer asks if we'd be willing to coordinate disclosure with two large downstream projects that they've informed privately. Those projects ship the vulnerable library and need time to update their own releases. Could we extend the 90-day deadline by two weeks to give them more time?
We agree. The new disclosure date is Day 104.
This is the negotiation that researchers and vendors fight about most often. Extending deadlines is reasonable when there's a specific downstream coordination need. Extending them because "we're not done yet" is what turns 90 days into 180 turns into never. Project Zero's strict 90-day policy exists specifically to prevent that drift.
Day 60 — Tuesday
One of the downstream projects has now patched their release. They publish a vague advisory ("we've shipped a security update — apply it") without naming the upstream library or the bug. This is the right move at this stage — they want their users to patch before the details are public.
We mention to the maintainer that we should coordinate the exact wording of the eventual public advisory so the various downstream notes align. Otherwise users get confused about which bugs they're patching for.
Day 78 — Saturday
A different security researcher — not us — publishes a blog post describing a bug in a different library that uses the same underlying class of vulnerability. They don't name our library. The community immediately starts asking which other libraries might be affected.
We email the maintainer: "We should probably accelerate." If a researcher with a similar finding asks the right question publicly, our bug might be re-discovered. The maintainer agrees. They commit to shipping the patch within 10 days regardless of the downstream coordination status.
Day 88 — Wednesday
The patched release ships. The release notes mention "security improvements" without details, as agreed.
The CVE has been requested through MITRE. Our advisory text is drafted. The maintainer's advisory is drafted. We've agreed on phrasing, on which acknowledgments go to whom, and on the embargo lift time.
Day 89 — Thursday morning
We discover, at 9am, that the patched release accidentally exposed the test cases for the bug in the public test suite. The test cases include a working proof-of-concept. The release was made public 12 hours ago.
We email the maintainer. They were not aware. They acknowledge that anyone who reads the test suite now has the exploit. The bug is now effectively public to anyone who looked at the diff.
This is the moment in every disclosure where the plan and reality diverge. We have to decide, in the next hour, whether to publish the full advisory today (giving defenders a chance to understand what they're patching) or stick to the originally planned date (Day 104, sixteen days from now) and pray nobody else notices.
We choose to publish today.
Day 89 — Thursday afternoon
We coordinate a rapid disclosure. Our advisory goes up at 4pm. The maintainer's goes up at 4:15. The CVE is published. The downstream projects who were still working on their own updates get our text and accelerate.
The advisory makes the front page of Hacker News by midnight. Several news outlets pick it up the next day. The bug is named, predictably, after some characteristic of how it works.
Day 90 — Friday
The volume of email is high. Other researchers want to know if they can write follow-up posts. Companies want to know if they're affected. A few angry users want to know why the patch isn't backported to their version (which is four major releases old).
The maintainer handles the technical questions. We handle the disclosure-process questions. We coordinate, at one point, to make sure we're not contradicting each other.
Day 95 — Wednesday
The bug is now in every security scanner's signature database. Vulnerability management teams at companies that use the library are getting alerts. Patch adoption is, based on download stats, at about 40% — meaning 60% of users are still vulnerable.
This is the part nobody talks about in disclosure articles. The patch shipping is not the end. The patch reaching users is the end. The gap between those two events is, in most disclosures, where the real-world risk lives.
Day 127 — Sunday
Patch adoption is at roughly 78%. The remaining 22% are users on old versions, users in environments without good update tooling, and users who just don't update. The maintainer and we have done what we can. The rest is on the ecosystem.
We close our internal tracking ticket on the disclosure. The post-mortem is short:
- Initial report was clear, which sped up the maintainer's response.
- Negotiating the CVSS score early avoided an argument later.
- Reviewing the patch caught a second related bug.
- The test-case leak on Day 89 was a process failure on the maintainer's side that we should have anticipated.
- The downstream coordination worked.
- The 22% of users who don't update is a problem nobody owns.
That last bullet is the one we keep coming back to.
What 127 days teaches you about disclosure
Reading the timeline back, the things that made the disclosure work were not glamorous. They were: a clear initial report, a documented timeline, responsive communication on both sides, mutual respect for the technical work, and a willingness to renegotiate when reality intervened. None of those are technical skills. They're practitioner-of-disclosure skills.
The things that nearly broke the disclosure: the test case leak, the parallel researcher publishing related work, the question of when to accelerate. Each one required a judgment call that the runbook doesn't quite cover. The runbook is the baseline. The judgment is what makes it work.
What this looks like for our clients
If you hire us and we find a bug in your application, the disclosure conversation is internal. There's no 90-day deadline. There's no public advisory. We report it to you, you fix it, we verify. The timeline is whatever your team's patch cadence is.
If we find a bug in a third-party library you depend on, we coordinate disclosure to the library maintainer with you in the loop. You get advance notice (often weeks before the public learns). You can patch before the world knows.
If we find a bug during research that affects many users — including you — we follow the timeline above, with you as one of the downstream coordinators. You get the patch before the public; you have time to plan.
The system protects you because you're connected to it. Researchers who don't have disclosure relationships sometimes leak too early. Vendors who don't engage well sometimes leak through their own processes. The companies that benefit most from the disclosure ecosystem are the ones that participate in it — by having a clear security contact, by responding promptly, by giving credit, by taking the work seriously.
The closing observation
The polished version of disclosure — the CVE, the blog post, the advisory — takes about thirty minutes to read. The version that produced it took 127 days of email, judgment, escalation, and trust-building. Most of that work is invisible to the public. All of it is the difference between a process that protects users and a process that doesn't.
If you're a vendor whose disclosure process is "we'll handle it when we get to it," the timeline above is what you're missing. If you're a researcher who's never coordinated a serious disclosure, the timeline is what you should expect. And if you're a customer of a vendor — which is everyone — the timeline above is the work that happens upstream of the patch you eventually install.
The patch is the visible deliverable. The 127 days are the actual job.