3

I have asked about security release notes Considerations for security release notes

I need additional clarification about security vulnerabilities announcement. We create major release of our product about each half years and security or maintenance releases each month. Our product is Java Web Application that runs on Apache and Tomcat.

  • How should we announce about security vulnerabilities? Should we add our company as a vendor to CVE database http://cve.mitre.org/ (like Apache) and create new CVE each time we found it? Or is it enough to list our internal bug number?
  • Should we add to CVE database only vulnerabilities that were discovered by our customers? Or should we add to CVE database also vulnerabilities that were discovered by QA?
Community
  • 1
Michael
  • 1,457
  • 1
  • 18
  • 36
  • Unless you think it might be possible that the bug is already exploited in the wild, you shouldn't disclose it before a bugfix is available, because the moment you disclose it, it will be exploited. – Philipp Dec 25 '13 at 23:45
  • Related: [How do I respond to a published security vulnerability in my application?](http://security.stackexchange.com/q/19436/11291) – Michael Hampton Dec 26 '13 at 00:36

2 Answers2

3

I recommend reading the CVE FAQ. In short the CVE system is created to share knowledge of vulnerabilities in software, keep track of their severity and reduce the duplication of effort. The fundamental purpose of the CVE system is to notify users that they are in danger, and to update immediately.

It is appropriate to obtain a CVE for any publicly disclosed vulnerability that could endanger users. A bug found internally though QA, is probably not being publicly exploited, and therefore a CVE would probably not help.

Consider offering a mailing-list to your users to inform them of security related updates.

rook
  • 46,916
  • 10
  • 92
  • 181
3

You should announce all the vulnerabilities you think exist to your customers, as you release patches for them. You can announce them publicly and issue a CVE to improve transparency and allow auditors to more easily substantiate the need to upgrade software, but you should generally embargo them for a period of time after the patch is issued (to give your customers time to patch).

When you announce them, it's best to do so without including too many details; don't include a PoC (Proof of concept). It's often sufficient to name the general functionality being exploited (such as configuration file parsing, or a particular feature the bug resides with), the class of bug, and what the bug gets an attacker.

You have to keep in mind what you're trying to accomplish by disclosing. You want to show that you are fixing security bugs above-board and notifying your users of their existence, and shift potential liability off of yourself by ensuring any reasonable security professional would be aware of your bugs and the need to patch particular versions. You don't want to give attackers additional ammunition against your clients.

So, chances are you should announce bugs found by your customers and support, as well as ones found by QA, but only after you patch them. It doesn't really matter whether you see that an attacker has the bug; if your software is important, chances are nasty people have lots of bugs you don't know about, as the current mood is to keep at least a few in reserve in case you want to do something (rather than blowing all your bugs as soon as they are found to add to your botnet or whatever).

In short, publish everything, but make sure your patches lead your public announcements by a reasonable period of time, and avoid giving specifics that would enable exploit writers.

Alvaro
  • 103
  • 4
Falcon Momot
  • 1,140
  • 6
  • 15