避免产生过多重复项
DefectDojo 的优势之一在于其数据模型能够适应许多不同的使用场景和应用方式。随着您逐渐掌握该软件并发现优化工作流程的方法，您的使用方式也可能随之改变。
默认情况下，DefectDojo 不会删除任何已创建的重复发现项。每个发现项都被视为一个独立的漏洞实例。因此在这种情况下，重复发现项的出现可能表明您的工作流程需要进行调整。
什么时候可以接受重复发现项？
重复发现项并不总是意味着存在问题。在许多情况下，保留重复项才是更合适的做法。例如：
- 如果您的团队使用并报告交互式测试活动。如果您想专门针对单个测试创建一份独立的报告，就会需要知道其中是否出现了此前已经发现过的发现项。
- 如果您的测试活动在上下文上彼此独立（例如，因为它们覆盖不同的代码仓库），您会希望能够标记出在两处都出现的发现项。
检查冗余的导入
第 1 步：清理过多的重复项
幸运的是，DefectDojo 的去重设置允许您在超过一定阈值后批量删除重复项。此功能让清理过程变得更加简便。要了解更多相关信息，请参阅我们关于发现项去重的文章 <-此处将插入链接。
第 2 步：评估您的测试活动是否存在冗余
清理完重复发现项后，最好回头查看包含这些发现项的产品，看看是否能找到明显的原因。您可能会发现产品中包含的某些测试活动之间存在冗余的上下文。
重复或被重复使用的测试活动
测试活动为特定的测试上下文存储一个或多个测试。该上下文最终由您自行定义，但如果您发现产品中有几个测试活动本应共享同一上下文，请考虑将它们合并为单个测试活动。
定义测试活动上下文时应思考的问题：
- 如果我想针对这项工作生成报告，该测试活动是否包含我所需的全部相关信息？
- 我们是提前主动创建测试活动，还是由导入流程“临时”创建的？
- 我们使用的测试活动类型是否正确——交互式还是 CI/CD？
- 测试所涉及的是代码库的哪个部分：每个代码仓库是否应作为一个独立的上下文，还是多个代码仓库可以共同构成一个共享的测试上下文？
- 该产品涉及哪些利益相关方，我将如何与他们分享结果？
第 3 步：检查冗余的测试
如果您发现存在多个针对相同测试上下文创建的独立测试，这可能表明这些测试可以合并为单一的重新导入流程。
DefectDojo 提供两种导入测试数据以创建发现项的方法：导入和重新导入。这两种方法非常相似，但关键区别在于：导入始终会创建一个新测试，而重新导入则可以向现有测试添加新数据。另外值得注意的是，重新导入不会在该测试内部创建重复的发现项。
每次将新的漏洞报告导入 DefectDojo 时，这些报告都会存储在一个测试对象中。用户可以提前创建一个测试对象，以便容纳未来的导入操作。如果用户在导入数据时未指定目标测试，系统会创建一个新测试来存储传入的报告。
测试是灵活的对象，虽然一个测试只能容纳一种报告，但可以通过重新导入方法处理该同类报告的多个实例。要了解有关重新导入的更多信息，请参阅我们关于该主题的**文章**。
对持续性测试使用重新导入
如果您有 CI/CD 流水线、每日扫描流程，或任何类型的重复性传入报告，提前设置好重新导入流程是避免产生过多重复项的关键。重新导入会将与某个重复性测试相关的上下文和发现项汇总到单个测试页面中，您可以在该页面查看导入历史，并跟踪各次扫描之间的漏洞变化。
- 创建一个测试活动，用于存储您所运行 CI/CD 对象的 CI/CD 结果。这可以是一个已设置 CI/CD 操作运行的代码仓库。通常，您需要为每条流水线单独设置一个测试活动，以便快速了解发现项结果的来源。
- 每个 CI/CD 操作都会在独立的步骤中将数据导入 DefectDojo，因此每个步骤都应对应一个独立的测试。例如，如果每次流水线执行都会运行 NPM-audit 以及依赖项扫描，那么每个扫描结果都需要分别流入一个测试（嵌套在该测试活动下）。
- 您无需在每次 CI/CD 操作运行时都创建新测试，而是可以将数据重新导入到同一个测试位置。
重新导入的实际运作
DefectDojo 会将传入的扫描数据与现有的扫描数据进行比较，然后按照以下方式对测试中包含的发现项应用更改：
创建发现项
任何未包含在上一次导入中的漏洞都会作为新发现项自动添加到测试中。
忽略已存在的发现项
如果任何传入的发现项与已存在的发现项匹配，传入的发现项将被丢弃，而不会被记录为重复项。这些发现项已经被记录过，无需再添加新的发现项对象。测试页面会将这些发现项显示为保持不变。
关闭发现项
如果测试中已存在的某些发现项未出现在传入的报告中，您可以选择自动将这些发现项设置为非活动和已缓解状态（假设这些漏洞自上次导入以来已被解决）。测试页面会将这些发现项显示为已关闭。
如果您不希望关闭任何发现项，可以在重新导入时禁用此行为：
- 如果使用界面操作，请取消勾选关闭旧发现项复选框
- 如果使用 API，请将 close_old_findings 设置为 False
重新打开发现项
- 如果任何已关闭的发现项在重新导入中再次出现，它们将被自动重新打开。系统会假设这些漏洞尽管此前已被缓解，但现在再次出现。测试页面会将这些发现项标记为已重新激活。
如果您使用的是无需分类的扫描工具，或者出于其他原因不希望已关闭的发现项被重新激活，可以在重新导入时禁用此行为：
- 如果使用 API，请将 do_not_reactivate 设置为 True
- 如果使用界面操作，请勾选不要重新激活复选框
使用导入历史记录
给定测试的导入历史记录列在测试页面的测试概览标题下。
该表格将每次导入或重新导入显示为单独一行，包含时间戳列，以及（如果已指定）分支标签、构建 ID、提交哈希和版本列。
操作
此标题栏显示了某次导入/重新导入所采取的操作。
- “# created”（新建数）表示导入/重新导入时创建的新发现项数量
- “# closed”（关闭数）表示由重新导入关闭的发现项数量（因为它们未出现在传入的报告中）。
- “# left untouched”（保持不变数）表示重新导入未作改动的处于打开状态的发现项数量（因为它们同样存在于传入的报告中）。
- “# reactivated”（重新激活数）表示由传入的重新导入重新打开的已关闭发现项数量。
为什么不直接使用导入？
虽然两种方法都是可行的，但导入应保留用于发现项和数据的新出现情形，而重新导入则应用于同一数据的后续迭代。
如果您的 CI/CD 流水线每次都运行导入并创建一个新的测试对象，那么每次导入都会给您带来一批独立的发现项，您随后需要将它们作为单独的对象来管理。使用重新导入可以缓解这一问题，并减少漏洞解决后您需要进行的“清理”工作量。
使用重新导入可以让您将每份重复性报告存储在同一页面中，并保持每次向测试添加新数据时的连续性。
但是，如果您在多个位置或上下文中使用同一扫描工具，为每个位置或上下文分别创建独立的测试可能更为合适。这取决于您偏好的组织方式。