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.
