很多人在談 AI 漏洞掃描時，第一個想到的是能不能找出更多問題。對開源維護者來說，更前面的問題是：收到一份報告後，誰能確認漏洞確實存在、影響哪些版本，又能安排安全修補與揭露？Anthropic 在 2026 年 10 月 8 日宣布 Cyber Mission，當中的 OSS Scanner 為符合條件並主動加入的開源專案提供免費、定期掃描；報告由模型生成，不經人工審查。它能增加一個檢查來源，實際降低多少風險，仍取決於專案是否有能力接手驗證和修補。
Anthropic OSS Scanner 補上哪一段開源安全缺口？
它讓符合條件的專案定期取得模型產生的漏洞候選報告、重現方式與可用時附上的候選修補，補充既有安全檢查；報告未經人工審查，不能直接視為已確認漏洞。
開源程式碼被大量軟體與服務採用，維護工作卻常由小型團隊或志工承擔。靜態分析、模糊測試、程式碼審查和外部研究者通報各自能找出不同問題，執行成本與涵蓋範圍也不同。Anthropic 表示，OSS Scanner 受到 Google OSS-Fuzz 啟發，使用其高能力模型為加入的專案定期掃描，服務目前免費。報告可能包含漏洞說明、重現程式或步驟，以及有提供時的候選修補；部分重現材料會說明漏洞可能如何被利用。
它與 Claude Security 的對象不同。Anthropic 將 Claude Security 定位為一般可取得、協助企業防護自身系統的程式碼掃描與修補產品；OSS Scanner 則面向符合資格的開源專案，由 Anthropic 管理掃描安排，使用該服務也不代表專案已通過安全認證。既有的協調式漏洞揭露流程仍會處理經人工驗證的報告，Anthropic 表示，缺乏人力自行分流的專案仍可透過該流程接收人工驗證結果。兩種安排處理的是不同承接能力與速度需求。
加入掃描前，專案要準備哪些條件？
不是所有專案都會自動加入。核心維護者需向 Anthropic 的 OSS Scanner GitHub 儲存庫提交 PR，提供專案設定；Anthropic 會確認維護者身分，並依專案對基礎設施與使用者安全的重要性逐案評估。
設定至少涉及程式碼儲存庫、主要聯絡信箱與 Dockerfile。Dockerfile 用來安裝相依套件並建置專案；維護者可以將它放在自己的程式庫，或依官方格式附在申請目錄。Anthropic 也建議先在本機驗證設定並確認容器內測試能執行。這些準備不是文書工作而已，它們決定掃描環境能否重現專案建置，以及後續報告能否送到負責處理的人手上。
設定中的聯絡信箱會公開在專案設定檔中。維護團隊宜使用適合公開、有人輪值查看的安全聯絡地址，並確認副本收件者是否需要收到每封報告。若希望報告加密，官方文件支援提供 OpenPGP 公鑰，但此設定有與副本收件地址搭配的限制，申請前應按文件確認。
威脅模型檔案雖然選填，卻能提供掃描器難以從程式碼推知的背景，例如哪些輸入視為不可信、哪些元件在範圍內、哪些情境不處理，以及專案希望如何判定嚴重度。若沒有這些脈絡，模型仍會自行推測邊界，報告可能把符合專案設計的行為當成漏洞，也可能高估影響。維護者可以把專案安全政策、既有嚴重度規則及修補格式偏好寫進威脅模型，並隨專案調整。
建置和掃描的網路邊界也需要看清楚。專案 Dockerfile 建置時可連網取得相依套件；完成建置後，掃描才在沒有網際網路的環境執行。隔離掃描有助於限制掃描期間的網路存取，卻不會消除建置腳本、套件來源或版本未固定所帶來的供應鏈風險。若維護者在本機試跑官方檢查工具，GitHub 文件特別提醒，Docker 建置會執行專案提供的指令並能連網；應在可信任的隔離主機測試，避免讓不熟悉的建置流程接觸工作站檔案或內網服務。
模型產生的漏洞報告，如何確認是否成立？
先在隔離環境重現報告，再核對受影響版本、觸發條件、威脅模型與實際影響；候選修補則要獨立測試。Anthropic 明確說明報告沒有人工審查，且嚴重度可能判錯或不符合專案威脅模型。
第一步是固定報告所用的程式版本與依賴，再照重現步驟建立最小測試。確認問題是否能穩定出現，輸入是否必須由攻擊者控制，攻擊者需要什麼權限，漏洞會影響機密性、完整性或服務可用性。接著比對修正紀錄與既有問題，排除已修補版本、相同根因的重複通報，以及只在不受支援或非預期設定下出現的情況。這些檢查能把「程式碼看起來可疑」轉成維護者可決策的證據。
嚴重度也要拆開看。掃描器可能正確找到缺陷，卻高估利用條件或影響範圍；報告的標籤是排序線索，不應直接等同專案的風險判定。威脅模型要回答專案的信任邊界與安全目標，重現測試則回答漏洞在特定版本是否成立，兩者都不能由一個分數代替。
Anthropic 表示，早期驗證中，專家滲透測試人員檢查了 48 個專案的 97 件高或嚴重等級發現，其中 85 件符合其協調式漏洞揭露流程的門檻；其餘 12 件裡，11 件是真實問題但與已知問題或同輪發現重複，1 件屬於誤報。這是 Anthropic 對自家早期測試樣本的說明，不代表所有語言、架構或漏洞類型都會有相同結果。Anthropic 也提到，維護者曾回報嚴重度偏高或掃描器誤解專案威脅模型的情況；公司預期真陽性率超過 90%，仍是廠商提出的預期，不是獨立機構對所有專案的保證。
「我們檢查的 97 件高或嚴重等級發現中，85 件達到協調式漏洞揭露流程的門檻。」這是 Anthropic 對早期測試樣本的公布結果；樣本範圍與判準應一併保留。— Anthropic OSS Scanner 研究公告
如何把掃描結果接進既有修補流程？
不能只因報告附有候選修補就直接合併。維護團隊應先分流與重現，再檢查補丁是否修正根因、是否引入回歸，最後依專案安全政策決定修補發布和對外揭露。
可以把收到的報告記錄為待驗證項目，至少保留報告日期、受影響版本、重現環境、負責人與目前狀態。初步分流時，先看能否在支援版本重現、是否已有相同問題、是否涉及尚未發布的漏洞細節。高影響且可重現的問題需要優先隔離處理；不成立或重複的發現則記錄判斷依據，避免未來重複投入時間。若報告無法重現，先檢查編譯選項、平台差異與輸入前提，再向 Anthropic 或報告提供方詢問必要資訊。
候選補丁應先在分支或隔離環境套用，執行相關測試與程式碼審查，確認修補範圍沒有過大，也沒有改變公開介面或製造新的安全問題。接著按專案既有的安全公告、版本發布和相依套件通知流程處理。漏洞細節可能讓尚未更新的使用者暴露於攻擊，應在發布前依安全政策決定通知對象、揭露時間與公告內容。Anthropic 的專案說明指出，OSS Scanner 的報告不會公開，也不採用 90 天揭露期；專案仍須自行負責收到報告後的驗證、修補與發布安排。
漏洞發現數增加，不會自動讓風險下降。每件候選報告都會消耗重現、分級、協調與測試時間；如果維護者沒有排班、追蹤紀錄或安全發布權限，定期掃描可能把未處理佇列越堆越高。這對由少數志工維護、使用者卻遍及各地的套件尤其重要：一個被多個產品引用的元件，修補與通知會牽動下游專案；維護團隊需要預留時間確認受影響版本、準備修正版並協助使用者升級。掃描器能增加線索，不能代替這些協調工作。NIST 的 SP 800-216 是針對美國聯邦系統的漏洞揭露指引，提出正式化接收、評估、管理報告及溝通修補資訊的框架。它不是 OSS Scanner 的規定，也不直接約束一般開源專案，但其流程觀點可供維護團隊設計自己的通報入口與處理紀錄參考。
NIST SP 800-216 建議美國聯邦機關建立正式流程，接收、驗證、處理漏洞揭露報告，並溝通修補資訊。這份指引適用於聯邦系統，可供開源維護團隊設計通報流程時參考。— 美國國家標準暨技術研究院（NIST）
| 檢查方式 | 主要產出 | 維護者仍須處理的工作 |
|---|---|---|
| OSS Scanner | 定期的模型生成報告、重現材料與可能的候選修補 | 確認是否成立、判定影響、測試修補及依政策揭露 |
| 靜態分析／模糊測試 | 規則或測試輸入觸發的可疑路徑與失敗案例 | 調整規則或測試條件、判讀結果並修正程式 |
| 人工安全審查／協調揭露 | 經研究者或專家驗證的問題與通報協調 | 修補、發布版本、通知使用者並維護揭露紀錄 |
- 掃描報告是候選發現；重現與影響評估才決定它是否構成專案漏洞。
- 專案在加入前要確認有人能處理定期報告，並檢查建置環境、公開聯絡信箱與安全揭露流程。
哪些開源專案適合申請？
適合度取決於專案重要性、建置環境能否重現，以及團隊是否能及時驗證與修補。維護人力已難以處理現有通報的專案，可先改善分流能力，再決定是否接受更多未經人工審查的報告。
Anthropic 將服務對象描述為對基礎設施與使用者安全有關鍵影響的開源專案，並由公司逐案評估；核心維護者身分也會人工確認。維護者可先盤點依賴者與部署情境，說明專案為何重要，並確認申請資料能否由團隊共同維護。符合公開條件仍不代表必然收錄，官方也表示未來可能因申請量調整資格標準。
加入前可逐項檢視：建置步驟能否在隔離環境穩定完成、依賴來源是否可信、測試是否能在建置容器執行、公開信箱是否有人管理、威脅模型是否反映專案實際邊界，以及誰負責驗證報告和核准修補。還要確認暫停與退出方式：官方設定可將 disabled 設為 true 暫停報告，也可移除專案申請目錄退出。完成這些盤點後，維護者才能估算掃描增加的工作量是否能轉成更快的修補。
若專案已能快速處理人工驗證的高風險通報，也有人力測試掃描器報告，OSS Scanner 可成為額外的候選漏洞來源。若團隊沒有負責人、建置仰賴無法信任或無法固定的外部依賴，或缺乏安全發布安排，應先補足這些環節。真正影響使用者的，是從發現到修補之間的整段時間；掃描頻率只是其中一個因素。
- 先確認資格與維護者身分：整理專案用途、重要性與核心維護者證明，再查看官方申請規格。
- 檢查建置和資料邊界：審查 Dockerfile、依賴版本、網路需求，並使用適合公開的安全聯絡信箱。
- 指定報告承接人：設定重現、分級、去重、修補測試與揭露的負責角色和追蹤紀錄。
- 小步驗證再擴大：先處理一批報告，檢視實際投入與可重現率，再調整威脅模型和後續安排。
常見問題
Q1：OSS Scanner 的報告有經過人工審查嗎？
沒有。Anthropic 說明，報告由模型生成並直接寄給維護者，未經人工審查或分流，因此可能有錯誤、重複發現或嚴重度判斷不符專案情境。
Q2：任何開源專案都能申請嗎？
不一定。申請由核心維護者提交 PR，Anthropic 會確認維護者身分，並按專案對基礎設施與使用者安全的重要性逐案評估；官方可能依申請狀況調整資格。
Q3：收到報告後可以直接套用候選修補嗎？
不建議直接合併。先在隔離環境重現漏洞，核對適用版本和影響，再測試候選補丁與回歸情況，並按專案的安全政策安排發布和揭露。
參考來源
- Anthropic (2026). *Introducing the Anthropic Cyber Mission
- Anthropic Frontier Red Team (2026). *An opt-in vulnerability-finding service for open-source software
- Anthropic (2026). *OSS Scanner
- Schaffer K, Mell P, Trinh H, Van Wyk I. (2023). *Recommendations for Federal Vulnerability Disclosure Guidelines*. NIST SP 800-216
