测试 (Open Source)
组织 → 资产 → 测试活动 → 测试 → 发现项
概述
测试是一个或多个扫描执行的容器，用于发现产品中的缺陷。测试是 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)” 结尾，则按原样使用）。
| 原生解析器 | 通用发现项导入 | |
|---|---|---|
| 主要用途 | 接收受支持工具的输出 | 通过固定模式接收不受支持的/自定义数据 |
| 输入格式 | 特定于工具（例如 ZAP XML、SARIF） | 严格的 JSON/CSV 模式 |
| 由谁处理规范化 | DefectDojo（内置解析器） | 用户（必须符合模式规范） |
| 测试创建触发方式 | 手动上传或 API 导入 | 手动上传或 API 导入 |
| 测试类型 | 预定义（例如 “ZAP Scan”） | 自动创建的 “Generic” 类型 |
| 配置成本 | 低 | 中（需要进行数据转换） |
| 灵活性 | 低（仅限受支持的工具） | 中 |
| 自动化程度 | 低至中 | 低至中 |
| 典型使用场景 | 标准扫描器（SAST、DAST、SCA） | 自定义脚本、不受支持的工具 |
无论采用哪种接收方式，DefectDojo 中的所有扫描数据最终都会以附加到某个测试上的发现项形式呈现，该测试则作为执行单元和生命周期跟踪的单位。
测试数据
测试会存储各种元数据，以帮助记录每次测试工作的各个组成部分，例如：
- 测试标题/名称
- 测试类型
- 测试描述/备注
- 开始和结束日期
- 运行测试的环境（例如开发、预发布、准生产、生产等）
- 版本/分支/构建 ID/提交哈希值
- API 扫描配置
- 可用于后续审计或重新导入的其他文件
- 上级测试活动、资产和组织
- 导入和重新导入的历史记录
每个测试都会维护一份导入历史记录，用于记录与该测试相关的所有扫描导入和重新导入操作，其中包括扫描日期、版本、分支、提交哈希值和构建 ID 等元数据。
这份历史记录为同一测试内的多次扫描执行提供了可追溯性。
权限
单个测试活动内可以存储多个测试，而测试活动则存储在产品内。因此，对某个产品的访问权限会自动授予对该产品内所有测试（及测试活动）的访问权限。测试没有独立的访问控制列表。
访问测试
尽管测试在 DefectDojo OS 中作为独立对象存在，但界面中并没有专门用于展示测试的特定区域。因此，每个测试主要通过包含它的产品和/或测试活动来访问。
测试视图
测试视图承载了多种表格，包括上级测试活动、导入和重新导入历史记录、测试内包含的发现项列表以及任何发现项分组。
此外还有潜在发现项、文件和备注的表格，这些都可以手动添加。
测试设置
每个测试视图中都提供以下设置：
- 编辑测试
- 允许编辑测试数据，例如标题、计划安排、环境以及其他各种详细信息。
- 复制测试
- 复制某个测试及其所有相关元数据和发现项，并允许将其归属到不同的测试活动。
- 重新上传扫描
- 启动重新导入流程。有关重新导入的更多信息，请参阅本文后面的内容。
- 添加备注
- 允许用户添加备注。页面底部还有一个备注表格。
- 备注可以切换为私密状态，此时该备注不会被推送到 Jira、报告以及发现项的导出内容中。
- 允许用户添加备注。页面底部还有一个备注表格。
- 报告
- 启动生成报告的流程，您可以在其中应用多种筛选条件，从而仅针对筛选后的发现项生成报告。
- 添加到日历
- 下载所选测试的 .ics 文件，该文件可添加到您的第三方日历应用程序中。
- 查看历史记录
- 打开对该测试所做编辑的历史记录，用于跟踪、报告和审计目的。
使用测试
创建测试
当扫描数据被直接导入到某个测试活动中时，系统会自动创建测试，从而生成一个包含该扫描数据的新测试。测试也可以为规划未来的测试活动而预先创建，或用于需要跟踪和修复的手动录入安全发现项。
手动工作流
在 OS 版本中，有多种方式可以创建测试：
- 选择一个产品，然后在导航栏的“发现项”菜单中点击“导入扫描结果”
- 这将创建一个临时测试活动来包含该测试
- 在产品内选择一个测试活动，点击“测试”子区域中的下拉菜单，然后点击“添加测试”或“导入扫描结果”
- 这将直接在所选的测试活动内创建随之产生的测试
- 在创建测试活动的过程中
使用上述第三种方法，您可以在创建测试活动的同时执行以下操作：
- 立即导入扫描结果
- 创建测试外壳（稍后可向其中导入扫描数据）
- 两者都不做，只需点击“完成”来创建测试活动
无论是导入扫描数据还是创建测试外壳，您都可以借此机会添加元数据。任何元数据都会反映在测试视图的导入历史记录部分中。
自动化工作流
在自动化工作流中，测试可以作为扫描导入流程的一部分以编程方式创建，使流水线能够上传结果，而无需事先手动创建测试。
使用 API 导入扫描结果时，通过提供 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，则扫描结果将被添加到现有测试中，这在重新导入工作流中很常见。
编辑测试
要编辑测试，可以在上级测试活动视图中的测试表格里点击 ⋮ 竖排菜单中的编辑测试，也可以在测试视图内的设置菜单中进行编辑。随后可编辑的所有字段，在创建测试时也同样可用。
手动向测试添加发现项
要将发现项手动添加到测试，可以在上级测试活动视图中，点击测试旁边 ⋮ 竖排菜单中的将发现项添加到测试，也可以在测试视图内发现项表格的设置中进行添加。
删除测试
要删除测试，可以在上级测试活动视图中，从测试旁边的 ⋮ 竖排菜单中选择删除测试，也可以在测试视图内的设置菜单中进行删除。此操作无法撤销。
删除测试还会删除该测试内包含的所有发现项。
重新导入
在测试内重新导入扫描是实现有效去重的基础。当扫描结果被重新导入到同一测试中时：
- 现有发现项可能会被更新
- 重复的发现项可能会被抑制
- 如果未找到匹配项，则可能会创建新的发现项
这一行为取决于所配置的去重规则和扫描类型。
创建新测试而非重新导入到现有测试中，可能会导致创建重复的发现项，而不是对其进行更新。
重新导入与导入的比较
重新导入通常适用于以下情况：
- 针对同一目标运行周期性扫描
- 跟踪发现项随时间的变化情况
- 持续掌握应用程序的安全态势
相比之下，导入（创建新测试）更适用于一次性或独立的扫描执行。
重新导入扫描结果（界面操作）
要向现有测试添加新数据，可以在上级测试活动视图中，点击测试旁边 ⋮ 竖排菜单中的重新上传扫描结果，也可以在测试视图内的设置菜单中点击重新上传扫描。
在填写“重新导入扫描”表单时，您可以选择更新正在重新导入的扫描的元数据，包括版本、分支标签、提交哈希值和构建 ID。
这些更改会反映在测试视图的导入历史记录部分中，该部分还会包含之前扫描导入的相同元数据。
例如，在下面的屏幕截图中，分支标签、构建 ID、提交哈希值和版本均在首次导入与后续重新导入之间被手动更新。
要编辑最近一次重新导入扫描的元数据，请按照上文“编辑测试”部分中的说明进行操作，并根据需要更新元数据。只有最近一次导入的元数据可以编辑。
重新导入扫描结果（API）
当测试通过 CI/CD 流水线创建或更新时，您可以纳入来自该流水线运行的元数据，以便将测试正确关联到其所扫描的代码。这使您能够：
- 将扫描结果与特定的提交或分支相关联。
- 跟踪发现项随代码变更的演变情况。
- 通过了解两次扫描是否适用于相同或不同版本的代码，来改进去重效果。
- 通过准确显示所扫描的代码内容及扫描时间，来支持可审计性。
DefectDojo 的 API 在导入或重新导入期间接受这些值，以便将其作为扫描导入的一部分进行存储，并反映在测试的导入历史记录中。此元数据可用于识别提交哈希值，或与 CI/CD 运行相关的任何相关代码仓库信息。
支持的元数据字段
API 支持一组明确定义的元数据字段，这些字段可以在重新导入期间包含。其中包括：
tagsversionbuild_idbranch_tagcommit_hashscan_dateminimum_severityactive / verified标志
这些字段是在重新导入操作期间附加上下文元数据的主要机制。
在自动化流水线中，最常提供的元数据包括：
- build_id（CI 作业标识符）
- commit_hash（源代码控制引用）
- branch_tag（分支或环境上下文）
- tags（例如 nightly、staging、production）
这些字段无需人工干预即可在各次扫描之间提供可追溯性。
尽管可以通过“重新导入扫描”表单手动更新元数据，但大多数自动化环境会通过直接调用 /api/v2/reimport-scan/ 端点来处理此事。这种方式使流水线能够在重新导入时自动附加元数据。
使用元数据进行 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"
元数据、重新导入与计划扫描
扫描也可以设置为按固定周期运行，例如由 cron 作业触发的扫描。计划扫描与代码仓库活动无关，因此提交哈希值或分支名称等元数据除非由脚本本身显式注入，否则并不适用。尽管如此，如果您希望在单个测试内保留安全态势的滚动记录，使用重新导入仍然会很有帮助。