Claude Security 持續掃描更新：追蹤修補、跨程式庫與企業試用額度怎麼看？
Claude Security 持續掃描新增變更檢查、修補追蹤、可編輯威脅模型及 API/MCP。本文核對每專案 8 個程式庫、Enterprise 條件、25,000 美元兩期額度與期限，並解釋持續掃描不等於即時阻擋漏洞。
資安掃描報告很快就會過期，因為程式碼繼續變，修補也常在另一個工具完成。
Anthropic 在 2026 年 10 月 21 日推出 Claude Security 持續掃描更新，讓它在第一次完整掃描後追蹤變更，也檢查發現是否已被修掉。
台灣時間 10 月 22 日凌晨的官方貼文，把這次改動濃縮成「連一次程式庫，後續跟上程式變更」。這是四月公開測試之後的功能更新，並非今天才第一次推出產品。
但持續不等於即時。官方文件寫明，後續掃描依風險與複雜度安排，沒有固定時間表，更不是每次提交都保證立刻完成。
新版本還能把多個程式庫放進同一專案、補上部署情境，讓漏洞待辦比較接近團隊真正要處理的風險。
我會建議已有 Enterprise、跨服務資安待辦很多的團隊，從一個專案試起。Pro、Max 用戶，以及需要服務完全不保留資料的團隊，則應先核對資格與條件。
要衡量這次更新，先看它如何把一次報告變成持續維護的清單。
Claude Security 持續掃描怎麼跑？先完整基準再追變更
第一次深度掃描建立基準，後續再依新提交的風險與複雜度安排掃描，是新流程的核心。
程式庫是保存專案原始碼和修改紀錄的地方，提交則記錄一組變更。當團隊繼續開發，一份只對舊版本做的報告，就不一定反映現在的程式。
依 Anthropic 的更新公告，團隊建立專案、連接程式庫，選好分支與範圍後，Claude 先做深度基準掃描，再定期檢查變更。
基準掃描可以理解成先完整看一遍，建立後續比較的起點。但第一次可能花幾分鐘到幾小時，時間仍取決於程式庫規模和代理採取的分析步驟。
後續掃描沒有固定時間表，因此不能用「我剛提交，畫面沒有新發現」推論變更已經通過檢查。要判斷覆蓋到哪個版本，應看發現附上的分支與提交證據。
官方說明，每項發現會列出檔案位置、受掃描的分支與提交。這些資訊讓人知道結論對應哪一份程式碼，也讓修補討論不必只靠一個模糊的漏洞標題。
和固定規則的靜態分析不同，服務的代理會依情境調整分析，所以官方也提醒，同一份程式碼的不同掃描可能產生不同結果。它不保證每次執行列出完全一樣的項目。
對團隊的意義是，評估時不能只挑一次發現最多的結果。更應看重要問題是否有清楚證據、能否重現，以及新的提交進來後，清單是否仍對得上目前版本。
清單保持新鮮之後，還要知道其中的舊發現何時才算處理完，這是第二個更新重點。
修補追蹤與重新開啟：fixed 不等於正式環境已更新
系統會對照變動的程式碼，判斷原有發現是否已修正。即使修補在其他工具完成，也能標記為已修，日後問題再出現時則重新開啟。
這能減少一種常見的待辦落差：工程師已經把修正合併，資安清單卻還停在待處理，得另外找人回填狀態。
但要把「程式碼修好」和「正式服務已更新」分開。前者看修正是否進入受追蹤版本，後者還可能經過建置、部署和服務重新啟動，不能只憑 fixed 標記推論使用者已經受到保護。
例如漏洞修正在主分支，正式服務卻仍用上一版容器，兩者就有時間差。這是部署流程的例子，不是官方已替每個專案驗證線上版本的能力。
因此，團隊可以把掃描發現的狀態和部署紀錄連起來，保留「程式碼已修、等待部署」這種實際工作階段。這樣才不會讓自動關閉清單掩蓋最後一段更新。
官方文件也列出不同結案理由，包括已修正、由合併的請求修正、誤報、接受風險或重複項目。不同理由不代表同一件事，報表加總時也應分開。
若把「接受風險」和「漏洞消失」一起算成修正成功率，數字會變好看，卻無法回答系統是否更安全。自動追蹤提供的是較完整的紀錄，如何解讀仍由團隊決定。
修補本身仍需要人工審查。官方定位是產生有針對性的修正建議，再交工程師確認，沒有宣稱自動改碼後即可略過回歸驗證。
有些發現是否值得修，還需要把單一檔案以外的部署情境放進來，所以新版本增加了跨程式庫與威脅模型。
延伸閱讀：Cloudflare security-audit skill 是什麼？六階段開源資安稽核與沙盒前提
最多 8 個程式庫與可編輯威脅模型，能補哪種脈絡？
同一專案可以放多個相關程式庫，讓代理看見服務之間的資料流，不必把每個專案當成孤島。
官方使用說明寫明，每個專案最多 8 個程式庫。部分可以列為掃描範圍，部分只供理解背景，但兩種都算進上限。
例如後端假設手機端已經驗證輸入，手機端卻沒有做那項檢查，問題就跨在兩邊。只讀其中一個服務，可能看不見整段信任關係，這也是官方提出的跨庫用途。
但 8 個不是越多越好的目標。若把互不相關的程式庫放進同一專案，仍需要額外說明它們的關係，否則數量增加不一定能補足有用脈絡。
比較適合的起點，是一起提供同一項服務的前端、後端與共用元件。若某個程式庫只用來理解資料格式，可以先列為背景，讓正式掃描的責任範圍保持清楚。
威脅模型則記錄誰能碰到哪些功能、有哪些部署控制，以及團隊已接受什麼風險。它把原始碼裡看不見的條件補進分析。
Claude 會先根據程式碼產生威脅模型，團隊可以編輯並加入架構文件。例如某個管理介面是否對外開放，會影響一條攻擊路徑實際能不能到達。
官方表示，後續掃描會利用這些內容決定哪些問題值得提出、嚴重程度怎麼評分。因此，同類型缺陷出現在不同專案，可能得到不同等級。
這種做法有助於讓發現接近團隊的處理順序，但前提是環境說明正確。如果服務已改成公開，威脅模型卻還寫只有內部能連，就可能低估影響，所以部署變更也應反映在內容中。
有了可討論的脈絡，下一步是把發現帶進工程師平常工作的工具，而不是再增加一個只能登入查看的清單。
API、MCP 與角色權限：如何接進現有修補流程
新介面讓團隊能讀取發現、開始修正並更新狀態，操作仍受使用者原有權限限制。
API 是供程式呼叫的介面，可以列出或管理專案、程式庫與發現。MCP 則讓 Claude 或 Claude Code 這類助理，透過工具介面接上同一套資料。
官方描述的情境是，工程師在同一段對話中打開漏洞、詢問原因、開始修正，再標記處理狀態。這減少的是搬資料與切換工具，並不自動證明新修正已通過測試。
另外，Webhook 可以在新發現出現時通知團隊系統。Webhook 是由服務主動送出的事件通知，和人定時刷新頁面不同，適合接入現有工單流程。
這時要保留發現的識別與證據版本，避免同一問題在不同工具裡被誤當成兩項新漏洞。如何建立工單對應，是導入流程的安排，不能只看連接是否成功。
角色權限也比單一管理員更細。官方提供 Full、Triage、View 等專案角色，讓負責修補的人能分類與處理，而只需了解進度的人維持查看權限。
個人存取權杖只能看見和修改該使用者有權限處理的內容，所以自動化不應被理解成繞過專案權限的新入口。
GitHub.com 和 GitHub Enterprise Server 透過 Claude GitHub App 連接，其他 Git 服務則使用程式庫位址與授權權杖。內部自架環境還要符合官方網路連線要求，不能只填網址就假定可達。
工具接得進去，也不代表帳號資格和費用已經具備。這次的促銷條件，需要另用一套時間與用量規則理解。
Enterprise 資格與 25,000 美元額度：兩期怎麼算？
新版本是 Claude Enterprise 的公開測試功能。依官方說明，使用者需要相應的 premium seat，組織開啟按用量計費的 credits，並由擁有者在設定中啟用。
它不要求另有 Cyber Verification Program 存取權，但這不代表 Pro 或 Max 方案也能直接使用。產品使用資格與高階資安模型的直接存取，是不同條件。
官方提供符合資格組織每期最高 25,000 美元、連續兩期的促銷使用額度。這裡的「月」從組織開始日期算到下一個月同日，不是每到月初重新送一筆。
例如依條款規則，某組織從 10 月 22 日開始，一期會跨到 11 月相同日期，再接下一期。這是說明計算方法，實際起算仍以組織帳戶紀錄為準。
未用完額度不滾存，而且整個優惠會在 2026 年 12 月 31 日 UTC 當天結束，即台灣時間 2027 年 1 月 1 日上午 8 時。因此，官方提醒 11 月 1 日之後加入的組織，拿不到兩個完整月。
額度會先於組織原有承諾支出或使用 credits 扣除，用完或到期後，服務按直接 token 成本收費。Token 是模型處理文字的計量單位，所以程式庫規模、上下文和掃描工作都可能影響消耗。
舊版專案也不會自動享有新優惠，要遷移到新版體驗後才納入。遷移會建立新專案、複製發現並封存舊專案，但成員、Webhook、排除資料夾、掃描歷史與原排程不會一起帶過去。
這代表遷移後要重新核對連接和範圍，不能看到發現清單出現就認為所有設定已搬完。官方另明示，GitHub Enterprise 專案不能使用該遷移方式。
促銷能提供試點空間，但服務持續運作仍有帳單。組織可以另設專屬支出限制，並在專案設定查看當月與每日用量，先用一個範圍清楚的專案比較，較容易找到消耗原因。
導入前先驗收一個專案：漏報、誤報與資料保留
比起追求發現總數，更有用的試點問題是：團隊能否從證據理解風險，修正之後清單是否正確更新。
可以先挑一個已有測試、部署範圍清楚的服務，確認首次掃描引用的提交，再跟進一項經人工確認的發現，觀察修改、合併與重新掃描後的紀錄。
這個流程會同時碰到新版本的幾個核心功能，卻不必把所有程式庫一次接進來。若發現一直被重開，也能檢查是修正沒有涵蓋問題、掃描分支不同，還是模型判斷需要調整。
誤報處理也要留下原因。如果問題已被部署控制擋住，可以把具體條件寫進威脅模型，而不是只按一次忽略，讓後續掃描失去理解團隊選擇的依據。
資料政策方面，這是由廠商負責運作的雲端代管服務。官方明確表示，它不支援零資料保留，也就是 ZDR。另有 Claude Code 的資安外掛走不同部署路徑，但不能把外掛條件套到這個產品。
因此，有這項硬性要求的組織，應先確認部署方案，而不是因為看到「公開測試」或「免費額度」就把程式碼接上。這是產品是否適用的條件，與掃描能找到多少問題不同。
Anthropic 宣稱，四月以來已有數千組織用服務找到超過一百萬項漏洞。公告沒有提供足以獨立核對全部發現的明細，不能再推成百萬項都屬嚴重、互不重複或已修正的漏洞。
那個總數可以說明官方描述的使用規模，但團隊自己的判斷，仍應回到有用發現比例、修補品質和待辦結清速度。
延伸閱讀：Codex Security Cloud 完整解析：Daybreak Blue、全程式庫掃描與 AI 修復怎麼用？
Claude Security 持續掃描常見問題
後續掃描是每次提交立即掃完嗎？
不是。官方說明它檢查新提交，再依風險和複雜度安排掃描，沒有固定時間表。應核對掃描引用的分支和提交，不能以沒有新警報代表已完成。
一個專案最多接幾個程式庫？
最多 8 個，包括正式掃描範圍和只供背景脈絡的程式庫。只供背景的程式庫會被讀取，但不在其中提出發現。
企業免費額度會每月永久重置嗎？
不會。符合資格組織可有連續兩期、每期最高 25,000 美元的促銷額度，不滾存，且受 2026 年底 UTC 截止限制，之後按用量計費。
雲端代管版支援 ZDR 嗎？
官方使用說明明示不支援。Claude Code 的另一個資安外掛有不同使用條件，不能視為同一項服務。
先追完一項修補，再決定擴大掃描範圍
這次更新把掃描、團隊脈絡與修補狀態接在一起，對已經有漏洞待辦流程的 Enterprise 團隊，比單次再多一份報告更有實際意義。
值得先選一個專案，從發現一路追到程式碼修正與部署確認，再衡量是否減少追蹤工作。若資格或資料保留條件不符，就先處理這些採用前提。
想持續追蹤 AI 資安工具的更新與使用界線，可免費訂閱 AI 郵報，並在開啟試點前重新核對官方條款。
