Anthropic OSS Scanner：開源維護者必須了解的安全掃描服務

Anthropic 推出了 OSS Scanner。這是一項可選擇加入的服務，面向符合條件的開源專案，免費提供由其強大 AI 模型執行的週期性漏洞掃描。這項發布正值軟體維護者需要重新思考安全工作的時刻：AI 可以快速發現有價值的線索，但這些線索仍需要嚴格的人工作業來重現與分級。

TL;DR：OSS Scanner 提供什麼

OSS Scanner 不是一般的依賴檢查器，也不是安全團隊的替代品。維護者需要透過 Anthropic 的官方 GitHub 儲存庫為專案申請加入。掃描器會在隔離環境中建置專案，在沒有網際網路存取的條件下分析程式碼，再把報告寄給專案設定的聯絡人。報告可能包含重現步驟、漏洞解釋、可用時的程式碼歷史或二分定位，以及候選修補程式。

最重要的取捨是速度與審查。快速通道報告由模型產生，不經人工驗證，因此可能出現誤報、嚴重性評級過高，或誤解專案威脅模型的情況。

為什麼它會影響軟體供應鏈

瀏覽器、雲端服務、行動應用程式、開發者工具與企業系統都依賴開源套件。許多關鍵專案由小型團隊維護，無法持續進行深度安全稽核。免費掃描服務可以補上商業產品和付費稽核難以覆蓋的範圍。

Anthropic 表示，其更廣泛的漏洞發現工作已產生超過 29,000 個候選漏洞，其中約 6,000 個經過人工審查或分流。這個差距說明 OSS Scanner 的設計：具備處理原始報告能力的專案，可以選擇更快的報告流，而不必等待所有結果排入人工隊列。

這項發布也發生在 AI 生成安全報告品質參差不齊的背景下。維護者不應把「模型發現」直接視為「已確認漏洞」。OSS Scanner 以明確的自願加入、私下寄送報告和維護者負責驗證的方式，降低未驗證警報擴散的風險。

如何申請加入

公開加入流程以程式碼儲存庫為中心。維護者需要提交拉取請求，新增專案目錄以及建置和理解程式碼所需的設定。儲存庫說明要求準備 project.yaml 和 Dockerfile，也可以提供 threat_model.md。掃描器會在隔離虛擬機器中完成建置，並在沒有網際網路的環境中分析專案。

專案資格並非自動取得。Anthropic 的目標是對基礎設施和使用者安全具有重要影響的開源軟體，標準與 OSS-Fuzz 類似。公開儲存庫不代表一定會被接受。提交前也應閱讀 OSS Scanner 服務條款。

維護者的實用工作流程

處理 AI 生成的安全報告時，最穩妥的方法是把它當作高價值線索，而不是已確認漏洞。先在乾淨環境中使用報告指定的版本和步驟重現，再按照專案真實的信任邊界重新判斷影響。接著測試候選修補程式、補上回歸測試，並檢查受影響程式碼是否已進入發行版本。

也應把報告接收流程和公開發布流程分開。建立私有安全佇列，把模型信心與人工嚴重性分開記錄，並要求維護者或安全審查者批准公告、CVE 申請、版本發布和公開披露。這樣可以保留 AI 的速度優勢，而不會把未驗證輸出直接變成下游使用者的警報。

選擇開發者軟體時，也要查看工具的安全流程，而不能只看功能列表。BTTC 的軟體發現目錄可以協助讀者比較開發和安全工具，但每次下載仍應核對官方發布頁、簽章說明和專案安全策略。

需要注意的限制與風險

OSS Scanner 不能消除模糊測試、依賴分析、程式碼審查、威脅建模和事件回應的必要性。需要執行環境、特殊部署假設或業務邏輯知識的漏洞，可能被 AI 掃描器遺漏；掃描器也可能給出看似合理但不正確的解釋。

另一個風險是報告數量讓維護者不堪負荷。因此，專案應在加入前制定嚴重性標籤、重現要求、責任人、回應時間和升級路徑。尤其涉及身分驗證、解析器、密碼學、沙箱和更新機制時，不要直接合併候選修補程式。

也要注意機密性和存取控制。維護者應了解會提交哪些原始碼、哪些聯絡人會收到報告，以及建置設定如何處理秘密。建置腳本應使用測試憑證和可重現測試資料，不要使用正式環境權杖。

常見問題

OSS Scanner 免費嗎？

Anthropic 將 OSS Scanner 描述為提供給符合條件開源專案的免費服務。專案需要主動申請，而且是否接受由 Anthropic 決定。

報告會經過人工審查嗎？

快速通道報告由模型產生，不經人工審查。維護者必須先重現、評估與分流，再決定如何處理。

OSS Scanner 能取代一般安全工具嗎？

不能。它應與程式碼審查、模糊測試、依賴掃描、安全發布流程和專案威脅模型配合使用。

收到可疑報告後該做什麼？

在指定版本上重現，確認威脅模型和影響，測試候選修補程式，加入回歸測試，並在公開細節前使用專案的私下披露流程。

結論

Anthropic OSS Scanner 的意義在於，它把先進的 AI 漏洞發現能力變成開源維護者可以選擇加入的服務，同時明確驗證責任仍在專案一方。它最適合加速安全研究的第一輪，而不是完全自動化安全。準備加入的團隊應預先建立私有分流流程、可重現建置、清楚的嚴重性規則和人工批准門檻。

如需了解更多開發者工具、安全工具和軟體選型內容，請前往 BTTC 部落格。