这取决于您的组织如何使用此类报告。

如果负责计划和/或实施安全控制的人员阅读了这些文档一次，然后再也看不到它们，或者将它们更多地视为指南而不是有关如何设置环境的实际规则，我可以看到您可能想要避免避免在报告中添加太多信息。仅仅因为您想确保通过安全措施解决实际存在的漏洞。

另一方面，如果这些是“活的”文档，设置了如何规划和实施控制的规则，并且如果基础设施在某个时刻发生变化，负责人会更新这些文档，那么您肯定希望包括这些漏洞。

恕我直言，作为在机构中组织信息安全的人，这是您应该推动的文化。

如果您担心您的文档会变得过于混乱，您可以随时使用它的结构。在与我合作的一个组织中所做的事情是，像这样的漏洞或未来可能的漏洞被添加到主文档的附件中。如果基础设施发生了任何变化，管理员可以先检查附件，看看是否有任何变化会带来那里列出的漏洞。

我想说的最后一点：虽然您没有启用这些功能，但这并不意味着攻击者在他/她访问路由器后不会这样做。因此，以防万一实施安全措施是合理的。不过，这可能应该在风险分析中进行评估。

引用 ISO/IEC 27005：

漏洞的存在本身不会造成伤害，因为需要存在威胁才能利用它。没有相应威胁的漏洞可能不需要实施控制，但应识别并监控其变化。

作为漏洞报告的客户，我会说是的，但是将其与其他漏洞同等重视肯定是浪费时间。例如，实时的、可利用的大量远程访问漏洞或活动的恶意后门不会获得与 DoS 漏洞或在这种情况下是禁用软件中的漏洞相同的覆盖范围。

恕我直言，报告应该有一个执行摘要，一个技术发现，然后进入繁琐的细节。

像您所描述的内容将是技术发现中的一条线，并且在繁琐的细节部分中有一些信息。

然而，CVE-2016-6380 意味着您没有定期修补设备，或者您的修补周期非常缓慢。这可能是客户可以接受的风险，但应该对其进行审查。在执行摘要中可能值得一提。没有 CVE# 的东西，高管们不在乎。

进一步参见 NIST 800-115 7.3

...

虽然需要识别和解决个别漏洞，但识别漏洞的根本原因是改善组织整体安全状况的关键，因为根本原因通常可以追溯到程序级别的弱点。一些常见的根本原因包括：

• 补丁管理不足，例如未能及时应用补丁或未能将补丁应用于所有易受攻击的系统

...

首先，您需要确定要扫描的内容和报告的内容的范围。

例如，扫描范围是为了发现和报告所有漏洞，包括低风险漏洞，或者只是高风险漏洞，或者可能只是关键漏洞。这应该在您开始漏洞扫描之前就已经定义好了。

如果确认为误报，则将其从报告中删除。

如果它是存在但未使用的服务，并且它是范围内确认的漏洞，则将其包含在报告中，以便可以从目标中删除该服务。

如果有人做出购买决定，他们可能会说“这个路由器支持路由器中的 DNS 解析。我们现在不使用它，但我们将来可能会这样做，所以我们购买这个路由器而不是没有这个的稍微便宜一点的路由器。特征”。

该漏洞意味着路由器不能以这种方式使用，因此该功能不得用于购买决策。换句话说，出于这个原因，它应该在您的报告中。如果服务可以从设备中删除，那么它应该被删除。（如果服务被删除并且人们抱怨，您可能会发现您认为它未被使用的假设实际上是错误的）。