漏洞 修復 已成為執行難題。安全團隊發現的漏洞數量空前，但這些發現往往無法及時轉化為風險降低措施。新出現的漏洞與有效修復之間的差距持續擴大。
彌補這一差距需要的不僅是改進掃描、優化儀錶板或增加工具，還需要專門的營運模式。這正是漏洞營運中心（VOC）的角色所在。正如 網路安全研究中心（CyberMINDS Research Institute）執行董事娜塔莉·福斯特·約翰遜博士所解釋的那樣，“實施漏洞運營中心是組織成熟度提升的一個步驟，它使組織能夠更早地解決風險敞口問題，在事件發生之前降低風險，而不是事後被動應對。”
VOC（風險評估工具）集中管理組織如何評估風險、確定優先順序並推動補救措施。其目的不僅在於觀察風險暴露情況，更在於透過協調一致的行動積極降低風險。
安全產業先前也曾面臨類似的轉捩點。當威脅偵測變得持續不斷，警報數量激增，分散式回應模式不堪負荷時，各組織機構紛紛建立起正式的 安全營運中心（ SOC ）。如今，漏洞修復也正步入同樣的轉捩點。漏洞的數量、速度和複雜性都已超出分散式管理的能力範圍。漏洞修復中心（VOC）應運而生，成為應對之策。
行業數據顯示，這種 轉變已經開始，許多組織正在採用或計劃採用與 VOC一致的模式。
為什麼傳統漏洞管理落後了
傳統的漏洞管理方式是為較為緩慢的環境而設計的。團隊定期掃描漏洞，分配嚴重性評分，建立工單，然後循環進行修復。這種方法在基礎設施穩定且漏洞易於管理的情況下行之有效。
那種環境已不存在。雲端和混合架構不斷變化，快速部署帶來的新缺陷遠遠超過週期性工作流程所能吸收的範圍。
同時，漏洞修復的責任歸屬也變得分散。基礎架構、雲端、終端、身分和應用團隊各自負責部分攻擊面。漏洞可能由中央統一識別，但修復工作卻依賴於各個優先順序不同的團隊之間的協調。
這種碎片化加劇了 優先排序的 難度，但這並非唯一原因。當團隊缺乏威脅活動、業務影響、補償控制措施或可利用性等背景資訊時，優先排序也會出現問題。僅憑嚴重性分數會顯得過於簡單粗暴，而補救措施往往側重於最容易修復的問題，而非降低風險的問題。
積壓案件越來越多，高風險項目持續開放的時間也過長。
隨著 CVE 披露數量逐年增長，這種結構性錯配問題愈演愈烈。
資料來源：https://www.cve.org/About/Metrics
從漏洞清單到風險暴露管理
一旦修復工作成為執行難題，工作單元就必須改變。僅僅管理漏洞清單已遠遠不夠，組織必須 管理漏洞暴露。
孤立的漏洞提供的洞察有限。只有當漏洞可存取、可利用，並且與對業務至關重要的系統或身分相關聯時，風險才會真正顯現。網路資產上的低嚴重性問題可能比孤立的關鍵漏洞帶來更大的風險。
這反映了攻擊者的運作方式。攻擊具有選擇性，這意味著優先排序必須基於攻擊的可及性、攻擊活動和業務影響，而不僅僅是嚴重性評分。
持續威脅暴露管理(CTEM)框架 將這種轉變正式化，它將暴露管理視為貫穿發現、優先排序、驗證和行動的持續性過程。然而，僅僅了解暴露情況並不能降低暴露風險。如果沒有明確的責任歸屬，它仍然停留在理論層面。
隨著組織採用 CTEM，漏洞管理正從技術職能演變為一項協調的營運規範。
這時，漏洞營運中心就顯得至關重要了。
漏洞營運中心作為控制塔
成熟的漏洞營運中心充當漏洞和風險敞口管理的營運控制塔。它不會取代現有的安全或交付團隊，而是透過集中化、問責制的模式來協調他們的工作。
「VOC 將重點從單純發現漏洞轉移到實施風險降低措施，明確責任歸屬、協調機制和可衡量的補救結果。」
— 網路安全與關鍵基礎設施彈性策略家 Natalie Foster Johnson 博士，CyberMINDS 研究所。
VOC 最重要的角色之一是建立治理機制。它透過引入與業務風險一致的結構化工作流程、優先標準、升級路徑和問責制，彌合了負責識別漏洞的安全團隊和負責修復漏洞的維運團隊之間的差距。
近期產業研究證實，各組織正朝著這個方向發展。在2025年針對企業安全領導者的調查中， 65%的受訪者表示已實施客戶之聲（VOC）或與VOC相符的模式。在這些組織中， 大多數認為該模型具有中等到高的價值，14%的組織表示正在積極推進採用。
資料來源：CESIN「Baromètre de la cybersécurité des entreprises」Rapport d'étude – Vague 2026 年 1 月 11 日
實際上，VOC（顧客之聲）的採用程度會因組織成熟度而異。擁有成熟CERT（電腦緊急應變小組）或漏洞應變團隊的大型企業更有可能正式設立專門的VOC職能部門。
規模較小的組織往往難以配備足夠的人員來組成基本的電腦緊急應變小組 (CERT)。在這些環境中，漏洞修復通常由安全營運中心 (SOC)、基礎設施或託管服務團隊負責，通常被視為週期性審計活動，而不是持續的運維工作。儘管許多組織參考了諸如 CTEM 之類的風險暴露框架，但其執行仍然以評估為導向，而不是持續進行。
這些限制導致了 VOC 鄰近模型的興起，其中存在協調和修復指導，但沒有正式定義的 VOC 結構。
當組織正式實施客戶之聲（VOC）時，此職能通常著重於五個核心任務：
為了有效率地運作，VOC 團隊會專注於反映執行情況而非發現量的關鍵績效指標 (KPI)。這些指標包括補救時間表、風險積壓減少、跨資產類別的服務等級協定 (SLA) 執行情況，以及衡量持續進展而非一次性清理的指標。成熟的團隊也會監控各責任團隊的反應速度和補救措施的後續落實情況，以強化問責制。
營運所有權模式進一步強化了這項轉變。調查數據顯示， 目前有41%的組織自行管理其客戶之聲（或類似的組織群體），高於上一次調查週期的30%，這表明組織正明顯轉向集中式的內部問責制，而非外包或非正式的補救模式。
VOC 與安全營運中心 (SOC) 協同工作。 SOC 著重於偵測和回應，而 VOC 則著重於透過補救措施進行預防。
將活動轉化為風險降低
透過集中進行優先排序和補救指導，VOC 提供了持續應對風險敞口而非被動應對的必要架構。風險敞口管理在此發揮至關重要的作用。它將發現的結果整合到一個統一的、優先排序的視圖中，並使團隊能夠直接採取行動，從而有助於彌合風險識別與實際降低風險之間的差距。
了解持續威脅暴露管理如何支援以暴露為導向的安全營運： 暴露管理解決方案 – Check Point 軟體
文章來源/Check Point Bolg Check Point Bolg
返回