你可以做任何一个，但我建议申请 CVE，以便获得威胁情报源的客户更有可能注意到问题并加快修补程序。如果您以后需要，分配 CVE 还可以更轻松地在一般通信中引用特定漏洞。这也是向您的客户发出的信号，表明您认真对待安全透明度。

CVE 由 MITRE 分配和管理，您可以使用CVE 申请表提出请求。

发布 CVE 以便其他人知道有必要更新会很有帮助：正如您所说，他们可以在威胁情报源（或 CVE 扫描）中看到它，而不必阅读每个更新的变更日志来决定他们是否需要更新。

此外，作为渗透测试人员，它对我们的工作有很大帮助。如果我们找到 SAPConnectorDeluxe 4.1.39，我们要做的第一件事就是检查 CVE 数据库是否存在任何漏洞。即使该软件是专有的并且仅由少数公司使用，了解运行该软件的风险对我们很有用，以便我们可以正确地为客户提供建议。

它还告诉我们发现问题的频率和类型：如果我们看到一个小型软件组件在过去一年中有 10 个缓冲区溢出漏洞，我们就知道开发人员没有时间将安全性纳入他们的开发过程. 在这种情况下，很可能会发现更多漏洞，或者已经被恶意方发现。

如果软件仅在内部使用，则提交 CVE 并不常见。如果我们找到定制软件，我们会进行一些分析（取决于我们有多少时间）并建议有人更彻底地审查其安全性。有关内部产品的信息不会帮助公司以外的任何人，因此无需将其发布到 CVE 等中央数据库。

您不需要申请 CVE，但当您认为这对您有利时，您可以自由申请。

CVE 只是一个识别漏洞的中心编号，它可以在沟通漏洞时提供帮助。当涉及多方时，CVE 特别有用。任何人都可以在您的产品中请求 CVE，但在我看来，如果您在其他人之前自己做会更好。

我认为最重要的问题是您的产品是否带有自动更新程序。如果默认情况下它会自动更新，那么 CVE 有时弊大于利，因为它会将您的产品置于许多黑客的认知范围内，否则他们可能根本不知道您的存在。他们可以看到您的 CVE 历史记录，并对您的安全状况有很好的了解。如果他们看到很多“不成熟”错误的修复，那么你的产品可能很容易受到那些知道如何找到更晦涩的东西的人的审查，否则你可能会幸运地避免这些东西。

此外，即使您发布了 CVE，也不太可能修补的产品弊大于利。大多数物联网设备从未打过补丁，因此，CVE 只是告诉黑客哪些设备很容易成为猎物。

相反，如果您的产品通常需要手动更新，而您发布 CVE 时可能会发生这种情况，那么您可能应该这样做。