配置 (Pro)
注意：Rules Engine 2.0 是 DefectDojo Pro 专属功能。
Rules Engine 2.0 开箱即用。本页的设置面向那些需要调整吞吐量、保留期或出站网络策略的部署环境。所有这些设置的应用方式都与其他任何 DefectDojo 设置相同（参见配置）。
Rules Engine 2.0 与原有的 Rules Engine 分开配置。两套引擎不共享任何调优参数，因此 DD_RULES_ENGINE_* 设置不会影响 Rules Engine 2.0，DD_RULES_V2_* 设置也不会影响原有引擎。
DD_RULES_V2_EVENT_BATCH=(int, 500),
DD_RULES_V2_CHUNK_SIZE=(int, 1000),
DD_RULES_V2_STALLED_AFTER_MINUTES=(int, 30),
DD_RULES_V2_RUN_TIME_LIMIT_MINUTES=(int, 360),
DD_RULES_V2_ALLOW_PRIVATE_EGRESS=(bool, False),
DD_RULES_V2_DELIVERY_RETENTION_DAYS=(int, 180),
DD_RULES_V2_RUN_RETENTION_DAYS=(int, 180),
DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS=(int, 8000),
DD_RULES_V2_MAX_PER_ITEM_SENDS=(int, 1000),吞吐量
每个事件的发现项数量（DD_RULES_V2_EVENT_BATCH）
默认值：500。
一个事件携带多少个发现项 id。事件要跨越一个异步边界，因此要保持足够小，以维持消息的低成本。较大的写入会分散成多个事件，每个事件都会成为一次独立的运行。
调高该值会产生更少、更大的运行；调低则会产生更多、更小的运行。
每个分块的发现项数量（DD_RULES_V2_CHUNK_SIZE）
默认值：1000。
一次运行同时在内存中保留多少个发现项。运行是按分块处理的，因此这是一个内存旋钮，而不是规则处理量的上限：规则始终会处理其作用范围匹配到的全部内容。
每个发现项的信封（envelope）大小大约是 2.7KB，因此默认值一次会占用几兆字节的内存。调高它是用内存换取更少的往返次数；调低则相反。
信封文本上限（DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS）
默认值：8000。设为 0 可禁用。
条目携带的 description、mitigation 和 impact 字符数上限。
这三个字段占据了信封大小的大部分。设置该上限是为了应对一种特殊情况：某个发现项的描述非常长，以至于满满一个分块的大小会远超分块大小设置暗示的规模。这个上限相当宽松，一般实例根本不会察觉到它的存在。
请注意，这会影响条件和模板所能看到的内容。针对一段很长描述的末尾进行匹配的条件，将看不到超出该上限的文本。
运行生命周期
停滞窗口（DD_RULES_V2_STALLED_AFTER_MINUTES）
默认值：30。
一次运行在被视为已放弃、标记为出错、并释放其按规则加的锁之前，可以有多久没有心跳。
运行在每个分块处理完后都会打一次心跳，因此这个时长是从最近一次心跳开始计算的，而不是从运行开始时计算。一次仍在推进的长时间扫描永远不会被误判为已崩溃的工作进程，这正是该窗口得以保持较短的原因。
运行时长上限（DD_RULES_V2_RUN_TIME_LIMIT_MINUTES）
默认值：360，即六小时。
单次运行在被工作进程终止之前，最长可以运行多久。
这是为了防范某条规则永远无法完成、却一直占用工作进程槽位及其规则执行锁的情况。这个值被有意设得比较宽松，因为对一个非常大的作用范围进行分块扫描，正是本引擎所要应对的工作负载类型。
保留期
有两个任务负责限制该功能所产生的三张表的大小。两者默认都是 180 天，都可以设为 0 以完全禁用清理。
保留期在产品中是明确呈现的，而非隐晦不明的：API 会同时提供保留窗口以及某条记录将被删除的具体日期，展示某次运行或某条投递记录的页面也会用一句话说明这一点。日期是在读取时计算的，因此更改窗口会立即生效，而不是只对新记录生效。
DD_RULES_V2_DELIVERY_RETENTION_DAYS
默认值：180。
一条已完成的投递记录会被保留多少天。
这是该功能中增长最快的表。一个按发现项处理的出站节点，每次运行都可能写入多达一整个分块数量的行，模拟模式下也不例外。如果您需要更长的出站审计轨迹就调高它，如果数据量成为问题就调低它。
DD_RULES_V2_RUN_RETENTION_DAYS
默认值：180。
一次已完成的运行，连同其按节点的记录行及其发现项溯源信息，会被保留多少天。
运行这一侧的增长比投递记录更快，因为溯源信息是“每次运行、每个更改类节点、每个发现项”各一行。一条针对大范围作用域每小时运行一次的规则，会产生大量此类数据。
一次仍持有投递记录的运行，会一直保留到那些投递记录被清理为止，因此将运行的保留窗口设得比投递记录的保留窗口短，并不会产生孤立数据。
出站目的地校验
有两个节点设置以自由文本形式接受目的地，而不是从已配置的对象中选择：Call a Webhook 节点上的 URL，以及 Send an Email 节点上的 To。两者都会在保存规则时进行校验。
对于 Webhook URL：
- 只接受
http和https。其他协议一律拒绝。 - URL 必须包含主机（host）。
- 默认情况下，解析到回环地址、链路本地地址、私有地址、保留地址或组播地址的主机会被拒绝。
对于电子邮件地址，空地址会被拒绝，包含换行符的地址也会被拒绝，因为那属于请求头注入。
之所以要做网络校验，是因为发送请求的工作进程通常位于您的集群内部，能够触及的内部网络范围，远超编写该规则的人所能触及的范围。如果没有这项检查，一个自由文本形式的 URL 就是一个请求伪造原语：把它指向某个元数据服务或内部管理端口，响应就会通过投递记录台账被带回来。
这是纵深防御，而非唯一的控制手段。反正 Rule Edit 本来就接近于管理权限。设置这项检查的价值在于，让某个被过度授予的角色所造成的影响范围，不至于是“可读取任意内部 HTTP 端点”，也让一次拼写错误能在保存时就以清晰的错误信息失败，而不是在发送时以连接错误的形式失败。
允许私有地址（DD_RULES_V2_ALLOW_PRIVATE_EGRESS）
默认值：关闭。
关闭网络地址检查，使 Webhook 可以向回环地址、链路本地地址和私有地址发送请求。协议和格式校验仍然适用。
如果您确实需要向某个私有地址上的服务发送 Webhook——自托管的聊天或 Webhook 接收端通常就是这种情况——可以开启此项。
每个发现项的发送上限
DD_RULES_V2_MAX_PER_ITEM_SENDS
默认值：1000。设为 0 可取消上限。
单个出站节点在一次运行中，针对每个发现项最多记录的发送次数。
启用了**每个发现项一条消息（One Message per Finding）**的节点，会为每个发现项产生一条投递记录行和一个排队任务。由于一次运行没有条目数量上限，作用范围非常宽、又开启了按发现项发送的规则，否则会导致两者的数量都变得没有边界。
超过该上限后，节点会记录一次可见的跳过（visible skip），说明有多少个发现项没有被发送。它不会导致运行失败，也不会悄无声息地停止。
相关设置
部分 Rules Engine 2.0 节点使用的是系统级的集成配置，而不是节点自身的配置：
- Send a Slack Message 使用系统级的 Slack 令牌，如果节点未指定频道，则回退使用系统级的 Slack 频道。
- Send a Microsoft Teams Message 使用系统设置中的 Microsoft Teams Webhook。
- Create a JIRA Issue 使用产品的 JIRA 配置来填写摘要、描述和优先级。
- Raise an In-App Alert 会遵循每位接收者自己的 Rules Engine Match 通知设置。