管理突发事件问题

从合规性角度来看，作为 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 扩展到生产扫描。

DevSecOps/单一管道生命周期

用例 1: 在构建中找到的漏洞

新构建引入了不接受的漏洞。除非变更请求是手动核准的紧急 CR，否则将阻止部署。

下图解释了发现漏洞时的构建管道流程以及相应的用户操作。

用例 2: 在同样位于生产环境中的构建中找到的漏洞

新构建包含当前已部署的生产中也存在的漏洞。团队具有解决问题的时间线，但仍可部署新功能或修订。

![在同时投入生产的构建版中发现的漏洞](images/vuln-uc-2.svg "在同时投入生产的构建版中发现的漏洞 ""){: caption="在同时投入生产的构建版中发现的漏洞 "" caption-side="bottom"}在同时投入生产的构建版中发现的漏洞

CC 管道设置时间线以修复在生产中发现的任何此类漏洞。仅当修复漏洞的时间线已到期时，此操作才会失败。流程如下图所示。

用例 2A: 在生产中找到的漏洞允许 PR

生产中的漏洞不会阻止 PR 合并。

![在生产中发现的漏洞允许发布 PR](images/vuln-uc-2a.svg "在生产中发现的漏洞允许发布 PR ""){: caption="在生产中发现的漏洞允许发布 PR "" caption-side="bottom"}在生产中发现的漏洞允许发布 PR

用例 3：误报与豁免

如果团队将某个问题归类为“误报”，或者针对某个漏洞收到了安全豁免通知，则该问题可标记为“豁免”。然后，可以将该问题作为非阻塞问题处理。要维护审计跟踪，变更请求会使问题保持可见。

用例 4: 自动关闭已修复的问题

定期运行 CC 管道可以关闭已打开的问题并设置到期日期。此外，在扫描中找不到相关漏洞。

下图说明了 CC 管道检测要关闭的问题以及要创建新问题的流程图。

![CC 管道自动关闭已修复问题](images/issue-mgmt-CC-flow-vuln-autoclosing.jpg "CC管道自动关闭已修复问题 "")

管理事件问题的截止日期

当在生产环境中发现问题时，系统会自动添加 Due Date 属性，以指定必须在该宽限期内修复该问题。宽限期的持续时间由找到的漏洞的严重性确定。

常见的到期日情况

以下场景描述了如何管理截止日期：

初始截止日期分配：当 CC 管道在生产环境中发现一个问题时，会根据该问题的严重程度自动计算并设置截止日期。
截止日期延期：如果您需要更多时间来修复某个问题，可在获得安全联络人的批准后延长截止日期。详情请参阅“推迟截止日期”。
逾期问题：即使问题已逾期，只要新构建不会导致生产环境状况恶化，CI 管道仍可继续进行部署（纯粹的风险管理方法）。这使得团队在解决安全问题的同时，仍能继续交付功能。

有关定制宽限期的更多信息，请参阅在 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) 管道根据问题的严重性来计算事件问题的到期日期。您可以更改缺省宽限期值并将其替换为定制值。

管道根据下表计算宽限期:

默认宽限期
严重性	宽限期
参考	180 天
低	180 天
中	90 天
高	30 天
严重	30 天

要更改缺省配置，请在 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，那么该过程会在今天创建两个问题。

支持的工具

事件问题处理功能支持集成到 DevSecOps 管道中的各种扫描工具生成的结果。有关当前支持的扫描工具及其功能的列表，请参阅 “支持的扫描工具”。

不受支持的工具或结果格式

如果 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”字段。
- 对于 GitHub Enterprise：请在问题描述中编辑 Due date 字段。
在该问题中引用安全联络人的批准，方法是添加一条包含审核或批准文件链接的评论。

设置和更新Git Repos and Issue Tracking的到期日 — 设置并更新Git Repos and Issue Tracking的到期日

请确保在问题中引用安全焦点复审，例如在注释中提供指向该安全焦点复审的链接。

安全例外

如果您遇到安全豁免相关的问题，可以将截止日期延长至与该豁免的到期日一致。这可确保在例外情况失效之前，证据收集和合规跟踪工作能够持续、妥善地进行。

针对 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 警报。