自動化漏洞修補：從發現到修正

什麼是自動化漏洞修補

漏洞修補是指從軟體中移除已知漏洞：升級受影響的套件、套用修補程式，或替換該元件。自動修補則是把其中機械性的工作交給軟體處理。它會讀取檢測結果、找出能修正該漏洞的版本、修改資訊清單檔、lockfile 或程式碼，並提出變更，最常見的形式是 pull request。

對於第三方相依套件，也就是現代程式碼庫中大部分已知漏洞所在之處，每個工具的流程都相同：

1. 資產清冊。掌握您交付的每項產品中有哪些套件、各是哪個版本。
2. 比對。將資產清冊與資安公告比對，並在新公告發布時持續比對。
3. 排定優先順序。依嚴重程度、遭利用情況與曝險程度，決定先修正什麼。
4. 修正。選出已修正的版本並完成更新，若升級造成問題則調整程式碼。
5. 驗證。建置並測試變更，再確認實際交付的就是已修正的版本。
6. 記錄。保留紀錄：哪些受到影響、何時修正，以及在哪個版本發布中修正。

自動化在第 2、4、6 步最能發揮作用，因為這些工作具重複性。在輸入有誤時，它最為薄弱，而其他所有步驟的輸入都是第 1 步。

四種自動修補方式

方式	功能	範例	局限
相依套件更新機器人	開啟 pull request，將有漏洞的相依套件升級到已修正的版本	Dependabot security updates、Renovate	依據儲存庫中的資訊清單檔與 lockfile 運作；破壞性升級仍需由人調整程式碼
SCA 修正 pull request	針對商用 SCA 工具提出的檢測結果開啟升級 pull request	Snyk、Black Duck、Aikido、Endor Labs	涵蓋範圍不一：有些工具只修正直接相依套件，有些會加入修補程式或向後移植
AI 程式碼修正	為檢測結果產生程式碼變更，通常是靜態分析警示	GitHub Copilot Autofix	非確定性的建議，需要審查；請參閱 AI 修補
基礎架構自動修補	在規則觸發時還原錯誤設定或修補主機	雲端安全態勢與端點工具	涵蓋的是執行中的基礎架構，而非您交付的軟體內部的相依套件

前三種都是修正您交付的程式碼，而且都有一個共同的假設：它們要修正的有漏洞套件清單是正確的。

每個修正都仰賴資產清冊

修補工具只能修正它知道的漏洞，而它知道的，就是資產清冊所包含的漏洞。大多數資產清冊是從檔案重建而來：資訊清單檔、lockfile、已安裝的套件或完成的容器映像檔。這種重建會以可預期的方式遺漏某些東西。

• 檔案中未宣告的套件。建置下載的工具、基礎映像檔、外掛，以及由腳本安裝的任何東西，都不會出現在 lockfile 中，因此永遠不會有針對它們的修正 pull request。
• 與 lockfile 不同的版本。建置解析出的版本，可能與掃描工具讀到的版本不同，尤其是在未提交 lockfile 的情況下。以錯誤版本為依據的修正，是一個自信滿滿的錯誤答案。
• 從快取還原的套件。快取的相依套件不會再次連到登錄庫，因此建置實際使用的內容，可能落後於儲存庫所記載的內容。

解決之道是從建置實際使用的內容出發。建置時 SBOM 是在建置執行時記錄的，因此它列出的是作業實際拉取的套件，包括遞移相依套件，而不是資訊清單檔認為應該需要的套件。從這裡開始的修補，修正的才是實際交付的內容。

哪些該自動化、哪些該保留

多數成功推動修補的團隊會這樣分工：

• 自動化發現與比對。每天都有新的資安公告發布。以人工方式將每個已交付的建置與這些公告重新比對無法擴展，而這正是軟體擅長的工作。
• 自動化提案。選出已修正的版本並開啟變更是機械性的工作。將相關的更新分組，讓審查者看到的是一個 pull request，而不是二十個。
• 以測試把關合併。對測試套件涵蓋的修補層級資安更新啟用自動合併。破壞性升級及任何缺乏測試涵蓋的變更，則保留給人處理。
• 判斷交由人來做。某個漏洞是否真的影響您的產品，以及本週是否值得進行有風險的升級，都是需要決策的事。請將這些決策記錄下來，例如以 VEX 聲明的形式，避免同一個問題被問兩次。

如何評估修補工具

在信任一個工具在您的儲存庫中開啟 pull request 之前，請先確認：

1. 它的漏洞清單從何而來：儲存庫中的檔案、掃描過的映像檔，還是建置本身？
2. 它會修正遞移相依套件，還是只修正您宣告的直接相依套件？
3. 它如何選擇修正版本：最低的已修補版本、最新版本，還是您鎖定的版本？
4. 修正在您看到之前是否已經建置並測試過，還是 pull request 才是它第一次執行？
5. 它能否將更新分組並排程，以免審查者應接不暇？
6. 它是否記錄哪些版本發布受到影響，以及每個修正何時交付？

CRACI 目前的定位

CRACI 在自己的執行器上執行您的 GitHub Actions 作業，並記錄每個作業實際取得的套件，包括遞移相依套件與從快取還原的套件，並為每個作業標示完整度狀態。這份紀錄，正是修補工作流程應該依據的資產清冊。

CRACI 會持續重新評估受監控的 SBOM，因此當新的資安公告發布時，您可以看到它影響您各儲存庫中的哪些已交付建置。資安團隊會分級研判每項檢測結果，並將它交給負責修正的團隊；CRACI 也支援以 VEX 記錄漏洞如何影響您的產品。接著，下一次建置的 SBOM 會顯示建置實際使用的是否為已修正的版本。漏洞追蹤頁面說明了完整的功能。

根據歐盟 Cyber Resilience Act（CRA），製造商必須毫不延遲地處理並修補漏洞，包括透過資安更新。記錄每個建置包含哪些內容、每個修正何時交付，正是這個流程所需要的佐證資料。

自動化漏洞修補：常見問題

什麼是自動化漏洞修補？

自動化漏洞修補是指由軟體將漏洞檢測結果轉為修正，而不需要人親自處理繁瑣的工作：它會找出已修正的版本、修改資訊清單檔、lockfile 或程式碼，並提出變更，通常是以 pull request 的形式。至於哪些變更可以合併，仍由人或團隊信任的政策決定。

漏洞修補與緩解有什麼不同？

修補是移除漏洞，例如升級到已修正的版本或套用修補程式。緩解則是在漏洞仍存在時降低風險，例如停用受影響的功能或阻斷攻擊路徑。緩解是爭取時間；修補才能結案。

漏洞修補可以完全自動化嗎？

部分可以。找出受影響的建置、比對資安公告與提出版本升級，都是機械性的工作，很適合自動化。判斷破壞性升級是否安全，或某個漏洞是否真的影響您的產品，仍需要判斷力。多數團隊會自動化提案，並在合併時保留由人把關，再輔以測試。

Dependabot 能做自動化漏洞修補嗎？

Dependabot security updates 會針對 GitHub 在您儲存庫相依關係圖上提出的警示開啟 pull request，將有漏洞的相依套件更新到最低的已修補版本。這是針對資訊清單檔與 lockfile 所宣告內容的自動修補。CRACI vs Dependabot 說明了宣告內容與實際交付內容的差異。

選擇漏洞修補工具時該注意什麼？

它的漏洞清單從何而來、是否處理遞移相依套件、如何挑選修正版本、修正在您看到之前是否已建置並測試，以及是否記錄修正了什麼、何時修正。最後一點對稽核與 CRA 都很重要，因為 CRA 要求製造商毫不延遲地修補漏洞。