误报历史记录

误报历史记录功能可以让您的团队免于反复对同一个误报进行分类处理。启用该功能后，当发现项被导入时，DefectDojo 会在同一产品中查找与之匹配的已有发现项，如果其中任何一个已被标记为误报，传入的发现项也会被标记为误报。

产品中该功能被标记为实验性功能，并且不能与去重功能同时使用。 在启用之前，请先阅读何时可以使用它。

功能说明#

假设某个扫描工具报告了一个发现项，您的团队对其进行调查后将其标记为误报。在此后的每次扫描中，同一个发现项都会再次出现。通常情况下，每次都需要有人手动将其驳回。而启用误报历史记录后，DefectDojo 会识别出这个重复出现的发现项，并自动将其标记为误报。

以这种方式标记的发现项不仅会被标记为误报，还会被设置为非活动和未验证状态。这是刻意设计的行为——该发现项会完全退出您的活动队列——但对于那些以为只有误报标志会改变的人来说，这一点可能会出乎意料。

DefectDojo 遵循的规则是：在同一产品内，如果一个发现项是误报，那么所有与之匹配的发现项也都是误报。

追溯模式#

追溯型误报历史记录会反向应用同样的规则。当您将某个发现项标记为误报时，该产品中所有与之匹配的其他活动发现项也会被标记为误报。

此操作会改写现有数据。系统不会提供预览，也不会弹出确认提示——更改会直接在整个产品范围内生效。请务必谨慎地决定是否启用此功能。

什么时候可以使用它#

误报历史记录与去重功能互斥。 这两项功能所解决的问题存在重叠，因此 DefectDojo 不允许同时启用两者：在系统设置中，启用其中一项会使另一项变灰不可用，而启用去重功能则会清除误报历史记录的相关设置。

这是理解该功能时最重要的一点。大多数实例都启用了去重功能，对于这些实例而言，误报历史记录功能不可用。该功能是为那些刻意选择不进行去重的实例而设计的。

启用方法#

这两项设置都位于系统设置中的去重区块内，且默认均为关闭状态：

这些设置是面向整个实例的。不存在按产品或按工具的覆盖设置——启用此功能会影响该实例上的每一个产品。

什么算作匹配#

误报历史记录功能会使用报告该发现项的工具所配置的去重算法来判断两个发现项是否“相同”——尽管去重功能本身必须处于关闭状态。

因此，该功能的准确性完全取决于该工具去重配置的完善程度。在启用误报历史记录之前，请先调优该工具的算法和哈希字段——参见去重调优（Pro 版）或去重调优（开源版）。

匹配范围限定在单个产品内。它永远不会跨产品匹配，也不会应用于整个实例范围。

基于集合的匹配（Pro 版）#

在 DefectDojo Pro 版中，匹配还会考虑基于集合的哈希码字段——即漏洞 ID 和 CWE 匹配器（vulnerability_ids_partial、vulnerability_ids_subset、cwes_partial、cwes_subset，以及它们的精确匹配形式），其含义与在去重功能中相同。

这使得 Pro 版的匹配比开源版更为严格，而这正是其设计目的：如果没有这一机制，误报历史记录可能会将某个误报状态复制到那些同工具去重原本根本不会视为重复项的发现项上。这种细化规则只会缩小被标记的发现项范围——启用 Pro 版功能永远不会导致更多发现项被自动标记。

在开源版中，匹配仅依赖哈希码，因此匹配范围更宽。在进行调优时请留意这一点。

启用前应了解的风险#

该功能会在无人工审查的情况下将发现项标记为误报。其影响范围由您的去重配置决定，因此配置过于宽松会带来风险。

• 过于宽松的匹配键可能会在不知不觉中驳回不相关的发现项。 旧版算法仅依据标题和严重程度进行匹配——因此一次误报判定就可能将该产品中所有标题相同、严重程度相同的发现项都标记为误报，其中也包括真正的漏洞。哈希码字段设置过于宽泛时也会出现同样的问题。请先收紧算法配置。
• 追溯模式会改写现有发现项，且不提供预览、不弹出提示，也不会提供更改内容的摘要。
• 发现项会被停用并标记为未验证，而不仅仅是被打上标记。
• 批量更新会绕过常规的保存时处理逻辑，因此依赖发现项更新事件触发的自动化流程，可能不会针对以这种方式更改的发现项而触发。
• 在 DefectDojo 中，该功能目前仍被标记为实验性功能。

对于大多数团队来说，更安全的做法是保持去重功能开启，让重复项从其原始发现项继承状态，而不是切换到误报历史记录功能。参见关于去重。