资产层级结构：概览 (Open Source)

DefectDojo 使用五个主要的数据类来组织您的工作：组织、资产、测试活动、测试和发现项。

DefectDojo 的设计目的是灵活地适应您的团队，而不是让您的团队去迁就工具。一旦您了解了如何使用这些数据类来组织工作，就能够设计出一个健壮、可适应的工作空间。

资产层级关系图#

组织#

您需要在 DefectDojo 中设置的第一类数据是组织。组织旨在以特定方式对资产进行分类。这可以是：

• 按业务领域
• 按开发团队
• 按安全团队

资产按其所属组织进行分组并嵌套在其下。

组织可以应用基于角色的访问控制规则，从而限制团队成员查看和操作其数据的能力（包括其下属资产中的测试活动、测试和发现项数据）。有关用户角色的更多信息，请参阅我们的角色介绍一文。

组织可以代表什么？#

• 如果某个软件项目有许多不同的部署或版本，那么创建一个涵盖整个项目范围的组织，并让每个版本作为单独的资产存在，可能是值得的。 ​
• 您也可以考虑使用组织来代表软件开发流程中的各个阶段：一个组织代表“开发中”，一个组织代表“生产中”，依此类推。 ​
• 归根结底，如何组织您的资产、以及您希望组织代表什么，完全取决于您自己的决定。您的 DefectDojo 层级结构可能需要根据安全团队的需求进行调整。

资产#

DefectDojo 中的资产旨在代表您当前正在测试的任何项目、程序或应用程序。资产承载着与其底层目标相关的所有安全工作和测试历史。

• 唯一的名称
• 描述
• 所属组织
• 分配的 SLA 配置

资产的范围可宽可窄，完全取决于您的意愿。默认情况下，资产在层级结构中是完全独立的对象，但可以通过组织将它们分组在一起。

资产是“隔离”的，不会与其他资产相互影响。DefectDojo 的智能功能（例如去重）仅在单个资产的范围内生效。

与组织一样，资产也可以应用基于角色的访问控制规则，从而限制团队成员查看和操作它们（以及其下属的测试活动、测试和发现项数据）的能力。有关用户角色的更多信息，请参阅我们的角色介绍一文。

资产可以代表什么？#

DefectDojo 中“资产”的概念不一定与您所在组织所称的“产品”一一对应。软件开发是复杂的，即使在单个软件的范围内，安全需求也可能存在很大差异。

以下场景是考虑创建单独 DefectDojo 资产的合理理由：

• “ExampleAsset”有 Windows 版本、Mac 版本和云版本
• “ExampleAsset 1.0”使用的软件组件与“ExampleAsset 2.0”完全不同，且这两个版本都由贵公司积极维护。
• 负责“ExampleAsset version A”的团队与负责“ExampleAsset version B”的资产团队不同，因此需要分配不同的安全权限。

单个资产内的这些差异也可以在测试活动层面进行处理。请注意，测试活动不像资产和组织那样具有访问控制。

测试活动#

设置好资产后，您就可以开始创建和安排测试活动。测试活动旨在代表正在进行测试的时间点，并包含一个或多个测试。

测试活动始终具有：

• 唯一的名称
• 目标开始和结束日期
• 状态（未开始、进行中、已取消、已完成……）
• 指定的测试负责人
• 关联的资产

测试活动有两种类型：交互式和 CI/CD。

• 交互式测试活动通常由工程师运行。交互式测试活动侧重于在应用程序运行期间对其进行测试，使用自动化测试、人工测试人员，或任何与应用程序功能“交互”的活动。请参阅 OWASP 对 IAST 的定义。
• CI/CD 测试活动用于与 CI/CD 流水线进行自动化集成。CI/CD 测试活动旨在作为一个自动化操作导入数据，由发布流程中的某个步骤触发。

可以使用 DefectDojo 的日历视图来跟踪测试活动。

测试活动可以代表什么？#

测试活动旨在代表一组相关的测试工作。您希望如何对测试工作进行分组，取决于您自己的方式。

如果您已经安排了一项计划中的测试工作，测试活动可以为您提供一个存储所有相关结果的地方。以下是这类测试活动的一个示例：

测试活动： ExampleSoftware 1.5.2 - 交互式测试工作#

在此示例中，一个安全团队在同一天内运行了多项测试，作为软件发布的一部分。

• 测试： Nessus 扫描结果（3 月 12 日）
• 测试： NPM 扫描审计结果（3 月 12 日）
• 测试： Snyk 扫描结果（3 月 12 日） ​ 您也可以在一个测试活动中组织 CI/CD 测试结果。这类测试活动是“开放式”的，意味着它们没有固定日期，而是每次运行相关的 CI/CD 操作时都会添加额外的数据。

测试活动：ExampleSoftware CI/CD Testing#

在此示例中，每次创建新的软件发布时，多个 CI/CD 扫描都会自动作为测试导入。

• 测试：1.5.2 扫描结果（3 月 12 日）
• 测试：1.5.1 扫描结果（3 月 3 日）
• 测试：1.5.0 扫描结果（2 月 14 日）

测试活动可以按照最适合您团队的方式进行组织。嵌套在某个资产下的所有测试活动，都可以被负责该资产的团队查看。

测试#

测试是工程师为尝试发现资产中的缺陷而进行的一组活动。

测试始终具有：

• 唯一的测试标题
• 特定的测试类型（API 测试、Nessus 扫描等）
• 关联的测试环境
• 关联的测试活动

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

测试类型#

DefectDojo 支持两类测试类型：

1. 基于解析器的测试类型：这些类型对应于以 XML、JSON 或 CSV 等格式生成输出的特定安全扫描器。在导入扫描结果时，DefectDojo 会使用专门的解析器将扫描器输出转换为发现项。

2. 非解析器测试类型：用于并非从扫描文件导入、而是手动创建的发现项。这些测试类型使用 通用发现项导入 方法来呈现发现项和元数据。

创建新测试时，以下测试类型会出现在“扫描类型”下拉菜单中。

• API 测试
• 静态检查
• 渗透测试
• Web 应用程序测试
• 安全研究
• 威胁建模
• 人工代码审查

当您需要手动创建需要修复、但并非源自自动化扫描器输出的发现项时，应使用非解析器测试类型。

基于解析器的测试类型#

基于解析器的测试类型可以根据其测试类型名称的确定方式进行分类：

• 固定的测试类型名称：测试类型名称是预先定义好的，在导入之前就已知（例如 “ZAP Scan”、“Nessus Scan”）。

• 由报告定义的测试类型名称：测试类型名称是在导入时从扫描报告内容中提取的。

示例包括：

• Generic Findings Import：根据 JSON 报告中的 type 字段创建测试类型
• SARIF：根据 SARIF 报告中的工具名称创建测试类型（例如 “Dockle Scan (SARIF)"）
• OpenReports：为报告中发现的每个来源创建单独的测试类型

由报告定义的测试类型命名规则：

• 如果报告的 type 字段等于扫描类型 → 直接使用扫描类型（例如 “Generic Findings Import”）
• 如果报告的 type 字段不同 → 创建 “{type} Scan ({scan_type})” 格式（例如 “Tool1 Scan (Generic Findings Import)"）
• 如果报告的 type 字段已经以 " ({scan_type})” 后缀结尾 → 按原样使用，因此后缀不会被重复添加（例如 “Tool1 (Generic Findings Import)” 仍保持为 “Tool1 (Generic Findings Import)"）
• 如果未提供 type 字段 → 直接使用扫描类型

重要注意事项：

• 在导入或重新导入期间检测到新类型时，会自动创建由报告定义的测试类型。
• 对于重新导入，测试类型名称必须完全匹配——不匹配会引发验证错误
• 去重设置（HASHCODE_FIELDS_PER_SCANNER）使用测试类型名称作为键，因此如果您需要自定义去重行为，必须相应地配置由报告定义的名称

测试之间如何相互影响？#

测试会将您的测试数据整理并归类为发现项。通常，安全团队会重复运行相同的测试工作，而 DefectDojo 中的测试可以让您优雅地处理这一过程。

之前导入的测试可以重新导入 - 如果您在同一测试活动的上下文中运行相同类型的测试，可以在每次完成扫描后重新导入测试结果。DefectDojo 会将重新导入的数据与现有结果进行比较，如果扫描数据中存在重复项，则不会创建新的发现项。

测试也可以分开导入 - 如果您在不同的测试活动中对同一资产运行相同的测试，DefectDojo 仍会将该数据与之前的测试进行比较，以查找重复的发现项。这使您能够跟踪之前已缓解或风险已接受的发现项。

如果在没有测试活动的情况下将测试直接添加到资产中，系统会自动创建一个通用测试活动来容纳该测试。这样便可以进行临时性的数据导入。

测试示例：

• Burp 扫描，时间为 2015 年 10 月 29 日至 2015 年 10 月 29 日
• Nessus 扫描，时间为 2015 年 10 月 31 日至 2015 年 10 月 31 日
• API 测试，时间为 2015 年 10 月 15 日至 2015 年 10 月 20 日

发现项#

一旦数据被添加/上传到某个测试中，该数据的结果就会在该测试中以单独的发现项形式列出，供审查。

一个发现项代表在测试过程中发现的一个具体缺陷。

发现项始终具有：

• 唯一的发现项名称
• 被发现的日期
• 多个关联的状态，例如活动、已验证或误报
• 关联的测试
• 一个严重程度级别：严重、高、中、低和信息性（信息）。

发现项可以通过数据导入添加，但也可以手动添加到测试中。

发现项示例：

• OpenSSL “ChangeCipherSpec” 中间人攻击潜在漏洞
• Web 应用程序可能易受点击劫持攻击
• Web 浏览器未启用 XSS 防护

端点#

扫描数据通常会包含对受某个发现项影响的主机或端点的引用。DefectDojo 会自动按端点汇总发现项，因此您可以使用端点视图来查看影响某个特定端点或主机名的所有发现项。

Examples:

• https://www.example.com
• https://www.example.com:8080/products
• 192.168.0.36