管理突发事件问题
从合规性角度来看,作为 Continuous Integration 和 Continuous Compliance 管道的一部分,创建,存储和更新突发事件问题 (漏洞,CVE) 对于证据收集至关重要。
在启用证据收集的 PR 管道、CI 和 CC 管道的执行过程中,collect-evidence
脚本 会创建事件问题,将其附加到收集的证据上,并将其存储到事件问题存储库中。
collect-evidence
脚本使用 cocoa incident process 命令的功能,该命令处理提供的扫描结果,并根据每个漏洞在提供的存储库中创建新的突发事件问题,或者根据主题-突发事件对更新现有突发事件问题。 因此,事件问题与资产绑定,并根据特定工具的结果创建。 有关更多信息,请参阅
CI 和 CC 管道中的问题处理之间的差异。
公关管道中的事件问题处理
当遇到任何漏洞或 CVE 时,启用了证据收集功能的 PR 管道会产生事件问题。 要在 PR 管道中启用证据收集,请参阅:PR 管道证据收集
PR 管道对事件问题的管理与 CI 管道类似。 唯一的区别在于高压灭菌的逻辑。
PR 管道创建的事件问题只能由在同一 PR 上运行的 PR 管道自动处置。 公关管道不能自动解决这个问题:
- 该问题由在任何其他 PR 上运行的 PR 管道发现。
- 任何 CI 或 CC 管道都能发现问题。
事件问题处理
尽管 CI 和 CC 管道具有公共步骤,但这些管道的问题处理存在一些差异:
- 在 CI 管道期间创建的突发事件问题没有到期日期,而在 CC 管道期间创建的突发事件问题没有到期日期。
- 在构建期间发现 CI 管道期间创建的突发事件问题,而在生产环境中发现 CC 管道期间创建的突发事件问题。
图 1-6 显示了基于这些差异的可能用例。
问题生命周期
问题生命周期从代码 PR 扩展到生产扫描。
用例 1: 在构建中找到的漏洞
新构建引入了不接受的漏洞。 除非变更请求是手动核准的紧急 CR,否则将阻止部署。
此构建管道流包含已找到的漏洞,下面说明了相应的用户操作。

用例 2: 在同样位于生产环境中的构建中找到的漏洞
新构建包含当前已部署的生产中也存在的漏洞。 团队具有解决问题的时间线,但仍可部署新功能或修订。
CC 管道设置时间线以修复在生产中发现的任何此类漏洞。 仅当修复漏洞的时间线已到期时,此操作才会失败。 下文概述了这一流程。

用例 2A: 在生产中找到的漏洞允许 PR
生产中的漏洞不会阻止 PR 合并。
用例 3: 误报
如果团队将问题分类为误报,那么可以将该问题标记为 豁免。 然后,可以将该问题作为非阻塞问题处理。 要维护审计跟踪,变更请求会使问题保持可见。
用例 4: 自动关闭已修复的问题
定期运行 CC 管道可以关闭已打开的问题并设置到期日期。 此外,在扫描中找不到相关漏洞。
下图说明了 CC 管道检测要关闭的问题以及要创建新问题的流程图。

设置事件问题的到期日期
如果在生产中发现突发事件问题,那么可以将 Due Date
属性添加到问题中,以指定必须修复该问题的宽限期。 宽限期的持续时间由找到的漏洞的严重性确定。
有关定制宽限期的更多信息,请参阅 在 CC 管道上配置定制宽限期。
标记突发事件问题
由持续集成 (CI) 或持续合规性 (CC) 管道创建的事件问题可以具有缺省标签。
代码风险分析器发现的事件问题的标签
Code Risk Analyzer (CRA) 可检测多种类型的漏洞,例如应用程序依赖关系和映像漏洞。
漏洞类型可以是以下类型: name
os
,python
,js
,golang
或 java
。
如果漏洞类型为 os
,那么会将 os-vulnerability
标签附加到问题。 对于任何其他类型的漏洞,会将 app-vulnerability
标签附加到问题。
具有可用修订的突发事件问题的标签
对于由持续集成 (CI) 管道或持续合规 (CC) 管道创建的事件问题,扫描程序可能在扫描结果中包含补救信息。 如果提供了补救信息,那么会将 fix-available
标签添加到突发事件问题,并在问题描述中添加指向修订描述的链接。
缺少 fix-available
标签并不意味着问题不可操作,因为并非每个扫描程序都在扫描结果中包含修订信息。 扫描程序建议修订信息,该信息来自扫描程序获取此“修订”数据的任何位置。 某些扫描程序可能没有最新的“修订”字典,或者不包含修订的信息。
具有到期日的事件问题
使用 collect-evidence 脚本时,会创建突发事件问题并将其附加到收集的证据。 如果在生产中发现问题,那么它们可以具有指定的时间段,在此时间段内必须修正这些问题,以便不会阻止部署。 为解决生产中的问题而提供的时间范围称为 宽限期。 但是,为了提高可读性,到期日期 现在在突发事件问题中可用,以便用户知道修订到期的日期,而不从宽限期计算该日期。
如果在生产中发现漏洞或 CVE 之类的问题,并且在构建中也发现相同的问题,那么构建不会使情况更糟。 该功能可以部署,团队可以专注于解决生产中的问题。
在 CC 管道上配置定制宽限期
“持续合规性”(CC) 管道根据问题的严重性来计算事件问题的到期日期。 您可以更改缺省宽限期值并将其替换为定制值。
管道根据下表计算宽限期:
严重性 | 宽限期 |
---|---|
参考 | 90 天 |
低 | 45 天 |
中 | 45 天 |
高 | 15 天 |
严重 | 15 天 |
要更改缺省配置,请在 CC 管道的环境属性中创建名为 grace-period-configuration
的新属性。 此环境属性必须是 JSON 字符串,并且与以下格式匹配:
{
"informational": 50,
"low": 40,
"medium": 30,
"high": 20,
"critical": 10
}
如果环境属性与期望的格式不匹配或不是有效的 JSON 字符串,那么管道将使用缺省值。
环境属性 grace-period-configuration
为尚未设置到期日期的问题设置到期日期。 对于设置了到期日期的问题,重新配置 grace-period-configuration
不会更新这些到期日期。
到期日期计算
发现日期是持续合规性 (CC) 管道运行并在生产环境中发现问题的时间。 如果存在该问题,那么 CC 会使用从该时刻开始计算的 到期日期 对其进行更新。
<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>
到期日期格式
到期日期为 ISO 8601
格式,显示为 YYYY-MM-DD。
示例: Due Date: 2022-04-01
用例
-
在 CC 管道生产中的其中一个基本映像中发现漏洞。 将根据漏洞的严重性向团队通知设置了宽限期的突发事件问题。 宽限期是团队必须部署修订的天数。
-
团队使用新功能部件构建新发行版。 构建将查找与用于应用程序的基本映像相关联的 CVE。 团队手动运行 CC 管道,这将扫描已在生产中的工件。 手动 CC 运行将在生产中的同一应用程序中检测相同的 CVE,并将“宽限期”添加到“事件问题”。 现在,该团队可以进行构建和部署,而不会被阻止。
CI 和 CC 管道中的问题处理之间的差异
在 CI 和 CC 管道中都创建了突发事件问题:
- 在 CI 中创建的问题表示在构建期间发现该问题。
- 在 CC 中创建的问题表示在生产环境中发现该问题。
仅当到期日期与生产环境中发现的问题相关时,才能自动将其添加到问题。 这意味着只允许 CC 管道将到期日期添加到问题。 如果 CI 发现问题并且到期日期不可用,那么到期日期的值为 n/a。
将结果处理成问题
将根据特定工具的结果来创建所发现问题的问题。 collect-evidence
脚本尝试处理附件中的结果文件并创建问题列表。
问题与资产绑定,这些资产可以是存储库或具有摘要的 Docker 映像中的落实。
将为每个问题标识创建一个问题-问题标识由以下组件组成:
- 绑定资产
- 发现漏洞的工具
- 漏洞标识 (例如,CVE 标识)
例如,如果通过两个单独的工具找到 CVE-2022-001
,那么该过程会在今天创建两个问题。
支持的工具
目前,支持使用以下工具进行问题处理:
- CRA
- VA
- 戈塞克
- 检测私钥
- OWASP-ZAP API 扫描程序
- OWASP-ZAP UI 扫描程序
- SonarQube
不受支持的工具或结果格式
如果 collect-evidence
脚本从不受支持的工具接收附件,或者在处理期间无法识别结果文件格式,那么该脚本将跳过创建问题并将结果文件用作证据的简单附件。
问题内容
- 问题 是问题或漏洞的名称。
- 到期日期 显示修订到期的日期,如果没有可用的到期日期,那么显示 不适用。
- 主题 是问题绑定到的资产。
- URL 是指向资产的准确版本的链接。
- 工具类型 是生成问题内容的工具
对于在 Git Repos and Issue Tracking上创建的问题,将在 GitLab 本机到期日期字段中设置到期日期,而不是问题描述。
问题描述包含首次发现问题时的时间戳记。 例如,First found on 2022-04-07.
日期为 YYYY-MM-DD
格式。 发生问题的位置将在问题的注释中列出。
推迟事件问题的到期日期
如果要推迟事件问题的到期日期,可以要求安全负责人进行复审。 根据复审,您可以通过修改 Git Repos and Issue Tracking 事件问题元字段中的 Due date
字段来推迟到期日期。

请确保在问题中引用安全焦点复审,例如在注释中提供指向该安全焦点复审的链接。
针对 CC 管道的暂挂问题和逾期问题的闲置警报
“持续合规性”(CC) 管道可以设置事件问题的到期日期。 如果启用了 Slack 集成,那么管道还可以使用 Slack 向用户通知已接近到期日期和逾期到期日期的问题。
有关更多信息,请参阅 设置持续集成(CI)工具链。 有关到期日期的更多信息,请参阅 [具有到期日期的事件问题](/docs/devsecops? topic = devsecops-incident-issues#devsecops-devsecops-issues-due-date)。
通知的问题分类如下:
- 在特定时间范围内具有暂挂到期日期的问题: 已打开的问题,到期日期以及在时间范围内到期的问题。
- 具有过去到期日期的问题: 已打开的问题,具有到期日期以及已通过日期。
时间范围持续时间为 overdue
,due in 1 day
,due in 2 days
,due in 5 days
和 due in 10 days
。
此功能的示例如下所示:
Overdue issues:
- <issue url#1>
- <issue url#2>
- <issue url#3>
Issues due in 1 day:
- <issue url#4>
Issues due in 2 days:
- <issue url#5>
Issues due in 5 days:
- <issue url#6>
- <issue url#7>
Issues due in 10 days
- <issue url#8>
- <issue url#9>
- <issue url#10>
- <issue url#11>
- <issue url#12>
将对聚集列表进行排序,首先列出已逾期的问题,然后列出具有最近到期日期的问题,然后列出具有较晚到期日期的问题。
CC 管道中的 cc-finish
阶段根据条件查询问题,并触发 Slack 警报。