好问题！我已经写了其中的一些，但总是有一种非常正式的方式，所以我从来没有选择考虑真正需要什么......

从必须使用、支持和升级您的产品的人的角度来看，我认为您需要涵盖：

• 高级信息（如果可能，还有指向详细信息的指针） - 关于为什么需要修复的信息。诸如“在 XYZ 组件中更正字符串缓冲区处理”之类的东西很有帮助。

• 已知问题 - 任何您仍无法修复但仍存在的问题。

• 第三方软件的升级以及查找所有第三方软件的当前基线的位置，无论是否升级。

从本质上讲，他们需要知道您修复了什么以及您的基线是什么。特别是在 Java 世界中，可能存在足够多的冲突和问题，明智的公司应该对哪些服务器正在运行哪些版本的 JVM 和其他组件保持运行记录。

您的问题的其他一些具体答案：

• 我们应该列出 Apache Httpd 中修复的漏洞吗？或者有足够的链接到 Apache 站点？

  • 链接将是一种善意。不要将您的发行说明与其他产品的详细信息混为一谈。

• 我们应该管理带有版本的 3-d 派对软件列表吗？

  • 它应该在某个地方可用，我不确定它是否必须在发行说明中，但如果没有，那么它应该在您的网站上的某个地方。

• 我们的内部安全漏洞呢？我们是否应该列出已修复的安全漏洞列表？这可能会危及那些不会升级到最新版本的客户。

  • 请记住，未能披露已知漏洞可能被视为法律责任。这是给你的律师的。IMO 告诉客户，让他们知道为什么安全修复如此重要，这比为了那些无法快速升级的人的安全而掩盖它的价值更重要。也就是说，您不必说“如果您 X、Y、Z，您将获得管理员权限”。说“访问控制系统中的严重漏洞”应该已经足够了。

• 我们应该如何公布安全漏洞？我们是否应该将我们的供应商添加到 CVE 数据库http://cve.mitre.org/并在每次找到它时创建新的 CVE？或者足以列出我们的内部错误编号？

  • 我不太确定您所说的“我们的供应商”是什么意思——我个人不会在未与他们达成一致意见的情况下为 CVE 调查结果注册第 3 方。

• 我们是否应该只将客户发现的漏洞添加到 CVE 数据库中？我们是否应该将 QA 发现的漏洞也添加到 CVE 数据库中？

  • 我还没有听说有任何供应商使用 CVE 作为内部测试/修复文档。我认为如果您首先找到它，链接到您自己的已修复错误存储库应该没问题，但我还没有制作那么多商业软件。