The most important thing to remember about vulnerability disclosure -- regardless of if you believe this personally or not -- is that while disclosing a vulnerability can be a win for your organization, it will hurt others, plain and simple. The justification to release it is that it will hurt people more if you don't disclose it.
Indeed, if not for your efforts, this vulnerability would not have been fixed, and may have been exploited by evil attackers without anyone knowing or used in a mass-exploitation by a worm a year from now. But that does not change the fact that the vendor whose product you found a vulnerability will suffer in having to fix it and in the support costs and from a PR perspective having to respond to criticism.
Then millions of potential users may get compromised because of your disclosure, when criminals use the information to exploit the software now, rather than a year from now.
These are issues you should be ready to address in a statement if asked, and are also why you should insist that your researchers disclose the vulnerability responsibly, with the vendor (as long as the vendor also responds responsibly), rather than try to dissuade them from it so that the timetable can be shortened.
Make sure you have the goods Ask your researchers to examine their work, and to bring in an extra pair of eyes to make sure the vulnerability it real (i.e. exploitable), and that on the flip-side, it is not even more serious than they think (such as a remote exploit versus a denial of service).
Write three press releases One should be a simple email you can send to reporters you work with to interest them in the discovery. The second is an actual press release that you can reference everywhere, and the third a miniature technical paper on the issue.
Send the email with a reference the actual press release (a cover letter, if you like) to reporters you work with often.
The technical paper can be referenced in the press release, on your Web site, and on other forums where you publish it. It will be referenced by others who will inevitably write on the topic, as any new released vulnerability is interesting to people inside the industry much more than it is to reporters.
Contact reporters The first question to ask yourself is how urgent is this release. If the vulnerability was discovered by your team due to rigorous research and is not likely that someone else will publish it in the next few months, take your time to do things right.
See if you can locate a journalist who will be interested in the disclosure as a scoop. Preferably, a reporter from a large, popular publication. But there is nothing wrong with working with a smaller, successful tech publication. When one such publication writes on something newsworthy, the rest are likely to pick it up.
Once a large newspaper writes on the subject, others will pick it up and your work is almost done.
If the release is more urgent, work from the bottom up. Contact journalists at tech publications, provide them with the information, and let them do their jobs.
Industry and community releases More important than contacting the press is informing the community.
If you have the time, have your technical team submit a talk on the vulnerability to a large security conference such as Black Hat, Defcon and CCC. These conferences have teams of reporters just waiting for juicy new releases, and may even contact you before the conference as the rumor-mill generates noise.
If the vulnerability is not that significant or time is short, ask for the help of your technical team, and write a short, yet detailed, technical email to be sent to relevant mailing lists (such as Bugtraq and Full-Disclosure). While email formats for such disclosures can be found online, they vary considerably.
It is important that you include: