維護者收到一份附有重現步驟與候選 patch 的漏洞報告，下一個問題是：誰能確認它影響哪個版本、成立需要什麼權限，以及修補會不會破壞合法用法？這些工作如果沒有接手的人，增加掃描頻率只會讓收件匣更長。

Anthropic 在 2026 年 10 月 8 日推出 OSS Scanner，讓符合資格、主動加入的開源專案免費接受定期掃描。報告完全由模型產生，沒有人工審查或分流。本文的工程判斷是：加入前應先定義報告如何從「收到」走到「已發布修補」，並讓每次狀態轉換都有證據。以下依官方公告與 repository 分析，沒有替專案登記，也沒有執行掃描器或重現任何漏洞。

85／97 只能回答那一批報告的問題

公告披露，Anthropic 過去六個月找到超過 29,000 個候選漏洞，人工審查與分流約 6,000 個。這個落差說明驗證人力已成為限制；它不表示剩下的候選項目都有效，也不能拿兩個數字相除當成準確率。

同一篇公告另列早期驗證樣本：48 個專案、97 個被列為 high 或 critical 的發現，85 個達到其協調式漏洞揭露（CVD）門檻；另外 11 個是真實但重複的問題，1 個無效。這是特定高嚴重度樣本的結果，沒有涵蓋所有嚴重度、所有專案或未被模型找到的漏洞。本文因此不把 88% 寫成服務整體 precision，更無法據此估算漏報率。

對維護者，這些數字支持的是「值得安排人驗證」，尚不足以支持自動合併 patch。公告也承認嚴重度可能高估，或誤解專案的威脅模型。收到一個可以 crash 的輸入後，仍要確認該輸入在支援的部署方式下是否可由攻擊者送達。

報告狀態要分開記，才能知道工作停在哪裡

我建議在既有私有安全追蹤系統加入以下概念契約。這不是 OSS Scanner 的官方輸出格式，範例 ID、版本與地址均為虛構；欄位要依專案的揭露政策調整。

report:
  id: example-report-001
  source_kind: model_generated
  target_revision: example-commit
  affected_release_range: unknown
  threat_preconditions:
    input_entrypoint: upload-parser
    attacker_access: unauthenticated
    deployment_assumptions: pending_review
  evidence:
    reproducer_artifact: private-artifact-001
    environment_manifest: pending
    original_failure: unverified
    patched_behavior: unverified
    legitimate_regression: unverified
  triage:
    owner: security-maintainers
    duplicate_of: null
    severity: pending_review
    status: received

source_kind 記錄出處，不隨人工確認而改掉；status 記錄當前工作。兩者分開，才能在修補完成後仍看出這份報告最初是模型產生的。

我會把狀態至少拆成 received、reproduced、accepted、patched、released，另設 duplicate、invalid 與 needs_information 分支。重現表示在記錄的環境看見失敗；接受表示專案認可安全影響；修補表示變更已完成驗收；發布則要有使用者能取得的版本。這些標籤是本文設計建議，不能互相代替。

停止規則：無法定位版本、無法說清楚威脅前提，或缺少可承接的負責人時，報告保留待查，不進入自動修補合併。 這能避免一個漂亮的重現程式，把尚未確認的影響範圍一起帶進 release note。

Threat model 要回答攻擊者可以做什麼

官方 repository要求專案提供建置方式，並建議附上 threat model。它也列出嚴重度評估、輸入入口、範圍與報告偏好等可補充資訊。這給維護者一個降低來回溝通成本的入口。

我建議 threat model 寫具體部署前提。例如，一個解析器可能同時用於公開上傳服務與受信任的離線批次工具。相同 crash 在兩種情境中的安全影響不同；「本專案只接受可信輸入」也必須對得上實際文件、預設設定與呼叫端，不能只是為了把報告降級而補上的說法。

可從這四個問題開始：

  • 哪個入口會接觸不可信輸入？由誰提供，經過哪些前置檢查？
  • 攻擊者需要登入、管理權限，還是只要網路可達？
  • 哪些部署模式與版本受支援？範例程式是否會被當成正式服務使用？
  • 嚴重度如何判定？哪個條件改變時需要重新評估？

維護者若修改了這些前提，應保留版本與理由。否則幾週後收到相同根因的另一份報告，很容易因描述不同而重複投入工時。去重應保留每個報告的證據，再把它們連到同一根因；只用標題或錯誤訊息去重，容易把相似症狀誤併。

離線稽核仍需要一個可控的建置環境

官方 README 描述的服務流程是先連網建置，再於沒有 Internet 的環境稽核；依賴應在建置階段備妥。其本機檢查工具也提醒，建置會執行專案 Dockerfile 並使用網路；即使用 QEMU 隔離檔案，仍可能接觸主機與區域網路服務。這不能被概括成「丟進 VM 就安全」。

對維護者的直接影響是：驗證環境本身要列入報告證據。記錄編譯器、依賴、測試命令與失敗輸出，並使用沒有日常憑證、沒有不必要內網權限的專用環境。測試因抓不到依賴而失敗，應標成環境問題；不能把它當成「漏洞無法重現」結案。

若要準備加入服務，README 中的設定鍵是小寫 dockerfile；聯絡地址會公開，應使用可公開的安全信箱。這篇文章不提供直接提交的登記檔，因為核心維護者資格、聯絡人、公開資訊與服務條款都需要專案自行確認。

讓修補通過正反例，再決定是否擴大接收量

報告附 patch 能縮短閱讀程式的時間，但修補可能只封住範例輸入。以下是建議的驗收案例，本文沒有執行它們，也沒有測得準確率或修補成功率。

  1. 在固定的舊版本與環境中重現原始失敗，保存輸入與結果。
  2. 在候選修補後重跑同一案例，確認安全性質成立，而不只確認程式沒有 crash。
  3. 加入合法輸入與鄰近邊界值，檢查修補是否誤擋支援行為。
  4. 對另一份相似報告比對根因、影響版本與修補位置，驗證去重決策。
  5. 刻意移除一項必要的攻擊前提，確認嚴重度與處理方式會重新評估。

這與用 ReviewBench 驗收 AI code review關注的問題不同：reviewer 的測評評估能不能找出問題；維護者的接收流程還要負責版本、揭露與發布。兩者需要各自的證據，不能只共用一個「通過」欄位。

接收量也應有上限。可以用「待確認報告中最老的一份已等待多久」與「本週仍沒有 owner 的報告數」觀察分流能力，再由團隊設定暫停條件。官方提供暫停報告的 disabled 設定；它是調整接收量的選項，不能拿來替代既有報告的追蹤責任。

下一步可以選一個已公開修復的歷史問題，照這份契約走完一次：從舊版本重現、威脅前提確認、修補回歸，一直到發布紀錄。若其中一步找不到證據或負責人，就已經知道正式接收更多報告前該補哪個環節。