管理發生事件問題
從法規遵循角度來看,在 持續整合 及 持續合規 管線中建立、儲存及更新發生事件問題 (漏洞、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 合併。
使用案例 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)」管線會根據問題的嚴重性來計算事件問題的到期日。 您可以變更預設寬限期值,並將它們取代為自訂值。
管線會根據下表來計算寬限期:
嚴重性 | 寬限期 |
---|---|
參考資訊 | 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 警示。