关于 Rules Engine 2.0 (Pro)

注意：Rules Engine 2.0 是 DefectDojo Pro 专属功能。

Rules Engine 2.0 是一个可视化自动化构建器。规则不再是“一个过滤器加一份扁平的动作列表”，而是一个图（graph）：一个决定规则何时被唤醒的触发器节点，以及任意数量相互连接的逻辑、发现项和出站（egress）节点，用来说明接下来会发生什么。

Rules Engine 2.0 只能通过 Pro UI 访问。

相较于 Rules Engine 新增了什么#

原有的 Rules Engine 会将一份有序的动作列表应用到匹配某个过滤器的每一个发现项上。Rules Engine 2.0 保留了这一能力，并新增了四项内容：

• 分支。 If / Filter 节点会将条目分流到“真”分支和“假”分支，因此一条规则就能对严重发现项与其他发现项采取不同处理方式，而无需拆分成两条规则。
• 出站（Egress）。 规则可以离开 DefectDojo：打开一个 JIRA 问题单或下游工单、发布到 Slack 或 Microsoft Teams、发送邮件、调用 Webhook、发出应用内提醒，或生成报告。
• 可追溯性。 每次执行都会作为一次运行（Run）按节点逐一记录，每次出站发送都会作为一条投递记录（Delivery）记录下来，准确说明发送了什么、发到了哪里、结果如何。
• 模拟模式。 规则可以精确记录它本会发送的内容而不实际发送，这就是在让规则接触外部世界之前安全测试它的方式。

两套引擎并行运行。启用 Rules Engine 2.0 不会禁用或转换您现有的规则，并且提供了一个转换器，供您在想要迁移规则时使用。

启用 Rules Engine 2.0#

Rules Engine 2.0 处于 Beta 阶段，默认关闭。超级用户可以在 Settings > Feature Flags 中启用它，云端和本地部署实例均适用。参见功能标志。

标志启用后，侧边栏会出现一个 Rules Engine 2.0 区块，下面有三个页面：

权限#

访问权限由两个全局角色权限控制，与原有 Rules Engine 共用：

• Rule View 用于查看侧边栏该区块及其下的所有内容。
• Rule Edit 用于创建、修改、运行、删除、转换、接管所有权以及重放。

Rule Edit 接近于管理权限。规则作者可以触及其规则所有者能看到的任何发现项，并能将输出定向到外部系统，因此请谨慎授予。

核心概念#

规则与图#

一条规则由名称、描述、所有者、模式、启用开关和一张图组成。图是一组节点（node）及节点之间的边（edge）。图中必须恰好包含一个触发器节点，且不能包含环。除此之外的一切都由您决定，包括让某个节点保持未连接——这只是意味着它在没有任何输入的情况下运行。

新建规则总是以禁用状态创建，因此启用规则是一个需要主动执行的操作。

条目（Items）#

沿着图的边流动的是一个条目（item）：一份发现项及其周边上下文的 JSON 快照。

{
  "finding":      { "id": 1234, "title": "...", "severity": "High", "...": "..." },
  "test":         { "id": 12, "title": "...", "scan_type": "..." },
  "engagement":   { "id": 5,  "name": "..." },
  "product":      { "id": 3,  "name": "..." },
  "product_type": { "id": 1,  "name": "..." },
  "ctx":          { "trigger": "finding.created", "depth": 0, "source": "app" }
}

条件和消息模板都是针对该结构中的路径来编写的，例如 finding.severity 或 product.name。完整字段列表见构建规则。

所有者#

每条规则都以其所有者的身份运行。它所能看到的发现项，与该用户本人能看到的完全一致，使用的是产品中其他地方通用的同一套授权机制。有两点后果值得了解：

• 缩小规则所有者的访问权限，也会缩小该规则的作用范围。
• 若规则所有者的账户被删除，规则就没有了所有者，因此它将不匹配任何内容，也不会执行任何操作。为其指定一个新的所有者，或在规则列表中使用接管所有权（Take Ownership），即可恢复它。

模式：模拟（Simulate）或实时（Live）#

模式按规则设置，而非按节点设置。

• Simulate（默认）会真实运行整张图，包括每一次发现项编辑，但出站节点只会记录它本会发送的内容，到此为止。不会有任何内容离开 DefectDojo。
• Live 会真正执行发送。

模拟发送仍会出现在 Deliveries 台账中，标记为 simulated，并附带完整载荷。这正是在放出规则之前对其进行审查的预期方式。

模式是有意针对整条规则生效的。一张图里部分发送是真实的、部分不是，会比拆成两条规则更难推理。

运行（Runs）#

规则的一次执行就是一次运行（Run）。一次运行会记录触发它的事件、其状态、按节点的追踪记录，以及任何错误。一条规则同一时刻只能有一次运行在进行中，因此繁忙的规则会排队，而不会与自身竞争。

投递记录（Deliveries）#

每一次出站副作用都是投递记录（Deliveries）台账中的一行，会在任何网络调用发生之前写入。该行保存载荷、解析出的目的地、状态、重试次数，以及目的地返回的任何内容。跳过操作也会被记录，因此“规则什么都没做”和“规则什么都没做是因为该发现项已经开过工单”是可以区分的。

溯源（Provenance）#

规则对发现项所做的每一次更改都会被追溯到具体的规则、运行和执行更改的节点。这条时间线在发现项本身上即可查看，因此您无需阅读规则定义就能回答“这个发现项为什么会变化？”。

规模#

规则会处理其作用范围（scope）匹配到的一切内容。一次运行能处理多少发现项没有上限：它会分块处理，以便让内存占用保持有界，而不是牺牲覆盖面。只有 Preview 会设置上限，并且在触发上限时会明确告知您。

保留期#

运行记录和投递记录默认都保留 180 天，之后会被清理。产品会向您展示保留窗口以及某条记录将被删除的具体日期，而不是让这一点变得隐晦，并且两个窗口都是可配置的。参见配置。

接下来可以阅读#

• 构建规则介绍编辑器、触发器、作用范围、条件和模板。
• 节点参考记录了全部 25 个节点。
• 运行（Runs）介绍执行、追踪、级联和限制。
• 投递记录（Deliveries）介绍渠道、状态、重试和重放。
• 从 Rules Engine 转换介绍如何迁移现有规则。
• 配置介绍部署层面的设置。