How to Turn Vulnerability Disclosure Into Media Coverage

But a vulnerability disclosure is not a typical news announcement. Reporters are buried in bug reports, the timeline is out of your control, and one misstep can draw criticism from the same security community you're trying to impress. Handled well, a disclosure builds credibility. Handled poorly, it can backfire fast.

Here are seven steps to help your team turn a vulnerability disclosure into media coverage – without the missteps.

Vulnerability disclosure happens in two stages. First, researchers report the bug privately to the software owner. Then, weeks or months later, once a fix is in place, the vulnerability goes public. That second stage typically happens once the owner confirms a patch, or automatically after 60 days if no patch is ready. Some owners will give you a heads-up on timing. Others won't say a word until the announcement.

Because the exact release date is often out of your hands, the smart move is to prepare early: build your outreach materials and reporter list well ahead of time, then keep watch. That might mean checking in with the software owner directly or tracking patch notes yourself.

Open-source software makes this timeline harder to predict. A vulnerability reported to Linux gets a patch for the kernel itself, but each distro then has to apply that fix and release its own update. Since open-source projects run on volunteer labor rather than a company's release schedule, that process can take longer and move less predictably.

Software vulnerabilities are graded on a scale called the Common Vulnerability Scoring System or CVSS that goes from 0 to 10. Higher numbers = more dangerous = more newsworthy. Bugs that score above a 7 will often be interesting for press. For instance, we worked on disclosing a bug that scored just under an 8 and it received over 100 pieces of coverage. Many things affect this score, like how easy the bug is to take advantage of and what it allows an attacker to do.

Most disclosures are announced with a technical blog post aimed at other security engineers, which means it's usually too dense for a general reporter to work with. Write a second piece: a plain-language explainer covering what the vulnerability does, what it lets an attacker do, who's affected, and how to fix it. If a reporter wants more technical detail, point them to the full paper.

It also helps to line up the right spokespeople ahead of time. The strongest combination is a researcher who can walk through the technical details and an executive who can speak to what the vulnerability means for the market. The executive answers "so what," and the researcher explains how it actually works.

Many cybersecurity reporters will take news like this under embargo. If you have a high-severity vulnerability and know in advance that a patch is coming soon, reach out to reporters ahead of time (either under embargo or with a simple heads-up that news is on the way).

Most cybersecurity press won't cover a vulnerability once more than a few days have passed since the patch shipped. That means your outreach materials and contact list need to be ready before the patch is even live. Once the disclosure goes public, you'll be pitching immediately, often after a period of waiting with everything prepared and nothing to do but watch for the release.

No one likes a huckster, especially not security researchers. Many cybersecurity professionals and reporters will be critical of blog posts or websites that are clearly created by AI or that exaggerate the risks of a vulnerability. Keep the language clear, neutral, and factual, without the small exaggerations that might pass in a typical marketing document. Remember that these vulnerabilities can be very dangerous in the wrong hands and the disclosure process is, first and foremost, meant to keep computer systems safe from attackers.

Public disclosures aren't just useful to defenders, attackers read them too, and they use them as a blueprint for new attacks. What used to take days now takes hours, thanks to AI. Take extra care to prevent early leaks. A disclosure that goes out ahead of schedule doesn't just draw criticism from the security community; it also puts real organizations at greater risk.

A vulnerability disclosure is a narrow window. The severity score, the patch timeline, and the reporter's attention span are all working against you. Teams that prepare their materials early, move fast once the patch lands, and stick to clear, factual language are the ones that turn a bug into a story — and a story into credibility.

The next disclosure your team makes could be the one that gets noticed. Plan for it now.