資料核對：2026-10-30。本文以 2026 年 10 月 20–22 日的公告與公開郵件為案例，整理給需要安排漏洞驗證與修補工作的資安、維運人員。封面為概念插畫，內文截圖則取自各段標示的原始來源。
早上打開弱點掃描報告，看到 500 個 CVE，先修哪一個？
當 AI 能協助研究人員探索更多程式路徑，這個問題會更值得注意。我的判斷是：防禦效果取決於整條處理流程，從確認問題、判斷環境是否受影響，到測試、部署與驗證更新，每一步都需要產能。報告增加，並不會自動讓這些工作一起完成。
1. 官方公告已經留下 AI 參與研究的紀錄
先把可以確認的證據放在一起：
| 案例 | 公開紀錄 | 可以支持的結論 |
|---|---|---|
| PHP2Shell | OpenAI 說明 Calif 使用 GPT-5.6 Sol 研究 PHP 漏洞，PHP 維護者主導修補與發布 | 模型能力與研究、維護及協調工作共同參與 |
| Node.js | 10 月 21 日公告中，Brotli 漏洞 CVE-2026-111497 致謝 OpenAI Codex Security 研究人員 | 研究成果已被專案納入正式公告 |
| Chrome | 10 月 20 日公告列出 CVE-2026-113303 的 Codex Security 致謝，以及 CVE-2026-113271 的 Claude 協助紀錄 | AI 參與已出現在日常使用的瀏覽器安全公告 |
來源：OpenAI 協調揭露說明、Node.js 安全公告、Chrome 安全公告。
這些紀錄能證明 AI 已參與研究，卻不能單靠致謝欄推斷每個研究步驟由誰完成、花了多久，或 AI 獨立完成的比例。
Node.js 的 Brotli 問題還有適用條件：應用程式必須讓外部可控制的壓縮內容進入相關解碼路徑，才需要進一步評估該攻擊面。安裝了 Node.js，不能直接等同於所有應用程式都有相同暴露程度；版本更新仍應依官方與供應商公告安排。Node.js 公告
2. 從可疑問題到有效報告，中間要有證據
我會把漏洞研究分成三道關卡：
- 可疑問題：某個流程看起來可能出錯。
- 穩定重現：在明確版本、設定與輸入條件下，能再次觀察到問題。
- 安全影響：證據能說明影響了什麼，以及成立所需的條件。
用一個教學假設來看：網站限制圖片只能上傳 10 MB，但程式先把內容完整載入記憶體，才檢查大小。限制有寫，檢查順序卻可能讓資源先被消耗。實際風險仍要核對入口限制、串流處理、可用記憶體與其他防護，不能只看這段描述就宣告存在可利用漏洞。
AI 可以協助追蹤資料從上傳、解析到儲存的路徑，提出測試假設。研究人員則需要在隔離且獲授權的環境中核對結果，記錄成功與失敗條件，並保留能讓別人檢查的證據。
PHP Foundation 對 PHP2Shell 的回顧也顯示，2024 年注意到的 OOM 問題，直到後續出現具體研究證據才釐清完整影響；修補同時涉及相容性與效能取捨。PHP Foundation 回顧
我的解讀是：值得交付的研究成果，應讓下一位處理者少猜幾件事，而不只是多收到一個可疑標題。
3. Linux 的 75%，指的是分流時間
Willy Tarreau 在 10 月 22 日的公開回信提到，當天收到超過 30 份待人工評估的報告，並描述過去約 75% 的分流時間花在讀報告、找維護者與轉寄。他也談到通報者能否協助測試修補的重要性。公開郵件
75% 不是假漏洞比例，也不是修補失敗率。 這封信呈現的是維護者的處理負擔；它沒有提供所有 AI 通報的品質分布，也不能據此把某單位的每份報告都歸為 AI 生成。
對企業內部也有一個可用的提醒：轉交掃描結果時，先補齊版本、設定、重複案件與負責人。把這些確認工作全部留給接手的人，待辦清單很容易只是換一個地方堆積。
4. PHP 的 15 與 100 多，不能直接算成功率
PHP Foundation 表示，自 2026 年 7 月 1 日起發布了 15 個 CVE，也處理過 100 多份無效、重複或無法重現的報告；團隊使用 AI 協助驗證與按根因分組，但判斷與修補仍有人員負責。PHP Foundation
這兩組數字的單位與對應關係不同。一個根因可能對應多份通報，報告也未必各自對應一個 CVE。缺少可比的完整母體，不能把它們組成「AI 找漏洞成功率」。
若我要檢查團隊是否改善，會更想看這些指標：確認受影響所需的時間、有負責人的案件比例、等待測試的時間，以及已完成部署並驗證的案件數。這些是建議追蹤的管理指標，並非上述來源已公布的統計。
5. 企業修補順序，不能只照基本分數排
CVSS 是描述漏洞嚴重性的共同方式。FIRST 的規格也區分基本、威脅與環境等資訊，並說明組織可把 CVSS 作為風險評估與弱點管理的輸入。CVSS v4.0 規格
以下是教學假設，9.8 與 8.1 僅用來示範基本分數排序的限制，不是對應真實漏洞的評分：
| 條件 | 測試主機 A | 正式網站 B |
|---|---|---|
| 假設的 CVSS 基本分數 | 9.8 | 8.1 |
| 暴露環境 | 隔離、未對外開放 | 對網際網路提供服務 |
| 業務資料 | 無重要資料 | 處理重要業務資料 |
| 利用情報 | 尚待核對 | 已確認實際利用，且有公開工具 |
| 建議處理 | 確認影響後排程，持續檢查隔離條件 | 優先確認適用性並安排緊急修補或緩解 |
在這組條件下，我會優先處理 B，並記錄理由。A 仍須處理；隔離情況、可達路徑或用途改變時，也要重新評估。
CISA 的 KEV 目錄可提供已知遭利用漏洞的情報，其官方 GitHub 鏡像提供資料檔與來源說明。CISA 官方 KEV 鏡像。未列入 KEV，不能當作沒有風險的證明；列入 KEV，也仍要核對自己的版本與設定是否受影響。
6. 把公告變成能交接的四步工作
以下是我建議的小規模起點，可以先挑一項對外服務試做：
| 步驟 | 先回答的問題 | 留下的紀錄 |
|---|---|---|
| 盤點資產 | 哪個服務在用？誰負責？對外開放嗎？ | 資產、負責人、實際執行版本、用途與暴露情況 |
| 確認適用性 | 官方受影響條件是否成立？有供應商回補嗎？ | 公告連結、套件完整版號、設定與判斷依據 |
| 排定處置 | 已有利用嗎？影響多大？更新或緩解何者可先做？ | 優先理由、負責人、期限、變更與回復方案 |
| 更新並驗證 | 工作程序已載入新版嗎？功能正常嗎？ | 部署紀錄、執行版本、重掃與功能測試結果 |
「已安裝更新套件」與「正在執行的服務已用上修補」需要分別確認。系統可能同時有多個執行環境，部分服務也可能需要重新載入。實際處理以供應商指引、變更程序及可驗證結果為準。
如果正在處理 PHP2Shell，可接著看已發布的 PHP2Shell 修補與防護指南，依負責角色核對更新、暫時防護與入侵跡象。
7. 讓 AI 的輸出可以被核對
我會先把 AI 用在公告摘要、版本資訊整理、重複案件分組與測試清單草擬，並要求每項判斷帶著依據：
- 來源與時間：從哪一份公告、哪個日期取得資訊。
- 適用條件：軟體、版本、設定、必要入口，以及還缺什麼資料。
- 判斷理由：為什麼排在前面，引用哪些資產與利用證據。
- 驗證結果：哪些已確認、哪些只是推測，下一步由誰確認。
若缺少執行中的版本，就標示待查；若沒有更新後測試紀錄，就保留待驗證。別讓流暢的摘要把未知條件藏起來。
這樣的起點比較容易驗收：挑一份公告、對應一項資產，請 AI 產生有來源的適用性清單，再由人員逐項核對。第一個目標，是交接者能重做相同的判斷。
8. 工程師的價值，會落在判斷與落地
從這些案例，我看到的是發現、驗證、修補與部署之間，需要更好的銜接。AI 可以加快部分工作，團隊仍要決定如何取捨安全性、相容性與營運需求，並確認處置真的生效。
先挑一項重要服務，把負責人、版本、暴露情況、待辦與驗證方式補齊，就能開始看出瓶頸在哪裡。
你的團隊最常卡在確認影響、安排更新，還是更新後驗證？歡迎分享分工方式，請避開公司、客戶及系統的可辨識資訊。