一個重大漏洞公布了，資安公告迅速傳開，不到一小時，就有人在公司聊天群組裡問：我們受影響了嗎？Log4Shell 讓這個問題廣為人知。CVE-2021-44228 影響了 2.0-beta9 到 2.15.0 的 Log4j Core，這個函式庫深藏在無數 Java 產品相依關係樹的好幾層之下，大多數團隊都是費盡千辛萬苦，才找出它到底在哪裡。

這個問題聽起來很簡單，實際上卻是三個問題：

  1. 有漏洞的元件，是否存在於我們建置或交付的任何產品中？
  2. 如果存在，它在我們的產品中能被利用嗎？
  3. 從何時開始，又存在於哪些版本中？

大多數流程能回答前兩個問題。第三個問題，則是客戶、稽核人員與主管機關接下來會問的，也是事後最難回答的。

步驟 1：找出元件是否存在

企業通常以下列四種方式之一得到答案，大致依成熟度排序。

**四處詢問與搜尋。**有人在 Slack 上發文，工程師在自己的儲存庫與 lockfile 中搜尋套件名稱，再用一份試算表彙整回覆。這仍是最常見的方法。它很慢，取決於誰回覆，而且會漏掉任何未在檔案中宣告的內容：相依套件的相依套件、內嵌的函式庫、基礎映像檔，以及建置期間安裝的工具。

**查看掃描工具的儀表板。**相依套件掃描工具會在數小時內依儲存庫標示出該 CVE。這比較快，但掃描工具回報的是它眼前今天的程式碼，通常是預設分支。它無法告訴您客戶正在執行哪些版本，也無法告訴您三個月前的一次建置實際拉進了什麼。

**查詢 SBOM 資產清冊。**為每個版本保留軟體物料清單的團隊，可以對所有版本提出同一個問題：哪些產品與版本包含此套件的受影響版本？這是第一個能針對您已交付的軟體、而不只是儲存庫中的軟體給出答案的方法。

**持續比對。**當 SBOM 持續與漏洞資料比對時，受影響產品的清單在有人提問之前就已經存在。聊天群組的討論從答案開始，而不是從問題開始。

每種方法的品質，都取決於資產清冊實際包含了什麼。常見的盲點有：

  • **遞移相依套件。**有漏洞的套件很少是您自己加入的，它通常來自往下三、四層。
  • **任何資訊清單未宣告的內容。**由建置腳本安裝的套件、npx 工具、Dockerfile 步驟、還原的快取，以及內嵌的 C 與 C++ 程式碼。
  • **舊版本。**已無法再建置的分支無法重新掃描，但由它建置的產品可能仍在市場上使用。

步驟 2：判斷是否重要

元件可能存在，卻不構成真正的風險，因此下一步是分級研判：

  • **版本與設定。**版本是否確實落在受影響範圍內？有漏洞的功能是否被編譯進去並啟用？
  • **可達性。**您的程式碼究竟有沒有呼叫有漏洞的函式？
  • **曝險程度。**該元件是否能從網路或不受信任的輸入觸及，還是只在建置時使用？
  • **緩解措施。**是否有沙箱、網路限制或能阻擋攻擊的設定？
  • **遭利用的訊號。**CVSS 提供嚴重程度，EPSS 估計某個 CVE 在未來 30 天內遭利用的機率，而 CISA 的 Known Exploited Vulnerabilities catalog 列出已在實際環境中遭利用的漏洞。三者合起來決定先處理哪些。

步驟 3：記錄判定

結果會依產品與版本記錄下來，而且越來越常以 VEX（Vulnerability Exploitability eXchange）聲明的形式記錄。CISA 的 VEX 最低要求定義了四種狀態：not affected、affected、fixed 與 under investigation。「not affected」聲明必須說明原因，例如有漏洞的程式碼不存在，或攻擊者無法觸及。

這份紀錄是後續所有工作的基礎：修正與包含修正的版本、給客戶的資安公告，以及主管機關要求的任何報告。例如根據歐盟 Cyber Resilience Act（CRA），製造商在得知其產品中有遭積極利用的漏洞後，必須在 24 小時內發出早期預警。

步驟 4：找出曝險期間

「我們受影響了嗎？」還有經常被略過的後半段：我們受影響了多久？

漏洞早在 CVE 公布之前就已存在。Log4Shell 自 2.0-beta9 起就在 Log4j 中，而該版本在任何人揭露漏洞之前好幾年就已發布。您的曝險始於某次建置第一次拉進有漏洞版本的那一天，終於最後一個包含它的建置被取代的那一天。您需要這段期間，才能：

  • 告訴客戶他們執行的哪些版本受影響，而不只是最新版本
  • 若漏洞可能已遭利用，將事件調查的範圍限定在正確的期間
  • 向稽核人員或主管機關說明問題何時進入產品，以及修正何時交付

掃描今天的程式碼無法提供這些資訊。目前的 lockfile 說的是儲存庫現在想要什麼，而不是過去每次建置安裝了什麼。唯一可靠的來源，是在每次建置執行時取得、並於事後保存的紀錄。

CRACI 如何回答

CRACI 在自有的執行器上執行您的 GitHub Actions 作業，並記錄每次建置實際拉進的每個套件，包括直接與遞移相依套件，以及由腳本安裝和從快取還原的套件。每次建置的 SBOM 都會保存下來，因此在 CVE 公布時，歷史紀錄早已就緒。

當新的 CVE 出現時，答案已經在那裡：過去的每次建置及其 SBOM、其中哪些包含有漏洞的相依套件（無論直接或遞移），以及您受影響的期間。不需要試算表，不需要重新掃描，也不需要從 lockfile 重建。第一個包含它的建置與移除它的建置，就構成曝險期間，可回溯的範圍取決於您的保存期限（預設 180 天，Enterprise 方案可自訂保存期限）。

一旦掌握狀況，政策關卡可以封鎖包含此 CVE 的建置，讓之後的相依套件更新或還原的快取，無法悄悄地把有漏洞的版本帶回某個版本中。

在此基礎上，流程的其餘部分就有了依據：

  • CRACI 持續監控 SBOM，因此新的 CVE 會自動與您的建置比對，無須任何人提問。
  • 資安團隊分級研判發現結果，並交給負責修正的團隊處理，而 CRACI 支援以 VEX 記錄結果。
  • CRACI 的資產清冊會顯示哪些軟體版本部署在哪些產品上。
  • 針對 CRA，CRACI 會備妥早期預警、事件通報與最終報告的內容；再由貴公司的人員透過 Single Reporting Platform 提交。

一旦掌握狀況，請告知您的客戶：供應鏈攻擊後如何回覆客戶一文提供第一份聲明以及各種結果的範本。如果問題多達數百個，請參閱擴展 PSIRT。

預約示範，看看您自己某個儲存庫的建置歷史。