What actually happens when you report a vulnerability

Finding the vulnerability is the part everyone romanticizes: the hunch, the proof of concept that fires, the adrenaline. But the bug is the easy part. The hard, thankless and often frustrating part is what comes after: getting the right person to listen, to fix the problem, and to acknowledge it. It is called coordinated disclosure, and having reported the same bug class across dozens of open source projects I have seen the full spectrum - from textbook-perfect to total silence. Here is how it really goes.

The first wall: finding who to write to

Half the battle is figuring out where to report. Mature projects have a SECURITY.md file, a private advisory channel (on GitHub, the "Report a vulnerability" button), or a security@ address. Very many have nothing: no contact, no policy, just a public issue tracker - where you certainly can't post the details of a flaw - and, if you are lucky, a maintainer's email. The golden rule for the reporter: look in this order for SECURITY.md, the platform's private advisory, security@, then the maintainer. And never write the details in a public issue: you would turn a responsible report into an open-air 0-day.

The report that gets a response

A good report is not an accusation, it is a favor made easy to accept. What makes the difference: a clear title, the affected versions, a minimal reproducible proof of concept, the impact explained in plain words (what an attacker can really do) and - when you can - a suggested fix. On the other side, most of the time, there is a volunteer maintaining the project in their spare time. The easier you make it to understand and act, the more likely the bug gets fixed quickly. A report that respects the reader's time is half the work.

Then: the silence

The most common outcome is neither a fix nor a rejection: it is nothing. You send a careful report and nobody answers. It is almost never bad faith - it is bandwidth. Open source security often rests on a single person with a real job and a life beyond the repository. What to do: a polite follow-up after a few days, a reasonable deadline and - if the issue is serious and the silence persists - escalation to a third-party coordinator such as a national CERT/CSIRT or CISA, who can act as a bridge when direct contact fails.

Embargo, disclosure window and the 90 days

"Coordinated" means exactly this: you give the project time to ship a fix before you make the details public. The most widespread convention - made famous by Google Project Zero - is a 90-day window: enough for a serious team to fix, not so long that users stay exposed forever. The embargo is the agreement to keep the details confidential until the agreed publication date. And the deadline is not cruelty: without a date, "we'll get to it" becomes "we never get to it". The deadline is what turns good intentions into a patch.

The CVE: what it is actually for

At some point the CVE comes into play, and there is a misconception to dispel: it is not a trophy. It is a public, stable identifier - a number - that lets everyone refer to the same vulnerability: scanners, SBOMs, defense teams, the users who need to figure out whether they are exposed. You get one through a CNA (CVE Numbering Authority): sometimes the project itself, sometimes a platform, sometimes a "last resort" authority like MITRE or CISA. The CVE does not make the bug more serious; it makes it citable. It is plumbing for the defense ecosystem, not a medal.

When it goes wrong

Not every report ends well, and the ways of failing recur. The silent fix: the vendor corrects the bug in some release, with no advisory and no credit - the problem is fixed in the code but users don't know they need to update urgently, and it is the worst case for whoever runs the software. The dispute: "it's not a vulnerability, it's a design choice" - sometimes true, sometimes a way to end the conversation. The never-fixed: acknowledged but left there for months. And the public by accident: someone opens a public issue with the PoC in it, and the embargo no longer exists. The maturity of a project is measured exactly by how it avoids these traps.

A checklist for the reporter

• Find the right contact: SECURITY.md, the platform's private advisory, security@, then the maintainer. Never a public issue.
• Write an actionable report: versions, minimal PoC, impact in the clear, suggested fix.
• Agree on a window: a reasonable deadline (90 days is a good default), not an ultimatum.
• Be patient but present: a polite follow-up, then escalation to a CERT/CISA if needed.
• Coordinate the CVE: not for the number, but so defenders can refer to the problem.
• Publish responsibly: on the agreed date, with details useful for defending, not for exploiting.

The lesson

The lone-hacker myth stops at the moment of discovery. But the real value - for users, for the people maintaining the software and for the reporter's reputation - is all in what comes after: a well-handled, cooperative, quiet disclosure. That is where a researcher's maturity is measured, not in finding the bug. The rule I carry with me is simple: report the way you would want a bug in your own code reported to you - with care, clarity, and the patience to see it through.