資安指南

為自家技術堆疊自動化漏洞監控:以實際使用的元件名稱比對

建立只標記影響自身環境之漏洞的監控機制:由 lockfile 與作業系統套件產生 SBOM、以 KEV 與 EPSS 排定優先順序,並讓 AI 只能提高緊急程度

發布於 2026-11-01 更新於 2026-11-01 最後核實 2026-11-01 閱讀時間 3 分鐘
本頁內容

適用對象:自行經營網站或服務,並希望在不必有人盯著資訊來源的情況下取得漏洞資訊的讀者。本文說明要蒐集什麼、以什麼進行比對,以及對 AI 可以信任到什麼程度。

發生了什麼:連續三次都是人先知道

在同一週內,本站營運者經營的網站上發生了三件事。每一次,營運者都是先透過社群媒體或電子郵件得知,而當時自動化監控尚未回報任何內容。

  1. 案例 1

    一則 PHP 漏洞。營運者先得知,自動化監控尚未標記。
  2. 案例 2

    Python 套件中被插入惡意程式碼。營運者先得知,自動化監控尚未標記。
  3. 案例 3

    容器基礎映像檔問題。營運者先得知,自動化監控尚未標記。

最初的推測是「來源不夠多」。但原因不只一個:官方來源可能落後於熱門話題(詳見下文),而且也缺乏足夠的資料來判斷某項目是否與我們的環境相關。「PHP」或「Python」等字詞會出現在新聞內文中,但這與您實際執行的套件名稱是兩回事。

重建後的監控機制

1. 蒐集

官方公告 / GitHub 公告 / 惡意套件清單 / KEV / 新聞 / 社群媒體

↓

清單 A:我們使用的技術關鍵字

廣泛撒網

清單 B:實際的元件名稱

由 lockfile 與作業系統套件產生

↓

2. 規則擷取符合項目(無需 AI 即可運作)

↓

3. 低成本 AI 模型進行初步分流

它可以提高緊急程度,但不能降低。

蒐集、以兩份清單比對、以規則擷取,再由只能提高緊急程度的 AI 處理。在 AI 無法使用的日子,規則路徑仍持續運作。
  • 蒐集的內容:官方公告、GitHub 公告、惡意套件清單、CISA 的 KEV、新聞與社群媒體。
  • 用於比對的兩份清單:技術關鍵字用於廣泛撒網,實際元件名稱用於高可信度的比對。元件清單由每個儲存庫的 lockfile 與作業系統套件建立。
  • 整體映像檔掃描:檢查整個映像檔(包含基礎映像檔),而不只是應用程式相依套件。
  • 執行環境落後程度:衡量 Node、PHP 與資料庫等執行環境與最新版本相差多少。
  • AI 初步分流:由低成本 AI 模型先判斷「這是否影響我們?」。AI 只能提高緊急程度。

測量結果,包括與預期相反的部分

最初的假設:官方來源就足夠

我們原以為,監看官方公告與 KEV 就能掌握重要事項。實際上,某個話題可能在公告發布之前就已開始延燒。僅靠官方來源,會輸掉這場時間差。

測量後:加入社群媒體作為入口

加入社群媒體後,監控能比僅靠官方來源更早察覺事態。但社群媒體內容在官方來源確認之前,不會被視為事實。入口要廣,判斷要謹慎。

約 100 則
由另一個用於尋找文章題材的監控,在 10 天內蒐集到的重大漏洞
0 則
其中影響營運者網站、卻被本監控漏掉的漏洞
約 6 天
AI 配額用完後,AI 分流暫停的時間(規則比對持續運作)
  1. 漏報檢查:由另一個用於尋找文章題材的監控,在 10 天內蒐集到約 100 則重大漏洞,並與本監控進行交叉比對。其中影響營運者網站的漏洞,漏報數為 0。
  2. AI 配額用盡:每月配額用完,AI 分流暫停約 6 天。不使用 AI 的規則比對全程持續運作。設計上會事先設定暫停結束日期,AI 部分會從該日期自動恢復。
  3. 新伺服器的缺口:新加入的伺服器,其作業系統套件未出現在元件清單中。每月重建清單時才發現。清單只有定期重新產生才可信,只建立一次並不足夠。

如何在您自己的環境中建立

1

機械式地產生元件清單(SBOM)

同時從每個儲存庫的 lockfile,以及伺服器與容器中的作業系統套件來建立。CISA 將 SBOM 描述為一份巢狀的清單,列出組成軟體元件的各項成分。SBOM 產生工具(例如開源工具 Syft)可從容器映像檔與檔案系統讀取作業系統套件及主要語言的相依套件,並可輸出 CycloneDX 或 SPDX 格式。

2

將清單與已知漏洞進行比對

對於相依套件的比對,開源工具 osv-scanner 可讀取 lockfile 與容器。安裝與 CI 整合方式請見osv-scanner:安裝與使用。

3

以 KEV 與 EPSS 排定優先順序

當發現的問題很多時,無法每一項都以同樣的緊急程度處理。應先看已確認遭利用的項目(KEV),以及預測遭利用機率較高的項目(EPSS)。如何結合兩者,請見CVSS、EPSS 與 KEV:如何併用。

4

若使用 AI,僅用於提高緊急程度

即使 AI 表示「不受影響」,也不要移除已被規則擷取的項目。AI 可能錯誤地判定為「無關」,而漏報的代價大於誤報的代價。

5

事先決定 AI 無法使用時的做法

配額會用完,服務會故障,供應商也可能停止服務。在營運前就應決定:單靠非 AI 規則仍能發出最低限度的通知,並設定恢復日期,讓 AI 部分自動回復。

6

定期重新產生清單

當伺服器或儲存庫已新增,但清單未更新時,就會產生缺口。請至少每月重建一次,並確認新增的項目已列入清單。

在官方來源確認之前,不要將社群媒體內容視為事實

社群媒體傳播速度快,但其中混雜了廠商尚未確認的錯誤與臆測。可將其作為入口,但應以廠商公告或 KEV 等可查證的第一手來源作為回應的依據。

本站觀點:技術關鍵字廣泛撒網,以元件名稱收斂

根據營運者的經驗,改為以實際元件名稱比對後,雜訊誤報與漏報都減少了。但若元件清單過時,會直接導致漏報。兩者都需要:廣泛撒網,以及用來收斂的準確清單。本文說明的是本站營運者所經營網站所建置的監控機制。

資料來源(第一手與官方)

延伸閱讀

FAQ

Q自動化漏洞監控應該從哪些來源蒐集資料?
A

可以從官方廠商公告、CISA 的 KEV 目錄、套件生態系的安全公告資料庫,以及惡意套件清單開始。不過,官方來源可能落後於熱門話題的進展。本站營運者所建置的監控機制,曾在話題開始延燒與官方公告發布之間落後,因此另外加入社群媒體作為輔助入口。來自社群媒體的內容,在官方來源確認之前,不會被視為事實。

Q如何建立自己使用的元件清單(SBOM)?
A

可以同時從每個儲存庫的 lockfile(例如 package-lock.json、pnpm-lock.yaml 等),以及伺服器與容器中的作業系統套件來建立。若只看應用程式相依套件,會漏掉作業系統與基礎映像檔的部分。SBOM 產生工具(例如開源工具 Syft)可從容器映像檔與檔案系統讀取作業系統套件及主要語言的相依套件,並可輸出 CycloneDX 或 SPDX 格式。

Q讓 AI 判斷某項目是否影響我們,安全嗎?
A

只要限制 AI 的判斷方向,就是安全的。在本站營運者的設定中,AI 只能提高緊急程度,無法降低已被規則擷取之項目的層級。AI 可能錯誤地判定為「不受影響」,而漏報的代價大於誤報的代價。

QAI 配額用盡的日子,監控機制會怎麼運作?
A

監控應該持續運作。在本站營運者的監控中,每月的 AI 配額用完後,AI 分流暫停了約 6 天,而不使用 AI 的規則比對則全程持續運作。若事先設定恢復日期,AI 部分會在該日期自動恢復。