Mozilla 在 2026 年公布，Firefox 150 修補了 271 個由 Claude Mythos Preview 找出的漏洞。Mozilla 說明，這些結果經過漏洞去重、分流、修補、測試與發布；當月共發布 423 個安全修補，還包括其他模型、模糊測試與人工發現的問題。Mozilla 的技術回顧呈現的關鍵，不只在模型能找到多少問題，也在團隊如何承接、確認並交付修補。

Cloud Security Alliance（CSA，雲端安全聯盟）提出 VulnOps，嘗試把這個交接問題放進一套持續運作的漏洞、風險與修補管理模式。企業導入 AI 開發工具或掃描代理後，候選漏洞可能增加；若資產資料、負責人、測試環境和部署權限沒有跟上，發現速度就不會自動轉成更快的風險降低。導入前要確認來源、每站負責人與修補後的關閉證據。

AI 找到更多漏洞，為什麼待修清單仍可能變長？

因為發現速度與修補吞吐量是不同環節。 若影響確認、排程、測試或正式部署的能力沒有增加，新增候選項目會在交接處形成積壓。

掃描結果、嚴重度分數或工單數量，無法單獨說明風險是否下降。發現可能是誤報、重複項目、未受影響資產，或在特定環境中不可觸及；分數不高的漏洞若位於對外服務且有攻擊路徑，也可能需要優先處理。排序前要補足資產、版本、網路暴露與既有防護脈絡。

Anthropic 在 2026 年說明，使用 Claude 檢查開源程式碼時，團隊已找到並驗證超過 500 個高嚴重度漏洞，並開始向維護者通報；初期由安全研究員逐一確認漏洞並手動撰寫修補，後續才增加外部研究員協助驗證與修補。Anthropic 的研究說明同時指出，報告經過去重、重新排序與人工確認。這是供應商公布的工作成果，能說明發現後仍需要人力承接，不能直接推論其他組織也會得到相同數量或效率。

AI 漏洞回報的驗證流程也與這個問題相連：發現訊號要能重現、對應到具體程式與影響，才適合進入修補隊列。當輸入端變快，驗證關卡若仍靠零散工單或個人判斷，積壓就會出現在確認與分派階段，而非掃描工具本身。

VulnOps 如何把不同來源的漏洞接進同一條流程？

VulnOps 將發布前程式碼、已部署系統，以及外部公告與供應商修補，匯入共同的分流、驗證、排序、處理和回查流程。 各來源可以採用不同驗證路徑，但都要能追蹤責任與處理結果。

CSA 將 VulnOps 定義為組織與流程設計。三個輸入流包括發布前程式碼掃描、已部署資產的掃描或新發現，以及供應商公告、上游版本、漏洞獎金回報與協調揭露。三者匯入共用流程，避免隔離隊列各自競用相同修補能力。CSA 的 VulnOps 操作模式也提醒，已部署的資產若無法對應到元件版本與負責人，後續就難以確認影響範圍或安排部署。

匯流不等於把每一則告警都當成一筆新工作。程式碼掃描、部署端掃描與供應商公告可能指向同一個元件或根因。系統應保存原始來源，再依受影響的資產、版本、弱點類型與修補方式合併重複項目。若一個上游修補能處理一批相同工作站上的漏洞，排程時也應以實際需要測試和部署的變更為單位，同時保留常見漏洞與暴露（CVE）編號、嚴重度及受影響系統數等資料。

去重不等於風險相同。不同服務即使使用同一個漏洞套件，暴露程度、重要性與變更風險仍可能不同。資產清冊要能查出元件版本、對外暴露情況、維護人、測試環境和部署核准者；缺少這些資料，就很難排序。

從影響確認到部署，哪些關卡不能跳過？

至少要確認漏洞是否適用、在組織環境是否可觸及、修補是否有效且不會造成不可接受的故障，並在部署後重新驗證。 緊急程度可以改變處理速度，不能取代證據與責任紀錄。

安全人員與系統負責者要確認受影響產品、版本、設定及攻擊路徑。AI 代理可以比對資產或產生測試案例，正式環境測試仍須先定義授權範圍。CSA 將證據關卡與人員決策納入模式，要求記錄測試、例外及部署的核准者。

接下來由工程、平台或產品維護人員選擇修補、暫時緩解或風險接受。若修補未通過測試或暫時無法部署，可先限制存取、隔離系統或調整設定，並指定到期日與重評條件。CISA 的漏洞應變手冊也建議，已遭利用的漏洞應依 Known Exploited Vulnerabilities（KEV，已知遭利用漏洞）目錄的時程處理；若修補尚未取得、未測試或不能即刻套用，可採取隔離、停用服務或其他緩解措施，之後再安全套用修補。CISA 漏洞應變手冊 PDF

「VulnOps 是讓漏洞、風險與修補管理轉向整合且持續運作的組織與流程改變。」（Cloud Security Alliance，CSA）

部署要兼顧測試證據和營運風險。先在測試環境確認修補，再分批發布、監測並準備回復條件。上線後仍要重新掃描或測試，確認弱點消失、服務正常且沒有復發；若驗證失敗，重新開啟工單並記錄原因。

流程圖呈現修補由測試環境進入小批次發布，再逐步擴大、回復或進行上線後漏洞複測。
分批發布並保留回復路徑，能讓修補在降低漏洞風險時兼顧服務穩定。

企業如何判斷流程能否消化新增漏洞？

可以追蹤已確認發現的吸收率，但必須同時公開分母、時間窗、處理範圍及修補品質指標。 單看關閉比例，可能看不出範圍縮小、未驗證結案或重複項目造成的偏差。

CSA 將吸收率定義為一段時間內已解決發現數除以新建立的已確認發現數，並提出以滾動 30 天觀察的做法。該文件建議，修補或有效緩解經回查確認後才算解決；若比例低於 1，進入流程的工作多於離開的工作，待處理量便可能持續增加。這是 CSA 提出的指標設計，不是已證明能替所有企業預測事故或保證修補速度的通用門檻。使用時要說明分母如何計算、何時開始計數，以及不同輸入流是否分開呈現。

吸收率也要搭配品質指標。縮小掃描範圍或提高納入門檻，可能讓比例上升，同時降低可見風險。至少應並列新增與解決的原始數量、受掃描資產範圍、嚴重漏洞的未結案時間、修補部署失敗率，以及重新開啟或復發的比例。發現到確認的時間變長，可能表示驗證容量不足；確認到部署的時間變長，則可能卡在測試、責任交接或變更窗口。

Microsoft 在 2026 年 6 月安全更新中處理 200 個漏洞。公司 5 月的另一份說明指出，漏洞回報量逐年增加，研究者協作、自動化與 AI 檢視都參與發現；當月回報仍經微軟安全應變中心（MSRC）驗證、排序與揭露。Microsoft 的流程說明及盧安達國家資安機關的 6 月更新摘要分別呈現處理流程和更新量，不能據此把六月 200 個漏洞都歸為 AI 發現。

Mozilla 的 Firefox 案例提供另一個流程觀察點。團隊指出，271 個漏洞修補並非一批模型輸出直接送進正式版本；Mozilla 建置了結合重現測試、去重、追蹤、分流及發布的安全漏洞生命週期，並由工程師逐項處理。Mozilla 同時說明，公布的 271 項屬於 AI 評估找到的漏洞，當月總修補數 423 項還包含模糊測試、內部與外部回報等其他來源。

「發現子系統本身並不足夠；要擴大規模，還需要接上完整的安全漏洞生命週期。」（Mozilla Firefox 團隊，技術回顧）

導入 VulnOps 前，先檢查哪些交接缺口？

先選一筆近期漏洞，從來源一路追到修補後回查，確認每一站都有可辨認的負責人、完成條件與證據。 如果第一個停滯點無人承接，應先補流程能力，再增加發現工具或代理數量。

  1. 盤點資產與輸入來源：確認程式碼、部署環境、供應商公告與外部回報是否都能進入同一個追蹤位置，並能連到元件版本、系統負責人和暴露情況。
  2. 定義確認與排序條件：記錄如何排除重複、誤報與不適用版本；排序時納入可觸及性、已遭利用狀態、服務重要性和修補風險。
  3. 指定決策責任：寫清楚誰可核准漏洞測試、修補部署、暫時緩解與延期；延期要有風險接受者、期限及重新檢視條件。
  4. 準備測試和回復：確認測試環境能重現問題，部署有監測項目、回復方案與授權範圍，並能在修補後再次驗證。
  5. 建立能解讀的指標：設定吸收率的分子、分母、統計期間及結案條件，並一併觀察掃描範圍、待處理年齡、部署失敗和復發情況。

小型團隊可由具決策權的負責人串起開發、維運與資安，先挑一個服務或發布管線試行。試點要涵蓋來源、驗證、修補和回查，才能看出組織承接能力。若外包掃描或驗證，資產授權、部署核准與風險接受仍由企業負責。

SBOM 漏洞修補流程談到元件清單、告警比對與責任分派；它可作為檢查資產與軟體供應鏈脈絡的延伸。

五張並列卡片列出資產與負責人、漏洞來源、驗證證據、風險決策，以及測試回復與修補後查核。
導入前先確認資產、責任、驗證和部署條件都有人承接，才能判斷流程缺口。

導入 VulnOps 前，常見問題怎麼判斷？

先確認組織能否把已確認漏洞一路追蹤到責任人、修補或緩解決策及部署後證據。 VulnOps 是運作模式，工具與自動化程度要依現有條件決定。

  • AI 發現能力增加後，驗證、排序、測試、部署與回查會決定漏洞管理能否跟上。
  • VulnOps 將三類來源接入共同流程，但需要資產脈絡、明確責任與人員決策關卡。
  • 吸收率要連同統計範圍、原始數量、修補失敗和復發情況閱讀。

Q1：VulnOps 是產品還是漏洞管理模式？

VulnOps 是 CSA 提出的漏洞管理操作模式，整合發現、驗證、排序、修補部署與回查。工具可依現有系統選擇。

Q2：導入 VulnOps 是否代表漏洞修補可以全自動？

不代表。自動化可協助去重、補充脈絡或產生測試；高影響測試、核准範圍外的部署與延期風險，仍由指定人員負責。

Q3：沒有專責團隊的企業可以先從哪裡開始？

選一筆近期漏洞，追蹤來源、受影響資產、負責人、測試部署與關閉證據，再改善最常停滯的交接點。