Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I need help with understanding how to manage security release notes for our product. We create major release of our product about each half years and security or maintenance releases each month.

What should I consider regarding what we tell our customers about security?

  • Should we tell them that we upgrade our 3-d party software?
    E.g. should we tell them we upgrade Apache Httpd server version?
  • Should we list vulnerabilities fixed in Apache Httpd?
    Or enough to link to Apache site?
  • Should we manage the list of 3-d party software with versions?
  • What about our internal security vulnerabilities?
    Should we list the list of fixed security vulnerabilities? This may endanger those customers that will not upgrade to the latest version.
  • 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?

(Our product is Java Web Application that runs on Apache and Tomcat.)

share|improve this question
4  
What is your "product"? An actual installable piece of software? A web app? –  Terry Chia Dec 23 '13 at 14:27

1 Answer 1

up vote 5 down vote accepted

Great question! I've written a few of these, but always had a very formal way of doing it, such that I never had the option to think about what's really needed...

Coming from the perspective of the people who have to use and support and upgrade your product, I think you need to cover:

  • High level information (and a pointer if possible to details) - on why the fix was needed. Something like - "corrected string buffer handling in XYZ component" is helpful.

  • Known issues - anything that you couldn't fix yet that is still in there.

  • Upgrades of third party software and a place to find current baseline of all 3rd party software, whether it was upgraded or not.

In essence, they need to know what you fixed and your baseline is. Particularly in the world of Java, there can be enough conflicts and issues, that a wise company should keep a running tally of what servers are running what versions of the JVMs and other components.

Some other specific answers for your questions:

  • Should we list vulnerabilities fixed in Apache Httpd? Or enough link to Apache site?

    • A link would be a kindess. Don't clutter up YOUR release notes with other product's details.
  • Should we manage the list of 3-d party software with versions?

    • It should be available somewhere, I'm not sure that it has to be in the release notes, but if not, then it should be on your website somewhere.
  • What about our internal security vulnerabilities? Should we list the list of fixed security vulnerabilities? It may danger those customers that will not upgrade to the latest version.

    • Keep in mind that a failure to disclose known vulnerabilities could be seen as a legal liability. This is one for your lawyers. IMO, telling customers so that they know why a security fix is so important is more outweighs the value of obscuring it for the safety of those that can't upgrade fast enough. That said, you don't have to say "if you X, Y, Z you'll get admin privileges". Saying "severed vulnerability in access control system" should be good enough.
  • How should we announce about security vulnerabilities? Should we add our vendor to CVE database http://cve.mitre.org/ and create new CVE each time we found it? Or enough to list our internal bug number?

    • I'm not really sure what you mean by "our vendor" - I personally wouldn't register a 3rd party for CVE findings without agreeing with them on it.
  • Should we add to CVE database only vulnerabilities that were discovered by our customers? Should we add to CVE database also vulnerabilities that were discovered by QA?

    • I have yet to hear of any vendor using CVE for internal test/fix documentation. I think if you found it first, linking to your own repository of fixed bugs should be fine, but I haven't made that much commercial software.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.