DefectDojo DefectDojo | docs

测试 (Pro)

Organizations → Assets → Engagements → TESTS → Findings

概述

测试是一个或多个扫描执行的容器，用于发现资产中的缺陷。测试是 DefectDojo 对象层级中最终、最细粒度的组成部分，它是安全工具执行或人工评估所产生发现项的容器，同时也添加了发现这些发现项时的上下文（即报告该发现项的工具是什么、该工具最近一次运行是什么时候等）。

测试的示例包括：

  • 静态应用程序安全测试
  • 动态应用程序安全测试
  • 软件成分分析
  • 容器安全扫描
  • 基础设施/网络扫描
  • 手动渗透测试
  • CI/CD 流水线扫描

测试类型

在 DefectDojo 中创建测试的方法有多种，包括特定厂商解析器（例如 Burp、OWASP ZAP、Acunetix、Invicti）、通用发现项导入、通用解析器以及连接器。

这些方法可以创建新测试，也可以根据配置和去重策略将发现项重新导入到现有测试中。

虽然这些方法在解析和摄取扫描数据的方式上各不相同，但最终都会将发现项关联到某个测试。

解析器

解析器是处理特定扫描输出格式（例如 XML、JSON、CSV）并将其映射到 DefectDojo 内部发现项模型的组件。导入扫描结果时，DefectDojo 会使用所选解析器提取发现项，并将其附加到新创建或现有的测试中。

通用发现项导入

当某个工具没有原生解析器时，通用发现项导入 允许您使用标准化的 JSON 或 CSV 架构导入发现项，无论其原始来源是什么。

DefectDojo 会解析提供的数据，创建新测试（或导入到现有测试中），并附加发现项。系统还会根据报告中可选的 type 字段创建相应的测试类型：当省略 type（或其值等于扫描类型）时，测试类型为 “Generic Findings Import”；当提供了 type 时，测试类型变为 “{type} Scan (Generic Findings Import)"（如果 type 值已经以 “(Generic Findings Import)” 后缀结尾，则按原样使用）。

通用解析器

通用解析器 允许用户定义任意输入数据如何映射到 DefectDojo 的发现项模型。配置解析器并上传扫描数据后，DefectDojo 会应用映射规则提取发现项，创建测试（或更新现有测试），并将发现项与该测试关联。

连接器

连接器 可用于通过 API 调用自动摄取和整理来自外部工具的漏洞数据。配置完成后，连接器会获取扫描结果、解析数据，并根据其配置创建新测试或更新现有测试。随后，发现项会被附加到相应的测试中。

测试创建机制对比

原生解析器通用发现项导入通用解析器（Pro）连接器
主要用途摄取受支持工具的输出通过固定架构摄取不受支持/自定义的数据通过可配置映射摄取任意格式持续同步外部系统
输入格式特定工具格式（例如 ZAP XML、SARIF）严格的 JSON/CSV 架构任意格式（JSON、XML 等）外部 API 响应
由谁负责规范化DefectDojo（内置解析器）用户（必须符合架构要求）DefectDojo（通过解析器配置）外部工具 + DefectDojo
测试创建触发方式手动上传或 API 导入手动上传或 API 导入手动上传或 API 导入自动同步（定时或事件驱动）
测试类型预定义（例如 “ZAP Scan”）自动创建 “Generic” 类型来自解析器配置取决于连接器/底层解析器
配置工作量低中等（需要数据转换）高（需要解析器配置）中到高（需要集成配置）
灵活性低（仅限受支持工具）中高中到高
自动化程度低到中等低到中等低到中等高
典型使用场景标准扫描器（SAST、DAST、SCA）自定义脚本、不受支持的工具大规模复杂/自定义格式CI/CD、SCM 或平台集成

无论采用哪种摄取方式，DefectDojo 中的所有扫描数据最终都会以附加到某个测试的发现项形式呈现，该测试即为执行与生命周期跟踪的基本单元。

测试数据

测试会存储多种元数据，用于记录每次测试工作的各个组成部分，例如：

  • 测试标题/名称
  • 测试类型
  • 测试描述/备注
  • 开始和结束日期
  • 运行测试所在的环境（例如开发、预发布、生产前、生产等）
  • 版本/分支/构建 ID/提交哈希
  • API 扫描配置
  • 与该测试相关的人员
  • 可用于后续审计或重新导入的其他文件
  • 上级测试活动、资产和组织
  • 导入和重新导入历史

每个测试都会维护一份导入历史记录，记录与该测试相关的所有扫描导入和重新导入操作。每条历史记录都包含扫描日期、版本、分支、提交哈希和构建 ID 等元数据。

该历史记录为同一测试内的多次扫描执行提供了可追溯性。

权限

一个测试活动中可以存储多个测试，而测试活动又存储在资产中。因此，对某个资产的访问权限会自动授予该资产内所有测试（及测试活动）的访问权限。测试没有独立的访问控制列表。

访问测试

可以从 DefectDojo 界面的多个位置访问测试。

  • 侧边栏

image

  • 测试活动内部

image

  • 资产的顶部栏

image

  • 发现项视图中的元数据表

image

使用测试

创建测试

当扫描数据直接导入到某个测试活动时，可以自动创建测试，其中包含该扫描数据。也可以为规划未来的测试活动提前创建测试，或者为需要跟踪和修复的手动录入安全发现项创建测试。

手动工作流

要创建一个测试，必须先创建一个用于容纳它的测试活动，以及一个用于容纳该测试活动的资产。之后，有以下几种方式可以创建测试：

  • 在侧边栏的管理子部分下的“测试”中
    • 在填写新建测试表单时，您需要选择一个已存在的测试活动，将该测试归属于其中。

image

  • 资产视图右上角的设置下拉菜单
    • 导入扫描会在扫描文件添加到导入扫描表单后自动创建一个测试。您可以选择将该测试归属于一个已存在的测试活动，或创建并命名一个新的测试活动来容纳该测试。
      • 在填写导入扫描表单时，您可以添加版本、分支标记、提交哈希和构建 ID 等元数据。这些信息会体现在测试视图的导入历史部分中。

image

  • 测试活动视图右上角的设置下拉菜单
    • 导入扫描遵循与资产相同的工作流程，但会自动将该测试对象放置在您点击导入扫描时所在的测试活动内。
    • 添加测试会创建一个测试对象，但不要求为该测试本身上传扫描文件，这在提前规划未来的测试，或需要跟踪和修复的手动录入安全发现项时非常有用。

image

如果您选择了添加测试，之后又想手动将扫描结果导入该测试，可以打开该测试，然后点击测试设置中的“重新导入发现项”按钮，或发现项表格中的“重新导入扫描”按钮。

image

自动化工作流

在自动化工作流中，可以在扫描导入过程中以编程方式创建测试，从而使流水线能够上传结果，而无需事先手动创建测试。

使用 API 或 CLI 导入扫描结果时，只需提供 engagement 而非 test，即可自动创建一个新测试。

API

curl -X POST "https://<your-instance>/api/v2/import-scan/"
-H "Authorization: Token <api_key>"
-F "engagement=45"
-F "scan_type=ZAP Scan"
-F "file=@report.xml"

通过以上命令，会在指定的测试活动下创建一个新测试，并将扫描结果附加到该测试中。

如果改为提供 test ID，扫描结果将被添加到现有测试中，这在重新导入工作流中很常见。

CLI

使用 DefectDojo CLI 时，该行为会根据所提供的参数自动处理。

defectdojo-cli import
–engagement-id 45
–scan-type "ZAP Scan"
GOog –file report.xml

通过以上命令，提供 engagement-id 会创建一个新测试，而提供 test-id 则会复用现有测试，并将扫描结果重新导入该测试。

有关所需标志的更多详细信息，请参阅 DefectDojo-CLI。

编辑测试

点击齿轮菜单中的编辑测试即可编辑测试。所有可编辑的字段在创建测试时同样可用。

删除测试

可以通过在测试的设置中选择删除测试来删除测试。此操作无法撤销。

删除测试还会删除该测试中包含的所有发现项。

重新导入扫描结果（界面）

要向现有测试添加新数据，请打开要添加数据的测试，然后点击测试设置中的“重新导入发现项”按钮，或发现项表格中的“重新导入扫描”按钮。

image

在填写重新导入扫描表单时，您可以选择更新正在重新导入的扫描的元数据，包括版本、分支标记、提交哈希和构建 ID。这些更改会体现在测试视图的导入历史部分中，其中也会包含之前扫描导入的相同元数据。

例如，在下方截图中，分支标记、构建 ID、提交哈希和版本在初次导入和后续重新导入之间都被手动更新过。

image

要编辑最近一次重新导入扫描的元数据，请点击测试活动视图右上角的齿轮图标，然后选择“编辑测试”。只能编辑最近一次导入的元数据。

重新导入扫描结果（API/CLI）

当通过 CI/CD 流水线创建或更新测试时，您可以包含来自流水线运行的元数据，以便将测试正确关联到其所扫描的代码。这使您能够：

  • 将扫描结果与特定提交或分支关联。
  • 跟踪发现项在代码变更过程中的演变情况。
  • 通过了解两次扫描是否适用于相同或不同版本的代码来改进去重。
  • 通过准确显示扫描了哪些代码以及扫描时间来支持可审计性。

DefectDojo 的 CLI 和 API 在导入或重新导入期间接受这些值，以便将其作为扫描导入的一部分存储，并体现在测试的导入历史中。此元数据可用于识别提交哈希，或与 CI/CD 运行相关的任何相关代码仓库信息。

支持的元数据字段

API 和 CLI 支持一组预定义的元数据字段，可在重新导入期间包含这些字段。包括：

  • tags
  • version
  • build_id
  • branch_tag
  • commit_hash
  • scan_date
  • minimum_severity
  • active / verified 标志

这些字段是在重新导入操作期间附加上下文元数据的主要机制。

在自动化流水线中，最常提供的元数据包括：

  • build_id（CI 作业标识符）
  • commit_hash（源代码控制引用）
  • branch_tag（分支或环境上下文）
  • tags（例如 nightly、staging、production）

这些字段无需人工干预即可提供跨扫描的可追溯性。

虽然可以通过重新导入扫描表单手动更新元数据，但大多数自动化环境会直接调用 /api/v2/reimport-scan/ 端点，或在构建过程中使用 DefectDojo CLI（defectdojo-cli reimport）来处理这一操作。这种方式可以让流水线在重新导入时自动附加元数据。

带元数据的 API 重新导入

curl -X POST "https://<your-instance>/api/v2/reimport-scan/"
-H "Authorization: Token <api_key>"
-F "test=123"
-F "scan_type=ZAP Scan"
-F "file=@report.xml"
-F "tags=nightly,api-scan"
-F "version=1.4.2"
-F "build_id=jenkins-842"
-F "branch_tag=main"
-F "commit_hash=a1b2c3d4"

带元数据的 CLI 重新导入

defectdojo-cli import
–test-id 123
–scan-type “ZAP Scan”
–file report.xml
–tag nightly
–tag api
–build-id jenkins-842
–branch main
–commit a1b2c3d4

CLI 直接映射到相同的 API 端点，并支持相同的一组元数据字段。

在重新导入期间处理元数据时，需要注意以下一些限制：

  • API/CLI 仅支持预定义参数。重新导入期间无法添加自定义键值元数据
  • 根据扫描类型和解析器的不同，可能会从扫描文件本身提取其他元数据。
  • 重新导入期间提供的元数据不会像在界面中手动编辑那样直接更新测试对象。
元数据、重新导入与计划扫描

扫描也可以设置为按固定间隔运行，例如由 cron 作业触发的扫描。计划扫描与代码仓库活动无关，因此除非脚本本身显式注入，否则提交哈希或分支名称等元数据并不适用。不过，如果您希望在单个测试中保留安全态势的滚动记录，使用重新导入仍然会很有用。

重新导入与去重

在测试中重新导入扫描是实现有效去重的基础。当扫描结果被重新导入到同一测试中时：

  • 现有发现项可能会被更新
  • 重复的发现项可能会被抑制
  • 如果未找到匹配项，可能会创建新的发现项

此行为取决于所配置的去重规则和扫描类型。

创建新测试而不是重新导入到现有测试中，可能会导致创建重复的发现项，而不是更新它们。

重新导入与导入的对比

通常在以下情况下使用重新导入：

  • 对同一目标运行重复性扫描
  • 跟踪发现项随时间的演变情况
  • 维护应用程序安全态势的连续视图

相比之下，导入（创建新测试）更适合一次性或独立的扫描执行。

上一页
测试
下一页
使用 URL