網站弱點修復 SLA 怎麼訂？從 Critical 到 Low 的期限、例外與複驗指南

先講結論：用風險式多時鐘 SLA，不要只看嚴重度

網站弱點修復 SLA 應同時管理三個時間：第一個是從發現到完成技術判定的分流時間；第二個是從確認弱點到部署修復或完成核准處置的修復時間；第三個是從首次發現起持續累積的風險暴露時間。前兩者用來管理流程效率，第三個用來看組織實際承擔風險多久，不能因工單改狀態而歸零。

NIST SP 800-53 的 RA-5 要求組織分析弱點掃描結果，並依風險在組織自行定義的時限內修復真實弱點；SI-2 也指出更新期限可依系統安全類別、弱點嚴重度、組織容忍度、任務與威脅環境調整。這代表標準不替所有企業指定一組固定天數，而是要求企業把風險判斷、期限與驗證制度化。

最實用的做法，是先建立 P0 到 P3 的處置優先級，再把 Critical 到 Low 的技術嚴重度映射進去。若出現主動利用、CISA KEV、公開服務、認證繞過、遠端程式碼執行、敏感資料或關鍵營運影響，就升級處置；若有經驗證的隔離、功能關閉或其他補償性控制，則可以調整永久修復期限，但不能把弱點當成不存在。

• 分流 SLA：多久內確認資產、證據、重現條件與優先級
• 緩解 SLA：高風險事件多久內降低可利用性或中斷攻擊路徑
• 永久修復 SLA：多久內完成程式、設定、套件或架構修正並部署
• 複驗 SLA：部署後多久內依原始證據確認弱點已消失
• 例外期限：無法如期修復時，風險接受何時到期、何時提前重評
• 暴露年齡：弱點自首次確認後累積存在多久，無論狀態都保留

先分清楚 SLA、SLO 與內部修復目標

SLA 通常代表對客戶、供應商或組織治理層可被追責的服務承諾；SLO 是團隊為達成承諾設定的內部目標，通常應比 SLA 更嚴格，保留驗證、部署失敗與溝通緩衝。若公司只是剛建立流程，也可以先稱為弱點修復政策或內部目標，避免把尚未能量測與履行的數字直接寫進合約。

一套完整政策不只寫『幾天內修好』。它還要定義適用資產、發現來源、優先級算法、工作日或日曆日、時區、計時起點、允許暫停的條件、逾期升級、例外核准、第三方責任與複驗標準。沒有這些定義，同一筆弱點在安全、開發與供應商眼中會有不同截止日。

對外 SLA 也不宜直接承諾每個弱點都在相同時間永久修復。部分問題需要供應商補丁、重大架構變更或長時間回歸測試；更可執行的承諾是分別定義確認、緩解、修復計畫、永久修正與驗證的時間，並說明無法達成時的替代控制與通報義務。

為什麼不能只用 CVSS 或 Critical、High、Medium、Low？

CVSS 描述弱點的技術嚴重度，適合建立共同語言，但不直接知道你的資產是否公開、是否存放敏感資料、是否已有攻擊跡象、是否位於關鍵業務路徑，或控制失效會造成什麼損失。兩個 CVSS 相同的弱點，出現在公開管理介面與隔離測試環境，修復優先順序不應相同。

CISA 的 SSVC 以決策樹協助組織依利用狀態、技術影響、任務重要性與公共影響決定回應；KEV Catalog 則把已有實際利用證據的 CVE 單獨列出。這些方法共同提醒：可利用性與業務情境會改變處置速度，不能把分數排序當成完整風險管理。

反過來，資產重要也不能無限制放大每個低風險發現。政策應用一致的升降級條件，保存原始嚴重度與企業優先級，並說明調整依據。這樣才能避免所有人都宣稱自己的系統最重要，最後所有工單都變成緊急。

把六項風險輸入轉成可重複的優先級

優先級模型要簡單到分析人員能一致使用，又要足以反映企業風險。實務上可用六項輸入：外部暴露、利用證據、資產與資料重要度、攻擊所需權限與影響、補償性控制，以及修復與復原可行性。每一項都要有可查證資料來源，不能只靠會議中的印象。

外部暴露應確認網路路徑、DNS、CDN、VPN、Allowlist 與登入要求；利用證據可看 CISA KEV、供應商公告、內部 SOC 告警與實際嘗試；資產重要度則來自服務目錄、資料分類、營運依賴與復原目標。補償性控制必須實際測過其覆蓋與失效條件，不能只在工單寫『有 WAF』。

修復難度不應降低風險本身，但會影響處置策略。若永久修復需要數週，組織就應更快完成隔離、關閉功能、限制來源、更新規則或加強監控，並把剩餘風險交由適當層級核准，而不是把截止日無限往後移。

一份可調整的 P0–P3 修復 SLA 範例

下表是企業建立第一版政策時可用的示範基線，不是法律要求，也不是所有產業的通用答案。醫療、金融、關鍵基礎設施、個資處理平台與高可用服務，應依監管、契約、風險容忍度與變更能力調整。『工作日』與『日曆日』也必須在政策中明確定義。

P0 應保留給需要立即處置的情境，例如確認主動利用、公開關鍵服務的遠端程式碼執行或認證繞過、重要憑證外洩、控制失效且可能造成重大影響。單純被掃描器標為 Critical，不一定自動成為 P0；但也不能等完整根因分析後才開始隔離。

永久修復期限與複驗期限要分開。修復團隊部署完成後，安全或指定驗證者應在另一個短期限內重現原始條件、檢查同根因範圍與正常功能。只有複驗通過，狀態才是已關閉。

計時從哪裡開始？先定義狀態機，避免每個團隊各算各的

建議在掃描結果進入弱點管理系統時立刻啟動分流時鐘，不要等工單有人接手。完成技術確認、排除誤報並確定受影響範圍後，再啟動修復時鐘。若高風險訊號已足夠，例如已確認攻擊或 KEV 命中，不應等待完整分流才開始緩解；緊急處置時鐘應立即啟動。

狀態名稱必須對應客觀閘門。『修復中』表示已有負責人、計畫與目標版本；『已緩解』表示控制已部署並驗證有效；『已部署』表示修正已進入所有受影響環境；『待複驗』表示具備可重測條件；『已關閉』只在複驗通過後使用。單純把工單指派給團隊，不代表風險已降低。

若等待供應商、變更窗口或業務批准，流程時鐘是否暫停可以依政策設計，但風險暴露時間不可停止。更透明的做法是保留原截止日，將工單標記為例外或阻塞，另外計算逾期天數與剩餘風險，而不是把開始日重設。

哪些事件要立即縮短期限或升級為 P0？

優先級不是建立後就固定不變。當利用證據、資產暴露、控制狀態或業務情境改變，系統應自動或人工重新評估。CISA KEV 的價值就在於標示已有實際利用證據的漏洞；其 BOD 22-01 對美國聯邦文職行政部門具有約束力，要求依 Catalog 的 due date 修復。其他企業雖不受該指令直接約束，仍可把 KEV 當作縮短處置期限的重要升級訊號。

公開 PoC 不等於已被攻擊，但會降低攻擊門檻；內部 SOC 看見探測、Payload、異常帳號或資料存取，則可能從弱點管理轉為事件應變。此時重點不只是排程修補，而是保存證據、隔離、阻擋、搜尋受害跡象與通報。

若原本的補償性控制失效、資產從內網改成公開、資料敏感度提高、功能重新啟用，或相同根因出現在更多服務，優先級也要上調。相反地，只有在控制經過驗證且影響範圍明確時，才可以調整處置方式，並保留原始優先級與調整理由。

• CISA KEV 新增、供應商確認主動利用或可信威脅情報出現
• SOC 發現探測、利用 Payload、異常 Session、權限提升或資料存取跡象
• 公開利用程式碼成熟、攻擊門檻降低或可自動化大規模利用
• 資產改為公開、Allowlist 移除、登入要求降低或信任邊界改變
• 補償性控制未覆蓋所有 Host／API／節點，或監控與阻擋失效
• 弱點影響擴大到關鍵服務、管理權限、敏感資料或多租戶隔離

緊急緩解與永久修復要分開管理

P0 或 P1 弱點未必能在幾小時內完成根因修正，但通常可以先降低暴露：關閉受影響功能、限制來源、撤銷憑證、隔離節點、停用易受攻擊元件、套用供應商緩解措施、建立精準 WAF 規則或提高監控。這些動作的目標是縮短攻擊窗口，不是宣告缺陷已消失。

每個緩解措施都要記錄適用資產、部署時間、覆蓋範圍、驗證方式、監控、失效條件與撤銷計畫。若 WAF 只覆蓋主站但沒有 API 子網域，或規則可被編碼繞過，就不能把整個弱點標成已緩解。

永久修復應處理根因，例如改用參數化查詢、建立伺服器端授權、更新受影響套件、修正 Cookie 或安全 Header、移除不安全端點。緩解後仍要保留永久修復期限；只有正式風險例外能改變責任與期限，而且例外本身也必須到期。

把修復 SLA 變成可稽核的閉環流程

下圖把 SLA 從一個數字變成五個可驗證階段：確認真實弱點、指定能交付修復的人、在必要時先部署臨時緩解、完成永久修正與部署，最後由複驗確認結案。例外只能從責任階段分流到核准與到期管理，之後仍需回到永久修復，不能直接繞過複驗。

這個流程也說明為什麼工單系統、變更管理、部署平台與掃描平台需要共享識別碼。若修復提交、部署版本、緩解規則與複驗結果彼此斷裂，管理者只能看到『完成』，卻無法證明風險在哪個環境、何時真正消失。

無法如期修復時，啟動正式例外而不是修改數字

常見的 SLA 美化方式包括降低嚴重度、重開新工單、修改首次發現日、把等待供應商標成暫停，或在沒有複驗時直接關閉。這些做法只改善報表，沒有降低風險。逾期項目應保留原始優先級與截止日，進入可被治理層看見的風險例外流程。

例外必須限定資產、弱點、版本與期間，說明無法修復的原因、原始風險、補償性控制、控制後殘餘風險、永久修復計畫、責任人、核准者與到期日。核准層級應隨風險上升；高風險公開系統不應由修復團隊自行批准延期。

到期不是唯一重評條件。若出現主動利用、KEV、控制失效、資產公開、資料範圍擴大、供應商發布修補或重大版本變更，例外應提前失效。OWASP SAMM 也建議將超過 SLA 且無法修復的項目轉入風險管理，並使用補償性控制，而不是讓逾期工單停留在一般缺陷清單。

誰對 SLA 負責？安全團隊不能一個人扛完

安全團隊負責建立方法、驗證發現、協助排序與複驗，但通常沒有權限直接修改所有應用程式。資產擁有者要對風險與資源取捨負責，工程團隊負責交付修正，平台與維運負責安全部署與回滾，風險擁有者則核准超出期限的殘餘風險。

工單一旦確認，就應同時有 Accountable owner 與實際 Assignee。前者確保期限、資源與例外被處理，後者執行修復；只有 assignee 沒有風險擁有者，遇到跨團隊或需停機的問題就容易卡住。

P0 流程還需要事件指揮與高層通報。若有主動利用跡象，弱點工單不應取代事件紀錄；兩者應以共同 ID 關聯，讓隔離、調查、修補、復原與複驗能被完整追溯。

第三方、SaaS 與舊系統也要有自己的處置路徑

第三方產品的修補時間不完全受企業控制，但風險仍屬於使用該服務的組織。合約應定義安全通報、確認時限、緩解措施、修補目標、證據、重大事件升級與無法修復時的退出選項；內部 SLA 則要保留供應商聯絡、替代控制與業務決策的責任。

SaaS 供應商若只回覆『已轉交工程』，不能視為風險已緩解。企業要確認受影響租戶與功能、是否有攻擊跡象、可否停用功能、限制存取、撤銷 Token、匯出資料或切換服務。必要時依資料與服務重要度啟動供應商風險或事件流程。

舊系統可能沒有修補或無法停機，這時應建立分段隔離、虛擬修補、最小權限、功能下線、密集監控與替換路線圖。例外期限應與淘汰里程碑連結；若每次到期只是再次延長，表示問題已不是單一弱點，而是技術債與營運風險治理失效。

複驗才是結案：確認弱點消失，也確認修復已完整部署

修復完成不能以程式碼合併、供應商回覆、變更單結束或掃描器暫時沒有告警作為唯一證據。複驗要使用原始請求、角色、路徑與前置條件，確認缺陷無法再重現，並比對目前版本與部署批次。

複驗範圍要涵蓋相同根因的其他 URL、API 版本、租戶、角色、節點與環境。若只驗證最初一個位置，可能漏掉部分節點未部署、舊 API 仍存在或另一種角色仍可利用。對批次修補，應用資產清單證明覆蓋，再以風險抽樣或全面檢測驗證。

也要確認正常功能沒有被破壞。授權修復要測合法角色，輸入驗證要測正常資料，WAF 規則要看真實交易誤阻，元件更新則要確認相依性與回滾。NIST SP 800-40 把『驗證更新已安裝』納入企業修補管理流程，說明部署與驗證本來就是同一個閉環。

• 原始 PoC 或最小請求不再成立，且回應、日誌與控制行為符合預期
• 全部受影響環境、節點、版本、角色、租戶與 API 範圍已處理
• 部署版本、變更單、發布時間與資產識別可以互相對應
• 同根因位置已覆蓋，沒有只修畫面或單一端點
• 正常功能、安全回歸與必要監控均通過
• 臨時緩解已撤銷或轉為正式控制，不留下重複與衝突規則

用五組指標看流程健康，不要只報『準時率 95%』

單一 SLA 達成率很容易被工單分類、低風險數量與例外方式影響。至少要按優先級、資產類型、公開程度、團隊與月份分組，並同時看平均值與第 90 百分位；否則少數長期暴露的高風險項目會被大量快速關閉的低風險項目掩蓋。

建議分開量測發現到確認、確認到緩解、確認到修復、部署到複驗，以及首次發現到關閉。這些時間分別反映分流、緊急處置、工程交付、驗證容量與整體風險窗口，不能只用一個平均修復時間代表。

例外也要納入指標。若準時率提高但例外數、平均例外年齡與重複延長同步上升，代表風險只是被搬出 SLA 分母。管理者應看到逾期項目、暴露天數、失效控制與沒有永久修復計畫的例外。

90 天導入計畫：先讓資料可信，再逐步收緊期限

第一版 SLA 不必追求複雜模型。前 30 天先統一資產識別、狀態、優先級、責任人與時間欄位，並用既有工單回算真實分布。若資料連首次發現日、部署環境與關閉證據都不完整，直接設定嚴格期限只會產生大量例外與人工爭議。

第 31 到 60 天選擇少量公開或關鍵服務試行，建立 P0/P1 升級、臨時緩解、例外核准與複驗流程。每週檢視逾期原因，分辨是驗證積壓、沒有 owner、缺少測試環境、變更窗口不足、供應商等待或資產資料錯誤。

第 61 到 90 天再把政策擴大，設定自動提醒與升級，把掃描、工單、部署與複驗資料串接，並由治理層審查例外與風險暴露。期限應根據實際能力逐步收緊，但不能因現況落後就把高風險基準設定得毫無意義。

弱點修復 SLA 政策上線前檢查清單

以下清單可以直接用於政策審查、工單欄位設計或供應商需求。若其中一項沒有答案，團隊就可能在真正的 P0 發生時才開始討論誰負責、何時計時與什麼才算完成。

• 是否明確區分 SLA、SLO、分流、緩解、永久修復與複驗期限？
• 是否定義工作日／日曆日、時區、計時起點、截止點與允許暫停條件？
• 是否保留首次發現與風險暴露天數，不因重開、轉單或例外歸零？
• 優先級是否同時考慮暴露、利用證據、資產、資料、攻擊條件與控制？
• 是否明確列出 KEV、主動利用、控制失效與資產公開等升級事件？
• P0 是否有 24×7 聯絡、事件指揮、緊急緩解、通報與復原路徑？
• 每筆確認弱點是否同時有 accountable owner、assignee、目標版本與期限？
• 補償性控制是否有覆蓋、驗證、監控、失效條件、擁有者與到期日？
• 風險例外是否有殘餘風險、核准層級、提前重評事件與永久修復計畫？
• 第三方與舊系統是否有獨立的緩解、升級、退出與替換路徑？
• 關閉是否強制要求原始條件複驗、同根因覆蓋與正常功能回歸？
• 儀表板是否同時呈現 P90、逾期、暴露天數、例外年齡與重開率？

好的 SLA 不是把團隊逼快，而是讓真正風險更早被處理

弱點修復期限的核心，不是用同一組天數處罰所有團隊，而是讓已遭利用、公開且影響重大的問題先得到資源，同時讓每一筆延期都有明確責任、控制與退出條件。技術嚴重度提供共同起點，企業情境決定真正處置優先級。

當分流、緩解、永久修復、例外與複驗各有可驗證閘門，管理者看到的不再只是工單準時率，而是風險暴露多久、哪個控制正在保護系統、誰接受剩餘風險，以及問題何時真正消失。這才是一套能支撐日常安全營運的修復 SLA。