漏洞管理流程圖（由掃描到已驗證結案）

甚麼是漏洞管理流程圖（由掃描到已驗證結案）流程

漏洞管理是在整個資產範圍內發現已知弱點、判斷哪些真正重要、推動它們獲得修復並加以證明的常態化營運循環。它的觸發是一份時間表，而不是一件事件：掃描時段針對資產登記冊開啟，下游的一切都取決於這份登記冊是否準確。下面這張圖跟隨一個完整週期，由頭走到尾：先議定掃描範圍與憑證覆蓋率，再執行已認證掃描；供應商公告與掃描器本身的輸出並行到達；發現經去重並確認；評分把嚴重程度、可利用性與資產上實際存放的內容結合起來；到期日與具名負責人隨之附上；一次變更承載修復；重新掃描要麼把這項發現結案，要麼令它重新開啟；登記冊與各項指標，就是管理層在下一個時段開啟之前要審閱的內容。

這張圖畫的是這套體系，不是修復本身。一位系統負責人在單一工單裡所做的事——對照自己的環境驗證發現，在修補程式、升級、設定變更與停用之間作出選擇，測試並部署——屬於漏洞修復流程，它掛在圖中唯一畫出的那一步「套用修補程式、設定變更或補償控制」上。供應商的修補程式本身，連同其適用性評估、非生產環境測試、分批部署與回退，屬於修補程式管理，是這套流程消費而非涵蓋的另一個獨立週期。而完整的保安豁免流程——業務理由、補償控制、隨風險評分而變化的審批層級、登記冊條目與續期覆核——位於「豁免是否已附到期日獲批？」這個決策之後，而不是在它之內。讓這些界線保持可見，正是防止一張圖試圖同時充當三張圖的方法。請把接下來的內容當作起點，按你們自己的保安政策、監管責任，以及一位稱職保安從業員的判斷去調整它。

四個判斷撐起這套流程。「範圍內每項資產是否都可掃描？」排在最前，因為覆蓋缺口是不可見的：沒有掃描範本能觸及的資產不會產生任何發現，一塊乾淨的監控面板和一批未被掃描的資產，在報告上看起來一模一樣。「是已知遭利用，還是嚴重程度屬『嚴重』？」是優先次序的分岔點，它放在分析師的泳道裡，因為利用證據由分析師掌握，而它開啟的緊急通道則屬於保安管理層，只有他們才有權中斷其他工作。「能否在SLA內完成修復？」被刻意放在系統負責人 / IT 營運的泳道，而不是分析師的泳道——必須作出變更的人，才知道這個時間窗是否真的存在——它的否定分支通向由保安管理層擁有的豁免決策，因為接受風險是一種管理行為，而不是工程行為。「重新掃描是否顯示發現已結案？」把流程交回分析師手上，令結案建基於證據之上，而不是建基於有人把工單標示為完成之上。

本流程圖涵蓋的內容

本範本包含

• 五條泳道——漏洞分析師、系統負責人 / IT 營運、變更經理、保安管理層與供應商——橫跨六個階段：範圍與發現、掃描與接收、分流、優先次序與指派、修復與驗證，以及報告與覆核
• 任何掃描之前的一道覆蓋閘門：「範圍內每項資產是否都可掃描？」把缺失的憑證和未部署的代理程式送返去修正，因為一項掃描器無法與之完成認證的資產，幾乎報不出任何東西，卻依然被計為已掃描
• 匯入同一隊列的兩條接收路徑：掃描器本身的輸出，以及在「發布公告與已修補版本」這一步到達的供應商公告，令兩次掃描時段之間公開披露的內容不會一直無人認領，拖到下一個週期
• 大多數流程圖會壓縮成一個方框的分流一對：「發現是否已在資產上確認？」把未經確認的結果導向「以誤報結案，並附證據」，這是一個封閉的終點，卻依然要求理由、失效日期與審批人
• 評分與到期日作為兩個分開的動作：「按CVSS、可利用性與資產價值評分」產出評分，「是已知遭利用，還是嚴重程度屬『嚴重』？」把緊急工作與常規分級區分開來，直到那之後才指定並問責一位修復負責人
• 以證據為本的結案，帶兩個循環與一條出口：「重新掃描是否顯示發現已結案？」會把仍然存在的一切重新開啟，「能否在SLA內完成修復？」通向「豁免是否已附到期日獲批？」，逾期的發現會在指標發布之前被升級

何時使用本範本

• 你們正在草擬或重寫一套漏洞管理標準，需要一張圖看清誰掃描、誰評分、誰修復、誰接受剩餘風險
• 發現的賬齡不斷超過到期日，卻沒有人能說清它們卡在分流、指派、變更窗口，還是重新掃描這一環
• 你們正在選型或更換掃描器，希望在設定掃描政策、憑證儲存、資產分組與SLA分級之前先議定這套流程
• 保安團隊和IT營運在甚麼才算「已修復」上意見不一，因此重新掃描、豁免路徑與升級路徑都需要寫明並落實到具體負責人
• 審核員或客戶的保安問卷要求提供一份成文說明，講清漏洞如何被識別、評分、修復與驗證

運作方式

1. 把泳道改成你們的角色

   用你們機構中真正存在的角色，替換漏洞分析師、系統負責人 / IT 營運、變更經理、保安管理層與供應商。在小型團隊裡，分析師和系統負責人往往是同一個人：把這兩條泳道合併，而不要畫一次只存在於紙面上的交接。即使如此，也要讓保安管理層保持獨立，因為豁免與升級分支需要一個不同時兼任修復人的權威。

2. 寫下你們的掃描範圍與覆蓋規則

   寫明哪些資產在範圍內、它們如何由登記冊或CMDB進入範圍、哪些用憑證或代理程式掃描、哪些不用，以及每個分組多久掃描一次。記下例外情況以及誰有權批准。覆蓋率是令項目裡其他一切數字都有意義的那個數字，所以把它畫在圖上，而不是留在沒有人會去看的工具設定裡。

3. 定義發現如何評分

   寫明你們使用的嚴重程度量表以及分數的來源，然後寫明你們在它之上再加甚麼。嚴重程度分數描述的是技術影響；可利用性證據與資產背景描述的，是這星期你們究竟應該有多擔心。把你們實際使用的組合寫下來，為每個輸入命名，並記錄誰有權推翻某個評分，以及這個推翻依據甚麼證據。

4. 設定SLA分級並啟動計時

   把你們自己的修復到期日畫在圖上，刪去佔位符。與必須遵守每個分級的人商定它，並清楚說明計時由何時開始，因為發現日期、工單日期與供應商發布日期，會對同一批資產得出截然不同的賬齡報告。寫明緊急通道在實務上意味着甚麼，以及誰有權開啟它。

5. 議定豁免與升級路徑

   決定誰有權批准一項豁免、需要附帶甚麼證據、它最長可以存續多久，以及在它存續期間必須運行甚麼補償控制。然後議定沒有豁免卻已逾期的一切該如何升級：通知誰、在甚麼賬齡觸發、之後仍無變化會如何。兩條路徑都需要一位具名的人，而不是一個共用郵箱。

6. 確定甚麼能證明一項發現已經結案

   結案應該建基於對受影響資產的重新掃描，而不是建基於工單被標示為完成。寫明哪次掃描能證明這一點、它在修復後多快執行，以及當重新掃描仍然報告這項發現時會發生甚麼。記錄一項補償控制究竟是令發現結案，還是只是降低它，因為這兩種約定會產生截然不同的登記冊和指標。

7. 用一項真實發現走一遍流程

   取上一週期的兩項發現——一項按時結案，另一項逾期或最終成為豁免——沿着圖把兩者都走一遍。人們描述過、卻沒有畫出來的每一步，以及畫出來了、卻在實務上被靜悄悄跳過的每一步，都是你們在把這套流程發布給其他人之前，值得處理的發現。

常見問題

漏洞管理流程包含哪些步驟？

掃描週期針對資產登記冊開啟，範圍與憑證覆蓋率在任何掃描運行之前就已確定；掃描器觸及不到的資產會被修正並重新檢查。已排程的已認證掃描隨之執行，兩次掃描之間到達的供應商公告會匯入同一隊列。發現先去重並補充可利用性資料，再對照資產確認，未獲確認的一律連同證據以誤報結案。已確認的發現按嚴重程度、可利用性與資產價值評分，被導向緊急通道或標準到期日分級，並指定給一位具名的修復負責人。這位負責人要麼在到期日之前完成修復（必要時透過變更窗口），要麼申請一項附到期日的豁免。重新掃描確認結案，或令工作重新開啟。最後，登記冊獲更新，逾期的發現被升級，覆蓋率、賬齡與結案率指標獲發布，管理層在下一個週期開始前覆核這個趨勢。

漏洞管理與修補程式管理有甚麼分別？

漏洞管理是在整個資產範圍內發現弱點、為它們評分，並把它們推向經過驗證的結案的那個循環——無論最終採用哪種處理方式。修補程式管理是這些處理方式之一：一個把供應商發行的版本拿來評估是否適用、測試、排程並部署的營運循環。NIST 關於企業修補程式管理規劃的指引（SP 800-40 第4版）由另一個角度說明同一件事：它把套用修補程式定位為預防性保養，視其為應對軟件漏洞所帶來風險的多種方式之一。這帶來的實務後果是，一個只用已安裝修補程式數量來衡量的漏洞項目，會低估自己的成效，因為設定變更、升級、停用與補償控制同樣能令發現結案，而且有些發現根本沒有修補程式可裝。

CVSS評分足以決定修復優先次序嗎？

CVSS由FIRST維護，把技術嚴重程度評為0.0至10.0分，其3.1版的定性分級是：低 0.1至3.9、中 4.0至6.9、高 7.0至8.9、嚴重 9.0至10.0。2023年發布的4.0版保留了基礎評分，並新增明確的威脅與環境兩組指標。CVSS刻意不會告訴你的是：這個漏洞被利用的可能性有多大，或者某項具體資產對你究竟有多重要。團隊通常會再加兩個訊號：一是像EPSS這樣的利用概率評分，同樣由FIRST提供，估算某個漏洞在未來三十日內在現實世界被利用的概率，並且每日重新計算；二是實際被利用的證據，例如CISA的已知遭利用漏洞（KEV）目錄。資產背景是第三個輸入，也是只有你自己才掌握的一個。這正是本圖先評分、再依據「是已知遭利用，還是嚴重程度屬『嚴重』？」來分流，而不是單純按分數為名單排序的原因。

漏洞掃描應該多久執行一次，這個流程該由誰負責？

各框架的要求並不一致，所以請以適用於你們的那一個來定頻率，而不是套用某條通用規則。ISO/IEC 27001:2022附錄A的8.8控制項，即技術漏洞管理，要求取得所用系統中技術漏洞的相關資訊、評估暴露程度並採取適當措施，但沒有訂明具體間距，把節奏留給你們自己的風險評估。PCI DSS第4版對持卡人資料環境的規定更為明確：內部漏洞掃描最少每三個月一次，並在任何重大變更之後再次進行，均以已認證掃描方式執行，外部掃描則由一家經批准的掃描服務商（Approved Scanning Vendor）完成。許多機構的掃描頻率遠高於這個最低要求，因為多掃一次的成本很低。至於歸屬，通常的劃分正是本圖所畫的那樣：保安團隊負責發現、評分與報告；系統負責人負責修復；管理層負責豁免與升級。一個連修復也由保安團隊負責的項目往往會陷於停滯，因為分析師既沒有變更權限，亦不承擔營運風險。

漏洞管理流程應當產出哪些紀錄？

要多到足以在一年之後、不打開掃描器的情況下重建任何一項發現。實務上這意味着每項發現在登記冊中都有一條紀錄，載明受影響的資產、發現日期、評分及其依據、指定的負責人、到期日、選擇的處理方式與結案證據。與之並列的還有掃描設定與覆蓋率證據，讓審閱者能看清哪些在範圍內、哪些經過了認證；結案清單，為每一項誤報記錄理由與覆核日期；豁免登記冊，載明理由、補償控制、審批人與到期日；以及令每一項發現結案的那次重新掃描的輸出結果。報告是最後一類紀錄：覆蓋率、相對到期日分級的賬齡，以及結案率隨時間的變化，連同趨勢變化時管理層作出的決定。審閱者通常會拿登記冊去對照掃描器，而不是反過來，所以工具裡存在、登記冊裡卻沒有的、說不清來由的發現，才是最常見的問題。