IBM Cloud Docs
管理突发事件问题

管理突发事件问题

从合规性角度来看,作为 Continuous IntegrationContinuous 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。 DevSecOps/one 管道生命周期

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

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

在构建中找到的漏洞
图 2。 在构建
中发现漏洞

此构建管道流包含已找到的漏洞,下面说明了相应的用户操作。

构建管道检测到漏洞
构建管道检测到漏洞

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

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

在同样在生产中的构建中找到的漏洞
图 3。 在同样位于生产
中的构建中发现漏洞

CC 管道设置时间线以修复在生产中发现的任何此类漏洞。 仅当修复漏洞的时间线已到期时,此操作才会失败。 下文概述了这一流程。

在生产中找到的漏洞
在生产中找到的漏洞

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

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

在生产中找到的漏洞允许 PR
图 4。 在生产环境中发现的漏洞允许 PR

用例 3: 误报

如果团队将问题分类为误报,那么可以将该问题标记为 豁免。 然后,可以将该问题作为非阻塞问题处理。 要维护审计跟踪,变更请求会使问题保持可见。

误报
图 5。 假正例

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

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

自动关闭固定问题
图 6。 自动关闭已解决的问题

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

CC 管道自动关闭固定问题
图 6。 CC 管道自动关闭已解决的问题

设置事件问题的到期日期

如果在生产中发现突发事件问题,那么可以将 Due Date 属性添加到问题中,以指定必须修复该问题的宽限期。 宽限期的持续时间由找到的漏洞的严重性确定。

有关定制宽限期的更多信息,请参阅 在 CC 管道上配置定制宽限期

标记突发事件问题

由持续集成 (CI) 或持续合规性 (CC) 管道创建的事件问题可以具有缺省标签。

代码风险分析器发现的事件问题的标签

Code Risk Analyzer (CRA) 可检测多种类型的漏洞,例如应用程序依赖关系和映像漏洞。

漏洞类型可以是以下类型: name ospythonjsgolangjava

如果漏洞类型为 os,那么会将 os-vulnerability 标签附加到问题。 对于任何其他类型的漏洞,会将 app-vulnerability 标签附加到问题。

具有可用修订的突发事件问题的标签

对于由持续集成 (CI) 管道或持续合规 (CC) 管道创建的事件问题,扫描程序可能在扫描结果中包含补救信息。 如果提供了补救信息,那么会将 fix-available 标签添加到突发事件问题,并在问题描述中添加指向修订描述的链接。

缺少 fix-available 标签并不意味着问题不可操作,因为并非每个扫描程序都在扫描结果中包含修订信息。 扫描程序建议修订信息,该信息来自扫描程序获取此“修订”数据的任何位置。 某些扫描程序可能没有最新的“修订”字典,或者不包含修订的信息。

具有到期日的事件问题

使用 collect-evidence 脚本时,会创建突发事件问题并将其附加到收集的证据。 如果在生产中发现问题,那么它们可以具有指定的时间段,在此时间段内必须修正这些问题,以便不会阻止部署。 为解决生产中的问题而提供的时间范围称为 宽限期。 但是,为了提高可读性,到期日期 现在在突发事件问题中可用,以便用户知道修订到期的日期,而不从宽限期计算该日期。

如果在生产中发现漏洞或 CVE 之类的问题,并且在构建中也发现相同的问题,那么构建不会使情况更糟。 该功能可以部署,团队可以专注于解决生产中的问题。

在 CC 管道上配置定制宽限期

“持续合规性”(CC) 管道根据问题的严重性来计算事件问题的到期日期。 您可以更改缺省宽限期值并将其替换为定制值。

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

表 1. 缺省宽限期
严重性 宽限期
参考 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 字段来推迟到期日期。

在 Git Repos and Issue Tracking
图 2。 在 Git Repos and Issue Tracking
上设置和更新到期日期

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

针对 CC 管道的暂挂问题和逾期问题的闲置警报

“持续合规性”(CC) 管道可以设置事件问题的到期日期。 如果启用了 Slack 集成,那么管道还可以使用 Slack 向用户通知已接近到期日期和逾期到期日期的问题。

有关更多信息,请参阅 设置持续集成(CI)工具链。 有关到期日期的更多信息,请参阅 [具有到期日期的事件问题](/docs/devsecops? topic = devsecops-incident-issues#devsecops-devsecops-issues-due-date)。

通知的问题分类如下:

  • 在特定时间范围内具有暂挂到期日期的问题: 已打开的问题,到期日期以及在时间范围内到期的问题。
  • 具有过去到期日期的问题: 已打开的问题,具有到期日期以及已通过日期。

时间范围持续时间为 overduedue in 1 daydue in 2 daysdue in 5 daysdue 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 警报。