漏洞排序別只看分數，先查執行路徑與外部輸入

Larry

安全掃描一次送來幾百筆警示，最容易採取的做法，就是從最高分一路往下處理。問題是，分數高的弱點可能位於服務根本不會執行到的位置；分數普通的另一筆警示，卻可能就在公開入口後方，而且已經出現遭利用跡象。只按分數排隊，真正急迫的風險反而可能被壓在清單中間。

判斷時要把兩件事拆開。風險急迫度用來決定是否立刻升級、限制曝露或啟動調查；部署準備度則確認修補是否已有負責人、測試結果、驗證範圍與回復方法。修補尚未有人承接，不代表風險變低，只代表現在還不具備上線條件。

Tenable 在 2026 年 7 月發布更新，把應用程式安全資料連回執行環境與曝露情境。這類外部資料能補充背景與調查訊號，卻無法代替團隊確認自家服務的實際狀況。要把警示轉成可執行的決定，還得補上本地技術影響、資產重要性、補償控制，以及部署前不可省略的人工閘門。

先判斷急不急，不要先問能不能部署

一個弱點「可達」，是指服務的實際執行流程會進入受影響的函式、模組或執行檔；「有曝露」，則是外部使用者、低權限帳號或其他低信任來源，能把資料送進那條路徑。這兩項都是重要的本地證據，但還不足以單獨決定順序。技術影響有多大、資產是否關鍵、補償控制是否有效，以及外部是否已有遭利用訊號，都要一起考量。

證據尚未完整，不等於可以先擱著。漏洞已知正遭利用，或系統正在受攻擊時，團隊不應等待完整的可達性證明才升級。相反地，若要暫緩，也必須有可重現的本地證據，不能只憑工具沒有報出更多資訊。

證據狀態	下一步
已知遭利用或正受攻擊；或已確認可達、低信任輸入可抵達，且可能造成重大技術影響或涉及關鍵資產；或關鍵資產／遭利用訊號存在，而重大證據缺口本身需要人工升級	立即處置：立即通報，由人決定是否採取可逆隔離、停用入口或限縮權限，並指派修補、部署與驗證負責人。這項結果不代表部署已獲批准。
可達性、曝露、影響、資產重要性或補償控制仍有未知，而且尚未符合任何立即處置條件	限期查證：寫明查證方法、負責人與期限。AI 不得關閉警示或自動部署；出現新訊號時，人工可提高處理層級。
可重現證據支持相關位置不會執行、沒有低信任輸入路徑，或補償控制確實有效；同時沒有已知遭利用、主動攻擊或關鍵曝露	暫緩並監看：保存證據、有效期限與重審條件。入口、架構、權限、版本、控制措施或遭利用狀態一有變化，就重新判斷。

外部訊號適合拿來補強調查。KEV 是美國 CISA 維護的「已知遭利用漏洞目錄」；CSAF 是不同系統交換安全公告的標準格式；VEX 則用來記錄產品或元件是否受特定漏洞影響，以及做出該判斷的理由。CISA 的 SSVC 方法也提供依狀態做決策的背景。不過，證據卡採用的三種結果與本地閘門，仍要由團隊根據自己的系統證據執行。

每張證據卡只處理一個漏洞。工具說了什麼、執行追蹤顯示什麼、重現測試得到什麼結果，以及網路入口、權限邊界與人工查證各自支持哪些結論，都應分開保存。風險結果只能落在「立即處置」「限期查證」「暫緩並監看」其中一種；修補能不能交付審核，則另用部署準備度記錄。

可送人工審核（READY_FOR_HUMAN_REVIEW）：負責人、測試結果、驗證方法、變更範圍與回復方案都已備妥。這只表示可以交由人審核，不是部署核准。
不可上線（NOT_READY）：已知至少缺少一項必要的發布條件。
待確認（TO_CONFIRM）：資訊不足，還無法判定必要條件是否齊全。

兩條軸線分開後，就不會把「修補還不能上線」誤認成「風險可以晚點處理」。例如，某項警示已符合立即處置條件，卻還沒有驗證方法，證據卡應記成「立即處置／不可上線」。團隊先升級風險，視情況採取可逆控制；正式部署仍須等待人工驗證與核准。

GitHub Docs 對安全與品質 AI 功能的 responsible-use 說明，也提醒使用者理解工具限制並審查輸出。這項提醒支持保留人工權限，但不能拿來當成本地風險模型已獲證明。

若要先劃清人工與 AI 的責任，可讀AI 能整理漏洞，但修補能不能上線要由人決定。容器掃描雜訊太多時，則可搭配Docker 安全掃描警訊太多，如何判斷哪些真的會影響映像檔檢查實際執行路徑與外部輸入。

拿五筆警示跑一次實際流程

從同一個服務挑出五筆警示，不必只選最高分。樣本中刻意放入高分但疑似不可達的項目、分數普通卻位於公開入口的項目、已有遭利用訊號的項目，以及修補條件尚未備妥的項目。

服務負責人與安全人員先依證據選出風險結果，再查看負責人、測試結果、驗證方法、變更範圍與回復方案，另行判定部署準備度。完成後，把五張卡與原本按掃描分數排序的清單並排比較，觀察哪些項目的順序發生變化。

遇到無法判斷的警示，不要讓 AI 把同一批資料改寫成更長的摘要。真正需要補的是能改變結論的資料，並且要為查證留下方法、負責人與期限。五張卡跑完後，再統計最常缺少的證據，把補件要求接回服務交接、端點新增與架構變更流程。

AI 整理卡

先從你目前可存取的 repository、專案目錄、弱點掃描結果、CI 紀錄與工作環境著手，只進行唯讀探索，不要修改檔案、設定、工單或執行狀態。自行檢查可用的程式碼、相依套件清單、安全報告、失敗紀錄與版本資訊，找出一個最值得改善的具體漏洞處理問題；不要要求我先整理或貼上資料。

若完全無法存取專案或相關證據，只問一個最能解除阻礙的存取／情境問題，問完即停止。資訊不足的欄位一律寫「待確認」，不得猜測。

請把結果整理成一張可供人員決策的證據卡，內容包括：
- 問題：用一句話指出選中的單一漏洞處理問題或改善機會。
- 已觀察事實：逐項列出直接證據，附上檔案路徑與行號、報告名稱與項目、CI job／log 位置，或你實際執行的唯讀命令及關鍵輸出。
- 推論：說明證據可能代表什麼，並明確標示尚未驗證之處，不得把推論寫成事實。
- 影響範圍：列出可能受影響的元件、版本、環境與暴露條件；無法證實者標為「待確認」。
- 風險處置：只能選「立即處置」「限期查證」「暫緩並監看」其中一項，並用證據解釋理由。
- 部署準備度：只能標示 READY_FOR_HUMAN_REVIEW、NOT_READY 或 TO_CONFIRM，且此欄不得取代風險處置判定。
- 人工檢查點：指出仍須由人員核准或判斷的事項。升級通報、關閉警示、核准修復、合併、部署與發布都不得由你自行決定或執行。

最後一行只寫一個現在就能執行、範圍明確且不會越過上述人工權限的下一步行動。