Anthropic OSS Scanner：當未審查的漏洞報告交到維護者手上

Anthropic 在 2026 年 10 月推出 OSS Scanner，讓符合資格、主動加入的開源專案直接收到模型生成的漏洞報告。這個快速通道不經人工審查或分流，報告可能錯誤；Anthropic 同時保留原本由外部安全研究團隊驗證、再依協調式漏洞揭露（CVD）流程通知維護者的路徑。變化的核心不是又多一款掃描器，而是漏洞發現速度超過驗證容量後，誰要接手第一線判斷。

候選增加，人工驗證仍是瓶頸

Anthropic 表示，在此前六個月掃描部分重要開源專案期間，模型產生超過 29,000 筆候選漏洞，但團隊只來得及人工審查與分流約 6,000 筆。Anthropic 也說，有些維護者在收到首批報告後，要求一次取得全部未驗證候選與提議的修補程式；截至發表時，近 5,000 份未驗證報告已依維護者要求直接送出。這些是 Anthropic 自行公布的活動數字，說明它面對的處理量與工作流選擇，並非獨立的品質評估。

OSS Scanner 把這種「先交候選、由專案自行判讀」的選項正式化。Anthropic 說，報告會由模型生成，可能附上重現步驟、漏洞解釋、可能的引入時間點，以及可用時的候選修補程式。專案需要自行檢查報告是否可重現、是否符合自己的威脅模型、是否和已知問題重複，再判斷優先度與處置方式。

兩條揭露路徑，責任落點不同

Anthropic 保留了兩條不能混為一談的路徑：

1. 一般 CVD：模型提出候選後，外部安全研究團隊重現問題、判斷是否為真實漏洞並評估嚴重度，再將通過驗證的報告交給維護者。這條路徑吸收了大部分驗證工作，也較適合無法自行消化大量原始候選的專案。
2. OSS Scanner 快速通道：合資格專案的核心維護者提交設定並選擇加入，模型報告會直接送達，不先經人工檢查。專案可以提供 threat model、嚴重度標準與去重偏好；也能暫停或退出，但收到報告後的重現、分級與排程仍要由專案承擔。

這項選擇並非對每個開源專案都合適。Anthropic 的 FAQ 表示，它會逐案評估專案資格，並將服務定位給已能處理經驗證高／嚴重度漏洞回報、且希望進一步強化安全的專案。若維護者連可信的高風險報告都無法及時處理，增加未驗證候選可能只會讓重要訊號淹沒在佇列裡。

快速通道如何接入專案

這不是讓任何人貼上 Git URL 就能啟動的即時掃描器。核心維護者要先向服務提交專案設定，指定來源儲存庫、報告收件人與 Dockerfile；Dockerfile 負責準備相依套件和建置流程，讓掃描代理能在隔離環境中離線檢查程式碼。專案也可以補充 threat model，說明哪些輸入、信任邊界和部署方式才是專案真正需要防守的範圍。

這種離線建置設計有助於限制掃描期間的網路存取，但不會自動消除風險：維護者仍需檢查建置指令是否執行不可信腳本、提供的 Dockerfile 是否安全，以及收件信箱是否由多人監看。服務文件也提醒，登記資料會公開在 GitHub；主要聯絡地址應使用願意公開的安全信箱，而不是私人個人地址。報告含有可重現程式碼或 patch 時，接收端應在隔離環境驗證，不應直接在正式環境執行。

Anthropic 表示，快速通道的報告不會套用一般 CVD 的固定公開揭露時程，也不會由 Anthropic 公開；接收專案仍需自行決定如何修補及對外說明。這讓專案更早看到線索，卻也代表維護者要先想好私下協調、版本發布與安全公告怎麼銜接。加入前，最好確認安全信箱、回報去重、修補分支及外部研究者聯絡流程有明確負責人。

97 筆樣本說明了什麼，又沒有說明什麼

Anthropic 表示，它請負責 CVD 審查的專家滲透測試人員檢查 OSS Scanner 早期版本在 48 個專案中產生的 97 筆高／嚴重度發現。其中 85 筆符合 Anthropic 的 CVD 標準；另外 11 筆是真實問題，但屬於重複或其他不適合回報的發現；1 筆無效。這組結果值得留意，但它是由嚴重度挑選的 97 筆樣本，不是隨機抽樣，也不是 29,000 多筆候選的整體精確率，更不能代表所有未審查的直接報告。

Anthropic 公開的 CVD 儀表板 與揭露 ledger 也屬於另一個、更廣的協調揭露計畫。儀表板截至 2026 年 10 月 2 日列出 6,123 筆由外部研究團隊審查的發現、5,674 筆被確認有效，另有直接送給維護者、可能含誤報的報告。這些累計數字涵蓋多個模型與 CVD 計畫流程，不能拿來補成 OSS Scanner 新加入專案的準確率。儀表板和 ledger 的用途，是呈現已揭露流程、審查來源與披露狀態；它們並未提供新服務完整候選串流的獨立評估。

目前仍缺少新服務整體候選的獨立精確率、依嚴重度或專案類型的誤報率、維護者花費時間是否下降，以及報告最後是否促成修補或降低重複漏洞。工程決策應以這些尚未回答的問題為背景，而不要將「有重現器」或「高嚴重度」當成已驗證結論。

Anthropic 同時刊出部分專案維護者的使用回饋。例如 wolfSSL 維護者表示，在收到的 74 份報告中，除兩份外皆有效，並有五份後續成為 CVE；curl 維護者則表示 OSS Scanner 找到多個值得處理的問題。這些具體回饋說明某些專案已把報告納入既有流程，但仍是由服務提供者刊出的案例，沒有對照組、完整收件母體或可供獨立重現的彙總資料，不能替代整體服務品質評估。

另一個需要分開看的問題是「漏洞候選品質」與「維護工作量」。如果報告大多可重現，但重複問題多、嚴重度過高，或 patch 需要大量審查，維護者仍可能花更多時間在分流，而不是修補。較有用的服務評估應同時呈現：每個專案每週收到多少報告、初審與重現時間、重複／無效比例、確認後的修補完成率，以及安全公告前後的回應時間。現階段公開資料尚不足以回答這些營運問題。

維護者需要一個可承受的分流契約

決定加入前，專案可以先把以下要求寫成自己的工作約定：

• 指定接收人與備援：安全信箱要有人負責監看，並定義逾期或主要維護者不在時由誰接手。不要讓報告只寄到無人值守的個人信箱。
• 先定義威脅模型與嚴重度：指出哪些入口、部署情境與使用者邊界屬於專案責任，也說清楚哪些問題在此專案中不構成可利用風險。這有助於模型報告貼近實際，但不能替代驗證。
• 保留證據鏈：記錄報告識別碼、版本或 commit、重現環境、前置條件、影響範圍、重複檢查、修補決策與對外揭露狀態。將「模型聲稱」「維護者重現」「已修補」分開標示。
• 設定容量與退出條件：預估每週可以完成多少初審，並在逾期積壓、誤報成本過高或缺乏修補人力時暫停接收。接收更多線索不一定代表更快修好漏洞。

收到報告後，也可用固定狀態避免「有寄出」被誤當成「已修復」：待初審、需要重現、確認且排入修補、重複／不在威脅模型內、已修補待發布、已公開揭露。每筆都記下所測 commit、重現環境、受影響版本、外部依賴和修補驗證結果。這些狀態是維護團隊可採用的建議流程，並非 Anthropic 宣稱服務會自動替專案追蹤的功能。

這裡的重點不是把模型的判斷當成新權威，而是讓新增線索有明確的負責人、驗證步驟和結束狀態。若需要思考重現證據的最低要求，可以延伸閱讀 MobileCybench 如何用可執行 Probe 驗證漏洞主張；更廣泛的 Agent 身分、工具與威脅邊界，則可參考企業 AI Agent 安全架構與 AI Agent 完整指南。

OSS Scanner 將一項原本由維護者個別提出的要求，變成可選擇加入的交付模式。對人力足以自行驗證回報的核心基礎設施專案，它可能縮短候選線索到維護者手中的距離；對分流資源有限的專案，未審查報告則可能成為新的負擔。真正值得追蹤的指標因此不只有候選數，還包括可重現比例、去重成本、維護者回應時間、修補完成率，以及選擇暫停服務的專案比例。

Sources

• Anthropic：Launching an opt-in vulnerability-finding service for open-source software — 上線說明、Anthropic 報告的活動數字與 97 筆早期驗證樣本。
• OSS Scanner repository — 登記設定、建置與離線掃描方式、報告交付說明。
• OSS Scanner FAQ — 專案資格、威脅模型、暫停方式與未驗證回報政策。
• CVD dashboard and disclosure ledger — 截至 2026-10-02 的較廣泛 CVD 流程統計與公開揭露紀錄。