管理發生事件問題

從法規遵循角度來看，在持續整合及持續合規管線中建立、儲存及更新發生事件問題 (漏洞、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: 建置中發現的漏洞

新建置會建立一個漏洞，但不接受此漏洞。除非變更要求是手動核准的緊急 CR，否則會封鎖部署。

中發現漏洞

此建置管線流程包含找到的漏洞，且對應的使用者動作說明如下。

使用案例 2: 在建置中找到也在正式作業中的漏洞

新建置包含的漏洞也在目前已部署的正式作業中。團隊有一個時間表來修正問題，但仍可以部署新的特性或修正程式。

CC 管線會設定時間表，以修正在正式作業中找到的任何此類漏洞。只有在修正漏洞的時間表已過期時，它才會失敗。流程概述如下。

在正式作業中找到的使用案例 2A: 漏洞容許 PR

正式作業中的漏洞不會阻止 PR 合併。

在正式作業中找到的漏洞容許 PR — 圖 4. 在正式作業中發現的漏洞容許 PR

使用案例 3: 誤判

如果團隊將問題分類為誤判，則問題可以標示為豁免。然後可以將問題當作非封鎖問題來處理。如果要維護審核追蹤，變更要求會保持可見的問題。

使用案例 4: 自動關閉已修正的問題

定期執行 CC 管線可以關閉已開啟且已設定到期日的問題。此外，在掃描中找不到相關漏洞。

下圖說明 CC 管線偵測要關閉哪些問題，以及要建立全新問題的流程圖。

設定事件問題的到期日

如果在正式作業中找到突發事件問題，可以將 Due Date 內容新增至問題，以指定必須修正它的寬限期。寬限期的持續時間取決於所找到漏洞的嚴重性。

如需自訂寬限期的相關資訊，請參閱在 CC 管線上配置自訂寬限期。

標示發生事件問題

持續整合 (CI) 或持續合規 (CC) 管線所建立的發生事件問題可以具有預設標籤。

Code Risk Analyzer 探索到事件問題的標籤

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

漏洞類型可以如下: name os、python、js、golang 或 java。

如果漏洞類型是 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 欄位。

設定及更新到期日

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

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

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