InfoQ 在 2026 年 10 月 23 日報導，Anthropic 推出一項名為 OSS Scanner 的服務，針對開源專案提供免費、可選擇加入的安全掃描。它不是把掃描結果直接當成已確認漏洞，而是由 Anthropic 較強的模型，包括 Claude Mythos，定期產生安全報告，寄給已註冊的維護者。報告未經人工審查，維護者必須自行判斷發現是否成立，並決定要接受哪些候選修補。這個設計的核心問題很明確：開源基礎設施的安全需求持續增加，但有能力審查漏洞、驗證修補與協調揭露的維護者數量並沒有同步成長。
開源維護者的驗證瓶頸
Anthropic 的 Frontier Red Team 在 10 月 8 日公告中說明，人工驗證已經成為限制。過去六個月，模型找出超過 29,000 個候選漏洞，但研究人員實際手動檢視與分流約 6,000 個。對於希望提早取得結果的維護者，Anthropic 已經提供近 5,000 份未經驗證的報告與建議修補。這組數字反映的不是模型能不能找到問題，而是找到之後由誰確認、排序與修補。OSS Scanner 因此把驗證責任部分交回專案端，讓維護者用自己的威脅模型與流程判斷哪些報告值得處理。
每份報告會附上可獨立執行的重現器、疑似漏洞的說明，並在可能時透過二分搜尋找出引入問題的變更，再提供候選修補。這讓報告不只是告警，而是帶有可操作線索的工單。這項工作延伸自 Project Glasswing；InfoQ 在 4 月曾報導，Anthropic 當時把 Mythos Preview 的使用權限限制給參與組織。PostgreSQL 維護者 Noah Misch 表示，快速通道存取協助專案在正式發布前處理問題，並提到「有幾份報告附帶的修補幾乎可以直接使用」。這句話點出 OSS Scanner 的價值：若報告能直接對接維護者既有的審查與修補流程，就能降低從發現到修復的摩擦。
從測試數據到實際案例
Anthropic 曾以早期掃描器版本進行測試，請滲透測試人員評估 48 個專案中的 97 個重大與高嚴重性發現。其中 85 個符合其協調漏洞揭露標準；另外 11 個是真實問題，但與已知問題或其他掃描結果重複；1 個無效。這些結果只描述這個被選取的樣本，不能直接推論成 OSS Scanner 未來每份報告的準確率。Anthropic 也承認，部分維護者看過誇大的嚴重性評級，以及對專案威脅模型的誤解。OpenSSL Corporation 的 Anton Arapov 仍認為原始報告「與我們從人得到的報告一樣好，有時甚至更好」，尤其在已有可用攻擊驗證時，確認問題會變得直接。wolfSSL 的 Todd Ouska 則表示候選修補能配合專案既有的驗證與修補流程，並指出在收到的 74 份報告中，除了兩份之外都有效，其中五項成為 CVE。
在公告之外，也有一個由維護者確認的案例。curl 的 Daniel Stenberg 把一個 HTTP/2 上傳的 use-after-free 漏洞歸功於 Anthropic 的 Luna Tong 使用 OSS Scanner。該問題在 curl 8.23.0 修復，編號 CVE-2026-92392，在特定條件下可能允許遠端程式碼執行。Stenberg 將其評為高風險而非重大風險，原因是成功利用並不容易，較可能的結果是程式崩潰。這個案例同時說明模型掃描能找到真實且具影響力的問題，也說明嚴重性判斷仍需依賴實際可利用性與專案脈絡，而非僅看漏洞類型。
與 OSS-Fuzz、CodeMender 的差異
Anthropic 表示 OSS Scanner 受到 Google OSS-Fuzz 啟發，但兩者方法不同。OSS-Fuzz 主要透過模糊測試與既有工具尋找程式當機與記憶體錯誤；OSS Scanner 則使用語言模型調查程式碼，嘗試理解變更、根因與修補方向。另一個可比較的系統是 Google DeepMind 的 CodeMender，InfoQ 在 2025 年 10 月報導過。CodeMender 在發布說明中，研究人員 Raluca Ada Popa 與 Four Flynn 描述以程式分析與測試進行自動化修補驗證，並在上游提交前保留人工審查。OSS Scanner 的不同之處，在於它會直接把未經人工審查的發現送給維護者。這個差異既是效率來源，也是風險來源：維護者能更早知道問題，但也要承擔更多分流成本，並面對誤報、重複與嚴重性偏差。
OSS Scanner 的常見問題說明提到，系統在寄出報告前，會由代理程式再次檢查漏洞、提出修補並分析根因。這種自動檢查與人工審查是分開的。後續掃描會尋找新引入的問題與先前漏掉的問題，頻率取決於專案使用情況與服務負載等因素。換句話說，OSS Scanner 不是一次性稽核，而是持續性的掃描流程，但其覆蓋範圍與節奏並非固定承諾。
影響、限制與導入條件
在揭露流程上，未經驗證的發現沒有自動的 90 天揭露期限。若某份報告之後被人工驗證，才可能進入另一套協調揭露流程，90 天期間從維護者被告知該驗證結果時起算。專案可以暫停報告或退出。Anthropic 也持續提供人工審查揭露，特別是針對沒有資源分流原始發現的專案。這表示 OSS Scanner 並非要取代傳統安全研究與協調揭露，而是增加一條較早、較大量、但需要專案端自行吸收雜訊的管道。
社群評論則把焦點放在修補之後的現實。Endor Labs 執行長兼共同創辦人 Varun Badhwar 在 LinkedIn 指出，如果企業還落後三個主要版本，上游修補幫助有限；他認為企業必須確認有漏洞的程式碼是否可達，以及能否在不破壞應用的前提下採用修補。Dimitrios Thomas 也在 LinkedIn 以個人身分表示，評估這類服務時應看驗證準確率、維護者工作量，以及從發現到實際部署修補的時間，而不是只看回報多少漏洞。這些觀點提醒，掃描服務的價值不只在找到問題，也在能否降低維護與升級成本。
有意加入的專案，核心維護者需透過 GitHub pull request 註冊，內容包含專案設定與一個準備建置環境與相依套件的 Dockerfile。掃描在設定完成後不需網際網路連線即可執行。可選的威脅模型文件能記錄掃描範圍與嚴重性預期，維護者可用它指出不受信任的輸入、排除特定元件、說明如何判斷嚴重性，也能指定偏好的報告格式與修補期待。Anthropic 會手動檢查註冊請求，確認申請者是核心維護者，且發現會送到獲授權的專案安全聯絡窗口。資格採逐案評估，優先考慮對基礎設施與使用者安全重要、且已有能力處理已驗證高嚴重性報告的成熟專案。
整體來看，OSS Scanner 把大型語言模型放到開源漏洞發現與修補建議的前端，並以「可選擇加入、未經人工審查、維護者自行驗證」的方式運作。它的潛力在於擴大發現量並壓縮初步分析時間；限制則在於誤報、嚴重性偏差、維護者負荷，以及從報告到實際部署修補之間的距離。對關鍵開源專案而言，這是一項值得觀察的安全基礎設施實驗，也是一個把驗證責任重新分配的案例。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。