Anthropic 推出 OSS Scanner：免費掃描開源漏洞，維護者還要驗證什麼？
Anthropic 推出免費、需主動加入的 OSS Scanner，讓符合條件的開源專案定期收到 AI 漏洞報告與候選修補。本文說明候選漏洞、人工驗證與正式修補的差別，整理申請資格、97 件早期樣本與維護者的驗收工作，避免把掃描報告當成安全保證。
AI 找到一個漏洞之後，誰來確認它真的存在，又由誰決定怎麼修？Anthropic 新推出的 OSS Scanner，把這個問題直接交到開源維護者面前。
公司在 2026 年 10 月 8 日宣布，符合條件、主動加入的開源專案，可以免費取得最強模型的定期安全掃描，使用模型包含 Claude Mythos。
官方公告 同時說清楚一個重要條件：這些報告完全由模型產生，沒有先經人工審核或分類處理，可能不正確或無效。
這是用速度交換部分驗證工作的新服務。它讓維護者更早看到候選問題，但不會讓「模型說有漏洞」自動變成「已確認需要修補」。
本文整理官方服務與維護流程，沒有執行掃描或驗證任何漏洞，也不提供攻擊操作。重點是讓團隊理解這些報告如何進入可靠的修復工作。
OSS Scanner 為什麼要把未審核報告提早交出去？
官方說，過去六個月使用新模型掃描重要軟體，取得超過 29,000 個候選漏洞，但人工只來得及檢查與分類約 6,000 個。
這兩個數字描述不同階段。29,000 是候選，6,000 是人工處理過的數量，不能寫成公司已確認 29,000 個真實漏洞。
候選漏洞可以理解成值得進一步調查的程式問題。它可能是有效缺陷，也可能來自模型誤解、重複報告，或與專案實際用途不符。
當模型產生報告的速度提高，人力驗證就可能成為瓶頸。官方說，有些維護者主動要求把尚未驗證的報告與修補建議一起寄來。
公司因此已應要求送出近 5,000 份這類報告，並把可選擇的快速管道做成服務。這不是所有專案都被強迫接受同一種報告方式。
對有能力自行分類與驗證的團隊，提早取得候選問題可能有價值。對缺少人力的專案，更多報告也可能增加負擔，兩者需要不同安排。
因此，「主動加入」是這個服務的重要部分。維護者先判斷自己能否處理未審核輸出，再決定是否把速度優先的管道接進工作流程。
一份報告不只有描述，還應讓維護者能重現問題
官方介紹的報告包含可獨立使用的重現範例、漏洞說明，並在可行時找出問題何時被引入，也在可提供時附上候選修補。
重現範例可以理解成讓工程師再次看到同一個問題的材料。它讓報告不只停在一段文字，而有機會被實際確認。
找出引入問題的版本，則能幫助團隊判斷影響範圍。某個舊版本已有缺陷，和最新修改才產生問題，可能需要不同的修復與溝通安排。
這些內容仍要按實際報告確認。官方說「可行時」提供，不代表每份報告一定有完整版本定位，也不代表每個候選都附上可直接採用的補丁。
補丁可以理解成對程式的修改方案。它可能處理眼前問題，但還需要看是否改變原本功能、是否影響其他環境，以及維護者是否接受。
對工程師，一份有重現材料與候選修補的報告，通常比只有模糊警告更容易進入工作。但容易開始，不代表最後驗證已經完成。
可以先確認專案與版本是否相符，再看問題是否能重現，接著檢查修補方案。這是本文提出的工作順序，不是替任何報告確認其有效性。
早期 97 件樣本很有參考價值，但不是所有報告的準確率
為驗證早期系統，Anthropic 請專業測試人員檢查 48 個專案的 97 件高嚴重度與關鍵候選，其中 85 件符合既有協調揭露流程的標準。
官方把這個比例寫成 88%。其餘 12 件裡，11 件是真實問題，但重複已知問題或同批發現，另 1 件無效，也就是誤報。
這組資料能說明早期高嚴重度樣本的結果，但不能直接當成所有掃描、所有專案與所有嚴重程度的統一準確率。
樣本選擇會影響解讀。這裡檢查的是高嚴重度與關鍵候選，較低嚴重度報告不在樣本中，不能套用同一分布。
重複問題也值得分開看。它不一定是假警報，但可能不是維護者需要新增處理的工作，重複數量仍會影響分類成本。
官方也收到維護者回饋，指出某些嚴重度評級可能偏高，或掃描器誤解專案的威脅模型。公司沒有保證系統會完全正確。
威脅模型可以理解成專案實際要防哪些情況，以及哪些人能接觸哪些功能。同一段程式在不同使用安排裡，風險可能不同。
因此，嚴重度標籤可以幫忙安排注意順序，不能替團隊回答所有影響條件。維護者仍需要把報告放回自己的系統用途裡判斷。
免費服務有加入條件，不是所有 GitHub 專案自動獲得
官方說，符合條件專案的核心維護者，可以依標準模板向 OSS Scanner 官方 GitHub 專案 提出加入申請。
資格採用類似 OSS-Fuzz 的原則，重點是對基礎設施與使用者安全有重要影響，實際是否接受由公司逐案判斷。
OSS-Fuzz 是 Google 面向開源軟體的安全測試計畫。Anthropic 以它作為服務方向的參考，不表示兩項服務使用相同工具或產生相同報告。
對維護者，先確認專案符合用途與資格，比只看到「免費」就預期立刻接入更實際。申請、接受與開始收到報告，是不同階段。
主動加入也代表需要安排接收與處理窗口。報告如果只是進到一個沒人看的位置，掃描速度提高，也不會自動讓軟體更安全。
可以先評估誰負責分類、誰驗證、誰審查修改，以及如何和原本版本發布流程接在一起。這些工作需要團隊在加入前理解。
官方另外提供 延伸 FAQ，讓維護者查看服務細節。具體加入條件仍應以該頁與官方專案說明為準。
既有人工揭露流程仍保留，快速管道是另一個選擇
Anthropic 說，仍會透過既有協調漏洞揭露流程，提供人工驗證過的報告，尤其保留給缺少自行分類資源的專案。
協調揭露可以理解成發現問題後，和維護者安排確認、修復與公開時程。它和把一個可能問題直接放到公開討論區，是不同做法。
新的快速管道則讓主動加入的維護者提早收到模型輸出。兩者的主要差別，在於報告到手時已經完成哪些檢查。
因此，不能把所有 Anthropic 漏洞報告都當成同一種狀態。接收者應知道它是原始候選、人工驗證報告，還是已被專案確認的缺陷。
| 報告或工作狀態 | 代表已完成什麼 | 還不能直接代表什麼 |
|---|---|---|
| 模型候選報告 | 模型找到值得調查的問題 | 漏洞已存在且影響正式系統 |
| 人工驗證報告 | 已完成一定範圍的確認 | 專案已採用修補並發布 |
| 候選補丁 | 有一份可審查的修改方案 | 功能與相容性都已通過 |
| 正式修復版本 | 專案已交付相關改動 | 所有使用者都已更新到新版本 |
這些名稱能讓團隊避免把中間進度寫成最後結果。對外說明時，也比較容易讓使用者理解目前需要採取哪一步。
修補不是套用一段程式，還要確認功能與版本交付
一個修補方案可能讓重現範例不再出錯，但仍需要確認原本功能。修掉某種輸入行為，若連合法用途也被阻擋，工作還沒有結束。
對維護者，測試應對應問題與受到影響的功能。只確認檔案有改動，無法知道它是否真的降低風險，也無法知道是否引入新問題。
版本差異也會影響修復。一份針對目前開發版本的補丁，未必能直接套用到所有舊分支，維護者需要按支持範圍處理。
修改被接受後，還要進入發布與通知。下游使用者如果仍用舊版本，程式專案已修好，與實際系統已更新，仍然是兩個不同狀態。
這些都是開源安全工作的日常部分。AI 可以協助更快產生候選與修改，但版本管理、接收判斷與交付責任仍需要清楚安排。
對使用開源套件的企業，也應知道自己實際使用的版本。看到上游發布安全消息，不代表內部所有系統都已完成更新。
這是本文的流程分析，並非對任何套件發出風險警報。它讓讀者理解掃描服務的重要性，也保留從報告到實際修復之間的工作。
AI 報告變多，維護者需要看處理成本與有效改善
官方強調模型找漏洞的能力已提高，但對專案而言，真正影響工作的是有效報告比例、重複程度、重現品質與修補是否可採用。
可以先看同一段時間收到多少候選、確認多少真實問題，以及每份報告需要多少人工時間，才能判斷服務是否幫忙減少負擔。
也要分開記錄嚴重度調整與重複問題。這些不一定代表模型完全錯誤，卻會影響工作優先順序與維護者的可用時間。
如果重現材料完整，團隊可能更容易驗證；如果報告缺少實際條件，就仍需要追問。單純比較報告數量，容易忽略這些差異。
因此，免費是使用成本的一部分，維護時間也是另一部分。能否讓真實問題更早被修復，才是值得持續追蹤的成果。
延伸閱讀：Project Glasswing 與 Claude Mythos 的資安工作，理解這項服務的模型與研究背景。
也可閱讀 Anthropic 資安驗證計畫的三種存取層級，區分掃描服務與專業人士使用模型的資格安排。
維護者也可以保留每個候選的來源與處理紀錄，讓同事知道它最後是有效問題、重複項目，還是需要更多條件才能確認的報告，避免不同人重做相同調查。
團隊回顧時，可以把確實進入修復版本的問題與尚未完成確認的候選分開比較。這能看出服務在哪個階段提供幫助，也讓後續改善建立在實際工作，而非單純累積報告數量。
常見問題
OSS Scanner 的報告都經過人工確認嗎？
沒有。官方說這項主動加入的快速服務輸出由模型產生，沒有人工審核或分類，可能不正確。既有人工驗證揭露流程仍另外保留。
29,000 個候選，就是 29,000 個確認漏洞嗎？
不是。候選是值得進一步調查的問題，可能有重複、誤解或無效情況。官方另列出約 6,000 件人工處理數量，兩個階段不能混寫。
88% 可以當成所有專案的準確率嗎？
不能。它來自 48 個專案的 97 件早期高嚴重度與關鍵樣本，描述該次檢查結果，不能直接套用所有報告與其他使用環境。
附上補丁，就能直接發布修復嗎？
仍需審查、測試與版本安排。候選修改不代表功能與相容性已通過，也不代表下游使用者已經更新到修復版本。
讓 AI 更早找到問題，也讓每個問題有清楚的驗證位置
OSS Scanner 把模型找漏洞的速度帶進開源維護，但它能產生的候選，仍需要接到維護者的分類、確認與修復流程。
想先建立程式工具、版本與修改回讀的基礎，可延伸閱讀 GitHub、VS Code 與 Claude Code 環境設定。這是開發能力的延伸，並非 OSS Scanner 服務操作教學。
對維護者，最重要的下一步仍是查看官方資格與 FAQ，再判斷團隊是否有能力接住未審核報告，讓更快的發現變成更可靠的修復。
