资产 (Open Source)

组织 → 资产 → 测试活动 → 测试 → 发现项

概述#

资产是 DefectDojo 对象层级结构中组织安全工作的核心。资产代表贵组织安全团队正在测试的任何项目、计划、软件或实体资产，并承载与该测试目标相关的全部安全工作和测试历史。资产的示例包括：

• 软件发行版
• 第三方软件
• 虚拟机或生产环境中的资产
• 单个应用程序
• 微服务
• API
• SaaS 平台
• 移动应用
• 内部系统
• 业务服务
• 面向客户的平台
• 云环境或基础设施域

总的来说，资产应当代表您希望长期跟踪其安全态势的那个“对象”。这包括与该“对象”相关的测试历史、发现项、指标、所有权归属、集成以及修复工作流程。

资产示例#

根据贵组织的需求，资产的划分可以更加细化。例如，在以下场景中，您可以考虑创建独立的 DefectDojo 资产：

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

虽然您也可以选择将这些差异表示为单个资产内的不同测试活动，但基于角色的访问控制（RBAC）只能在资产或组织级别设置，如果按这种方式组织，可能会限制用户访问相应测试活动（以及这些测试活动中的测试和发现项）的权限。有关 DefectDojo 中 RBAC 和权限的更多信息，请点击此处。

资产数据#

资产始终包含以下组成部分：

• 唯一名称
• 描述
• 组织
• SLA 配置

可选的资产元数据包括：

• 标签
• 人员信息（例如资产经理、团队经理、技术联系人等）
• 法规（例如 HIPAA、GLBA、OPPA 等）
• 业务关键性
• 平台（例如 API、桌面端、物联网、移动端、Web 等）
• 生命周期（例如构建、生产、退役等）
• 来源（例如第三方库、外购、开源等）
• 用户记录数（即该资产中估计的用户记录数量）
• 营收

这些元数据可以改进整个安全项目中的筛选、报告和优先级排序，但更重要的是，资产还包含围绕该资产开展的所有测试活动、测试和发现项。来自各测试的所有发现项最终都会汇总到资产级别，从而支持长期跟踪、趋势分析和报告。

访问资产#

可以通过侧边栏访问资产。子菜单还提供了创建新资产的选项。

权限#

资产可以应用基于角色的访问控制（RBAC）规则，从而限制团队成员查看和操作这些资产的能力。

权限会向下级联，这意味着对某个资产的访问权限会自动授予对该资产内所有对象（例如测试活动、测试和发现项）的访问权限。

有关用户角色的更多信息，请参阅我们的角色介绍文章。

资产视图#

资产视图包含多种表格和图表，可帮助您一目了然地了解某个资产的状态。具体包括：

• 元数据
  • 包括组织、业务关键性、营收，以及在资产设置中添加的其他详细信息。
• 指标
  • 该资产内开放发现项的列表，按严重程度分组
• 按严重程度划分的服务级别协议
  • 将设置中的资产 SLA 配置应用于该资产内的发现项。
• 技术栈
  • 例如 next.js、vue.js、npm v.1.2.3、Django、nginx、Hugo
• 法规
• 基准进度
• 成员
• 组
• 联系人
• 通知
  • 根据特定事件（例如某个测试活动被添加或关闭）开启或关闭通知

使用资产#

创建资产#

创建新资产有多种方式，包括：

• 全部资产列表中的添加资产按钮

• 在某个组织视图中，资产表格的下拉菜单
  • 这将自动在该组织内创建该资产。

• 侧边栏中的添加资产按钮

编辑资产#

可以从资产的设置中编辑该资产，共有两种访问方式：

• 在全部资产视图中，资产左侧 ⋮ 三点菜单内的编辑按钮

• 资产视图中设置下拉菜单内的编辑按钮

删除资产#

删除资产的选项位于上文编辑资产部分所述的相同菜单底部。此操作无法撤销。资产无法先关闭再重新打开。

删除某个资产还会同时删除以下内容：

• 该资产内包含的所有测试活动和测试
• 所有相关的安全历史记录，包括发现项和集成
• 任何关联的 Jira Epic
• 与该资产的测试活动和测试相关联的所有备注和上传文件

资产边界#

去重#

资产之间是彼此“隔离”的，不会与其他资产产生交互。DefectDojo 的智能功能（例如去重）仅在单个资产的范围内生效。不同资产之间的发现项不会自动去重。

指标#

大多数报告和指标都是在资产级别汇总数据的，这使资产成为衡量和跟踪风险的主要单位。

因此，许多关键指标都是按资产计算的，包括：

• 发现项总数（按严重程度或状态划分）
• 平均修复时间（MTTR）
• SLA 合规率和违规率
• 风险随时间的变化趋势

这意味着资产的结构方式会直接影响报告的准确性和实用性。例如，将多个不相关的系统归入同一个资产可能会掩盖风险的可见性，而过于细碎的资产结构则可能使报告变得零散，难以识别更宏观的趋势。

特定资产的指标可以通过所选资产视图顶部栏中的指标按钮访问。

CI/CD 流水线#

CI/CD 流水线可自动导入扫描结果。无论采用何种集成方式，所有扫描导入都必须关联到某个资产，这使得资产成为流水线驱动的安全数据的锚点。

当流水线提交扫描结果时，必须满足以下条件之一：

• 指定一个现有资产（并可选择指定一个测试活动），或者
• 以某种方式进行配置，使结果能够始终一致地映射到正确的资产

所有导入的发现项都会继承该资产的上下文信息，包括所有权归属、权限、SLA 配置和报告范围。

在实践中，资产的定义应当反映系统在 CI/CD 中的构建和部署方式，以确保安全结果始终与正确的应用程序或服务相关联。

Jira 关联关系#

资产可以直接映射到 Jira 项目，从而将该资产的发现项推送到 Jira 实例中。

由于发现项会从其父级资产继承风险、优先级和所有权归属，资产实际上决定了流入 Jira 工单和下游连接器工作流程的修复上下文。

需要特别指出的是，资产同样是决定发现项 SLA 特性的主要因素。因此，某个发现项的 SLA 取决于其父级资产的 SLA 配置。有关 SLA 配置的更多信息，请参见此处。