Claude Security：結案不等於修好

Claude Security 隨程式變更掃描、追蹤修補，問題復發時會重開。釐清已修正、誤報與接受風險，讓台灣維運團隊核對結案原因與版本，避免把關單數當成修補成果。

發佈於： 2026-10-23 | 更新於： 2026-10-23

內容查核： 2026-10-23 來源查核： 2026-10-23

Claude Security 的 10 月 21 日更新，讓漏洞掃描開始跟著程式碼繼續走。 它是 Anthropic 的託管資安服務，會在程式變更後追蹤既有發現是否已修好，之後若再次找到同一問題，還能自動重開。目前新版對 Claude Enterprise 用戶公開測試。

對替客戶維護網站、交付安全修補月報的台灣團隊，這能減少人工追查「這筆到底補了沒」的工作。但我不建議直接把已結案總數當成修補成果：系統裡的結案，可能是修好，也可能只是認定誤報、重複，或決定接受風險。要看的是結案原因與對應程式版本。

修補後再查，復發就重開

新版先做一次基準掃描，再依變更的風險與複雜度持續檢查。團隊可把相關程式庫放進同一專案，讓服務沿著前後端之間的資料流查找問題；掃描不只停在某一個檔案。不過，現行使用說明明列後續檢查沒有固定時程，不能把「持續」理解為每次提交都立即完成安全驗證。

修補追蹤也不限於 Claude Code 產生的修改。工程師在其他流程修好程式，Claude Security 仍會檢查變更與尚未結案的發現，再標示處理狀態。這對有人手動修改、有人使用代理協作的團隊，比要求所有修補都換到同一套工具更實用。

但重查仍是模型做的判斷。文件說明，同一份程式碼在不同次掃描中可能出現不同結果；被標為已修正的問題，也要在模型之後再次找到時才會重開。我的判斷是，這提供了可接續追查的紀錄，沒有替團隊免掉原本的測試與發布確認。還在建立這套流程的讀者，可參考原始碼安全審查指南。

不同產品的驗證依據也應分開看。GitHub 現行文件說明，Agentic Autofix 會嘗試重跑 CodeQL 查詢來驗證修補，並列有無法確認的查詢類型；Claude Security 的後續掃描則會依程式脈絡重新分析。使用 GitHub 修補代理的團隊，不能只看兩邊都有「已修正」，就把檢查過程當成相同。

另有同名的 Claude Code 掃描外掛，是在使用者的工作階段內按需執行，使用該帳號可用的模型。它和這次更新的託管持續監看服務是不同入口，安裝外掛不代表程式庫已開始被持續追蹤。

已結案，也可能是接受風險

使用說明把發現的狀態分成 Open 與 Resolved，後者另外記錄結案原因。官方操作教學也允許人員把發現標為已修正，或以誤報、接受風險、重複等理由排除。這些處置不能混成同一種成果。

結案原因	代表的處理
已修正	被標為修好，仍應看對應變更與驗證依據
誤報或重複	問題被排除，或已另有追蹤紀錄，不代表新增修補
接受風險	團隊決定保留風險，不能算成已消除

尤其要留意排除之後的行為。使用說明指出，被排除的那筆發現不會在後續掃描重新出現；這與已修正問題之後可能自動重開不同。如果團隊因為「這個入口目前只在內網」而接受風險，日後服務對外開放，就需要人回頭檢視原本的判斷，不能指望同一筆警示一定會自己回來。

因此，向客戶報告時，我會把修補完成、經判定排除、接受風險分開列，並保留當時的理由。教學建議在處置時加註說明，發現本身也有變更歷史；API 與 MCP 介面還能讓人從其他工具調整結案或重開狀態。狀態欄是一項工作紀錄，未必每次都代表掃描器重新證明了什麼。

程式版本也要對上。發現的證據會記錄掃描的分支與提交；修補進入該分支，不足以推論客戶正式服務已部署同一版本。原本的拉取請求審查與測試仍有用途：讓團隊確認改了哪裡、驗過什麼，以及實際發布了什麼。

常見問題

Claude Security 把問題標為已修正，之後還會重開嗎？

如果它之後再次找到同一問題，會自動重開。這不代表每次提交都會立即完成重查；後續掃描會依風險與複雜度進行，沒有固定時程。

把發現當成誤報或接受風險排除後，還會再提醒嗎？

依現行使用說明，被排除的那筆發現不會在後續掃描重新出現。接受風險並不代表改好了程式，若部署條件或可存取範圍改變，團隊需要回頭檢視原先理由。

舊的 Claude Security 專案會自動換成新版嗎？

舊專案會繼續沿用原本體驗，擁有者可另行移轉。移轉會建立新專案、複製發現並封存舊專案，但成員、事件通知、排除目錄、掃描歷史與排程不會一併複製。GitHub Enterprise 專案目前不能移轉。

參考來源

№ · further reading