IBM Cloud Docs
管理發生事件問題

管理發生事件問題

從法規遵循角度來看,在 持續整合持續合規 管線中建立、儲存及更新發生事件問題 (漏洞、CVE),對於證明收集而言很重要。

在啟用證據收集的 PR 管道、CI 和 CC 管道的執行過程中,collect-evidence 腳本 會建立事件問題,將它們附加到收集的證據,並將它們儲存在事件問題儲存庫中。

collect-evidence Script 使用 cocoa incident process 指令的功能,該指令會處理提供的掃描結果,並根據漏洞在提供的儲存庫中建立新的發生事件問題,或根據主旨-發生事件配對更新現有的發生事件問題。 因此,發生事件問題會連結至資產,並根據特定工具的結果來建立。 如需相關資訊,請參閱 CI 與 CC 管線中問題處理之間的差異

PR 管道中的事件問題處理

當遇到任何漏洞或 CVE 時,啟用證據收集的 PR 管道可能會產生事件問題。 若要在 PR 管道中啟用證據收集,請參閱:PR 管道證據收集

PR 管道中針對事件問題的問題管理與 CI 管道類似。 唯一的差別在於自動關閉邏輯。

PR 管道建立的事件問題只能由同一 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 探索到事件問題的標籤

Code Risk Analyzer (CRA) 可偵測多種類型的漏洞,例如應用程式相依關係及映像檔漏洞。

漏洞類型可以如下: name ospythonjsgolangjava

如果漏洞類型是 os 類型,則會將 os-vulnerability 標籤附加至問題。 對於任何其他類型的漏洞,會將 app-vulnerability 標籤附加至問題。

具有可用修正程式之發生事件問題的標籤

對於持續整合 (CI) 管線或持續相符性 (CC) 管線所建立的發生事件問題,掃描器可能具有補救資訊作為掃描結果的一部分。 如果補救資訊可用,則會將 fix-available 標籤新增至事件問題,並鏈結至問題說明內的修正程式說明。

缺少 fix-available 標籤並不表示問題無法採取行動,因為並非每個掃描器都在掃描結果中包含修正程式資訊。 掃描器會建議修正程式資訊,而該資訊來自掃描器取得此「修正程式」資料的任何地方。 部分掃描器可能沒有最新的「修正程式」字典,或未包含修正程式的資訊。

具有到期日的事件問題

當您使用 collect-evidence Script 時,會建立發生事件問題,並將其附加至所收集的證明。 如果在正式作業中發現問題,則必須修正它們的指定時段,以便不會封鎖部署。 提供在正式作業中修正問題的時間範圍稱為 寬限期。 不過,為了更好的可讀性,現在可以在發生事件問題中使用 到期日,讓使用者知道修正程式到期的日期,而不需要從寬限期開始計算。

如果在正式作業中發現漏洞或 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 Script 會嘗試處理附件中的結果檔案,並建立問題清單。

問題會連結至資產,這些資產可以是儲存庫中的確定或具有摘要的 Docker 映像檔。

每個問題 ID 都會建立一個問題-問題 ID 由下列元件組成:

  • 連結資產
  • 找到漏洞的工具
  • 漏洞 ID (例如 CVE ID)

例如,如果由兩個個別工具找到 CVE-2022-001,則處理程序今天會產生兩個問題。

受支援的工具

目前支援下列工具進行問題處理:

  • Cra
  • VA
  • 戈塞克
  • 偵測密鑰
  • OWASP-ZAP API 掃描器
  • OWASP-ZAP 使用者介面掃描器
  • SonarQube

不受支援的工具或結果格式

如果 collect-evidence Script 從不受支援的工具接收附件,或在處理期間無法辨識結果檔案格式,則 Script 會跳過建立問題,並使用結果檔案作為證明的簡式附件。

問題內容

  • 問題 是問題或漏洞的名稱。
  • 到期日 會顯示修正程式到期的日期,如果沒有可用的「到期日」,則會顯示 n/a
  • 主旨 是問題所連結的資產。
  • URL 是資產確切版本的鏈結。
  • 工具類型 是產生問題內容的工具

對於在 Git Repos and Issue Tracking上建立的問題,會在 GitLab 原生到期日欄位中設定到期日,而不是問題說明。

問題說明包含第一次探索問題時的時間戳記。 例如,First found on 2022-04-07. The date is in YYYY-MM-DD format. 問題發生的位置會列在問題的註解中。

延遲事件問題的到期日

如果您想要延遲事件問題的到期日,可以向安全聯絡人要求檢閱。 視檢閱而定,您可以延遲到期日,方法是修改 Git Repos and Issue Tracking 發生事件問題 meta 欄位中的 Due date 欄位。

設定及更新到期日 Git Repos and Issue Tracking
圖 2. 在 Git Repos and Issue Tracking
設定及更新到期日

請務必參照問題中的安全焦點檢閱,例如在註解中提供其鏈結。

CC 管線擱置及逾期問題的 Slack 警示

「持續合規 (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 警示。