漏洞
如何降低漏洞管理中的雜訊
雜訊是指佔用注意力、卻不會改變您該做什麼的發現結果。請從源頭依序削減：準確的資產清冊、去除重複、縮小相依套件的範圍、可利用性情境，以及依政策指派負責人。然後再為剩下的項目排序。順序很重要，因為每一步都會讓下一步更省力，而優先排序工具只是為雜訊排序，並不會移除雜訊。
更新日期
漏洞雜訊從何而來
拿一份待處理清單，依每項發現結果的來源分類。以下數字僅為示意，並非基準值， 但這些類別正是團隊抽樣檢視自己的待處理清單時會發現的類別。
| 發現結果的來源 | 1,000 項發現結果中（示意） | 可移除它的步驟 |
|---|---|---|
| 您並未交付的元件：lockfile 與資訊清單項目、建置器層、開發與測試工具 | 300 | 1. 讓資產清冊正確 |
| 同一個 CVE 被多個工具回報，或每個儲存庫各回報一次 | 250 | 2. 每項發現結果只計算一次 |
| 錯誤比對：CPE 名稱衝突、發行版的向後移植修補 | 80 | 1. 讓資產清冊正確 |
| 在您的產品中無法被利用的真實發現結果 | 150 | 4. 補上可利用性情境 |
| 尚無修正的真實發現結果 | 70 | 5. 附有效期限的政策決定 |
| 沒有負責人的發現結果 | 50 | 5. 指派給負責人 |
| 剩下需要排序與修正的項目 | 100 | 優先排序 |
有一項區分能讓本頁其餘內容更容易理解。其中有些發現結果是誤報：發現結果本身是錯的， 因為元件並不存在，或該版本並未受影響。另一些則是雜訊：發現結果是對的，但不會改變您這週要做的事。 兩者需要不同的處理方式，若混為一談，團隊最後就會壓下真實的發現結果，或為錯誤的發現結果爭論不休。
| 誤報：發現結果是錯的 | 雜訊：正確，但不緊急 |
|---|---|
| 該元件不在您交付的內容中 | 易受攻擊的程式碼在您的產品中無法被觸及或觸發 |
| 比對錯誤：CPE 衝突，或版本號碼掩蓋了向後移植的修正 | 尚無修正，或產品僅供內部使用、未對外暴露 |
| 透過修正資產清冊與比對方式來解決 | 透過情境、記錄在案的決定與負責人來解決 |
步驟 1：讓資產清冊與您交付的內容一致
這是影響最大的單一槓桿，因為之後的每一步都會放大資產清冊的錯誤。一個被列出卻從未交付的元件， 會在每個掃描器、每個儲存庫與每個版本中都產生一項發現結果。
- 從建置中記錄。依據版本發布建置實際使用的內容建立資產清冊，而不是依據資訊清單或對完成建置產物的掃描。 建置時 SBOM 包含作業實際擷取的內容，包括任何 lockfile 都未列出的項目。
-
以 PURL 識別元件。Package URL 例如
pkg:npm/[email protected]， 能精確指出生態系、套件與版本。比對以 PURL 為鍵的資安公告（例如 OSV 中的各生態系資安公告）， 可以消除從產品名稱猜測 CPE 所造成的錯誤比對。 - 對作業系統套件使用能辨識發行版的比對方式。Debian 等發行版會將資安修正向後移植到其已發布的版本，而非升級版本， 因此版本號碼看起來可能比上游的修正版本更舊。請依據發行版本身的資安追蹤系統比對，而不是上游的版本範圍。
- 追蹤完整性。要知道資產清冊何時有看不到的部分，而不是假設它是完整的。缺漏的元件比帶來雜訊的元件更糟： 它根本不會產生任何發現結果。
實例說明。某個 Node.js 服務的 lockfile 包含 [email protected]，這是測試與建置工具所依賴的
glob 比對程式庫。lockfile 掃描回報了 CVE-2024-4067，這是一個已於 4.0.8 修正的正規表示式阻斷服務漏洞。版本發布作業以
npm ci --omit=dev 只安裝正式環境的相依套件，因此 micromatch 從未進入實際交付的建置。該建置的紀錄中
不包含它，這項發現結果也就不會進入待處理清單。這個 CVE 是真實存在的；但對這項產品而言，這項發現結果是誤報。
步驟 2：每項發現結果只計算一次
同一個 CVE 會從 SCA 工具、容器掃描器與 SBOM 平台各來一次，使用該程式庫的每個儲存庫又再各來一次。
請以單一鍵值去除重複：Package URL、版本與 CVE。例如，
pkg:npm/[email protected] 搭配 CVE-2024-45296 就是一項發現結果，無論有多少工具回報。
- 以每個交付的建置產物計算一項發現結果，而不是每個掃描器各算一項。
- 跨建置與儲存庫彙整，讓共用程式庫的 CVE 成為套用到所有地方的單一決定，而不是四十張工單。
- 整併功能重疊的掃描器。一個簡單的原則：相依套件的發現結果來自單一 SCA 或 SBOM 來源，映像檔的發現結果來自單一容器掃描器， 您自己程式碼中的發現結果來自單一 SAST 工具。如果兩個工具回報相同的訊號，請保留較接近實際交付內容的那一個（SAST 與 SCA 比較）。
步驟 3：交付更少的內容
每一個您不交付的相依套件，都是一個您永遠不必處理的發現結果來源。
- 移除未使用的相依套件。大多數專案都帶著幾個已經沒有任何地方匯入的套件。
-
升級引入易受攻擊套件的那個套件。Express 4.19.2 固定使用
[email protected]與[email protected]，它們分別帶有 CVE-2024-45590 與 CVE-2024-45296。若不使用覆寫設定，您無法單獨更新它們。Express 4.20.0 於 2024 年 9 月發布， 依賴的是已修正的版本，因此一次升級就能同時解決兩者 （遞移相依套件）。 - 使用精簡的基礎映像檔。Slim 與 distroless 映像檔包含較少的作業系統套件，適用的資安公告也就較少。 容器掃描介紹了映像檔專屬的槓桿。
- 有計畫地固定版本與更新。lockfile 與摘要值（digest）能讓資產清冊在各次建置之間保持穩定。
- 封鎖含有已知易受攻擊版本的建置。能中止建置的政策關卡， 可以在易受攻擊的程式庫變成需要有人分級研判的發現結果之前，就將它擋在門外。
example-service
└─ [email protected] → upgrade to 4.20.0
├─ [email protected] CVE-2024-45590
└─ [email protected] CVE-2024-45296步驟 4：補上可利用性情境
經過步驟 1 到 3 後剩下的都是真實的發現結果。情境決定其中哪些是緊急的。
- VEX。將「未受影響」連同理由，以 VEX 聲明記錄一次， 並在各版本與各客戶之間重複使用。當客戶轉寄他們自己對您產品的掃描結果時，同一批紀錄就能回覆他們：請參閱擴展 PSIRT， 以及供應鏈攻擊後如何回覆客戶 中的回覆範本。
- 可達性：若您的工具有提供，可顯示您的程式碼是否會呼叫易受攻擊的函式。 它有幫助，但有其限度（可達性分析）。
- 遭利用的訊號。CISA KEV 表示某個漏洞已在實際環境中遭到利用； EPSS 則估算未來 30 天內遭利用的可能性。
- 暴露程度。面向網際網路的產品，優先順序高於私有網路上的內部工具。
步驟 5：依政策將發現結果指派給負責人
- 將門檻寫成政策。以政策為每個產品或儲存庫設定嚴重性與可利用性門檻， 而不是某個人在儀表板上套用的篩選條件。
- 指派負責人：依儲存庫或團隊指派，讓每項發現結果都有人負責做決定。
- 明確決定如何處理「尚無修正」：附有效期限地接受風險、加以緩解，或替換該元件。 沒有修正的發現結果，不應在沒有任何決定的情況下一直處於未結狀態。
開發人員忽略發現結果有四個原因：沒有負責人、沒有情境、沒有期限，或傳遞管道錯誤。與我們交流的團隊 描述過工程部門因為輸出雜訊太多、難以閱讀，乾脆把掃描器關掉的情況。請逐一解決這些原因：每個儲存庫都有負責人、 附上步驟 4 的情境、依政策訂定到期日，並在團隊既有的工作場域中傳遞。
降低雜訊與隱藏風險的差別
待處理清單變短，只有在基於正確理由縮短時才是好事。
- 沒有理由與有效期限的壓制，就是隱藏的債務。它會在稽核或資安事件中再度浮現， 而屆時已經沒有人記得當初為什麼這麼做。
- 嚴重性下限只是隱藏錯誤的發現結果，而不是移除它們。「CVSS 7 以下一律不看」會讓 CVSS 6 的誤報消失， 卻讓 CVSS 9 的誤報留在原地。
- 每一項不修正的決定都需要留下紀錄。客戶會要求查看，法規也一樣，例如 歐盟 Cyber Resilience Act（CRA）就要求製造商在產品的支援期間內處理漏洞。
如何衡量成效
- 每個交付版本的發現結果數，而非每次掃描的數量。
- 已採取行動的發現結果比例：已修正、已緩解或已做出決定。
- 附 VEX 紀錄、以「未受影響」結案的數量，對照未附紀錄而遭壓制的數量。
- 從建置到指派負責人的時間：新的發現結果要等多久才有人負責。
- 各工具之間的重複率。
一個下午就能完成的 50 項發現結果抽樣。隨機挑選 50 項未結的發現結果。針對每一項，記錄 該元件是否隨版本交付、是否有其他工具或儲存庫回報相同的發現結果、比對是否正確、在您的產品中是否可被利用、 是否已有修正，以及由誰負責。這些統計數字會告訴您應該從哪一步著手。一季後再用同樣方式抽樣一次。 我們不引用這些數字的業界基準值，因為沒有任何第一手來源可以支持。
CRACI 的定位
對於在 GitHub Actions 中建置的軟體，CRACI 負責步驟 1 與 2、步驟 3 中的建置關卡，以及步驟 4 與 5 的部分內容。
- 資產清冊。CRACI 取代您的 GitHub 託管執行器，記錄每個作業實際拉進的套件， 每個元件都附有 PURL，每份 SBOM 都附有完整性狀態。CRACI SBOM 中的每個元件 都確實存在於建置中。這項準確性指的是 SBOM 的元件；比對到的 CVE 仍有可能並未影響您的產品。這正是 VEX 的用途，而 CRACI 支援 VEX。
- 一項發現結果，多次建置。發現結果會跨建置與儲存庫彙整，受監控的 SBOM 也會在新漏洞公布時持續重新評估。
- 關卡。政策關卡可依據發現結果即時中止建置，包括含有特定 CVE 的建置。
- 分級研判與指派。資安團隊在 CRACI 中對發現結果進行分級研判，並將每一項分派給負責修正的團隊。
- 通知。CRACI 會將漏洞及其嚴重性通知相關人員。
CRACI 不提供可達性分析、SAST 或 MTTR 儀表板。完整功能請參閱 漏洞追蹤，或 看看您的建置實際包含了什麼。
CRACI 不適用的情況
- 您的雜訊大多是自己程式碼中的 SAST 發現結果。這是 SAST 調校的問題。
- 您的待處理清單大多是已交付程式碼中真實且可被利用的發現結果。這是修補量能的問題，而不是雜訊的問題。
- 您需要來自正式環境工作負載的執行階段情境。這需要 CNAPP 或執行階段資安工具來解決。
更全面的規劃，請參閱CVE 數量持續攀升時應自動化哪些工作， 以及 CVE 發布趨勢的即時數據。
降低漏洞雜訊：常見問題
如何減少漏洞警示的數量？
從源頭依序削減：讓資產清冊與您交付的內容一致、依 Package URL、版本與 CVE 去除重複的發現結果、交付更少的相依套件、補上 VEX、KEV 與 EPSS 等可利用性情境，並依書面政策將剩下的項目指派給負責人。然後再進行優先排序。
為什麼我們的掃描器回報了數千個漏洞？哪些才重要？
通常是因為它回報了您並未交付的元件、同一個 CVE 在每個工具與儲存庫各回報一次，而且有些比對是猜錯的。重要的是那些位於您版本實際包含的元件中、在您的產品中可被利用，且已知或可能遭到利用的漏洞。
如何為多個資安工具的發現結果去除重複？
以 Package URL、版本與 CVE 作為每項發現結果的鍵值，並以每個交付的建置產物計算一項發現結果。跨儲存庫彙整，讓共用程式庫成為單一決定。接著將每一類訊號交給單一工具負責，讓兩個掃描器不再回報相同的內容。
我們應該壓制沒有修正的漏洞嗎？
不應悄悄壓制。請做出明確的決定：附書面理由與有效期限地接受風險、加以緩解，或替換該元件。待修正出現時再重新檢視。沒有理由與有效期限的壓制，就是隱藏的債務。
一年都沒人修正的漏洞，還算是雜訊嗎？
不一定。存在多久與風險高低無關。如果它隨產品交付且可被利用，就需要決定與負責人。如果它不影響您的產品，請以 VEX 聲明記錄下來，讓它不再反覆出現。無論哪種情況，它都不應在沒有任何決定的情況下一直處於未結狀態。
如何讓開發人員不再忽略資安發現結果？
為每項發現結果指派負責人、提供採取行動所需的情境、依書面政策訂定期限，並在團隊既有的工作場域中傳遞。先移除雜訊：如果一個管道中的大多數發現結果都無關緊要，開發人員就不會再看它。
未結漏洞的數量多少才算合理？
沒有可靠的基準值，而且原始數量本身就是錯誤的衡量指標。請追蹤每個交付版本的發現結果數、已採取行動的比例、附記錄理由結案的比例，以及已知遭利用的漏洞在已交付軟體中維持未結的時間。