資安或工程團隊想讓 Claude Code 幫忙掃舊 repo，最容易卡在掃描結果交出去的那一刻。模型可能很快列出一百個可疑點，但工程師回頭問：哪一個真的可達？哪一個會被現有驗證擋住？修補會不會讓登入、付款或補助申請流程壞掉？如果這些答案沒有一起交付，AI 只是把待辦清單放大。
比較安全的起點，是把 Claude Code 限定在「整理證據、產生修補草稿」這兩件事。先選一條高風險服務，定義威脅模型與沙箱，要求每個 finding 附上可達路徑、檔案行號、測試或反證，再讓人審 diff 與上線風險。成果要看少數高信心問題是否更快進入測試、修補與回滾準備，不要看模型列出多少疑似漏洞。
先決定：今天要交付的是可審補丁
Anthropic 2026 年 5 月的原始碼安全方法文，把瓶頸講得很清楚：漏洞探索已經比較容易平行化，難的是驗證、分級與修補。模型會讀得很快，也會把「看起來像漏洞」的片段大量列出來；資安團隊實際需要的是可驗證證據、重複 finding 去除、影響分級，以及能安全合併的修補。
7 月 6 日 Anthropic 又發布 Alberta 政府案例。官方說 Alberta Ministry of Technology and Innovation 從 2025 年開始用 Claude Code 搭配 Opus、Sonnet 檢查政府系統，案例中提到 1,280 個 applications、3,400 個 repositories、466 million lines of code，約 20 小時完成掃描；同篇案例也說，修補前仍由 ministry engineers review and approve。這些數字適合拿來理解「大規模舊系統可以怎麼拆任務」，不該被拿來承諾自己的 repo 也能在同樣時間完成。
對一般團隊，第一個可交付成果應該是三件事：一份縮小範圍的威脅模型、一批有證據的高信心 finding、以及少量附測試的修補 PR。只拿「掃了幾百萬行」或「找到多少疑似漏洞」報告進度，會讓主管誤以為風險已經下降，實際上工程師還沒拿到能合併的改動。
第一輪只掃一條高風險服務
不要從全公司 monorepo 開始。先挑一條真的會讓業務停擺或資料外洩的服務，例如登入、檔案上傳、付款、webhook、搜尋端點、匯出報表、內部管理後台。範圍越小，越容易確認模型是不是誤會信任邊界，也越容易讓工程師驗證修補。
| 今天的情境 | 讓 Claude Code 做什麼 | 暫時不要做什麼 |
|---|---|---|
| 舊服務沒有完整文件 | 先整理資料流、外部入口、權限邊界與高風險模組 | 直接要求「找所有漏洞」 |
| 測試覆蓋率很低 | 先補最小可跑的回歸測試或重現測試 | 讓模型一次改很多檔案 |
| SAST 已經有大量警告 | 請模型去重、補可達路徑與攻擊前提 | 把所有警告原封不動丟給工程師 |
| 準備修補高風險 finding | 產生 patch 草稿、測試與 rollback note | 自動合併安全改動 |
這張表的用意是避免把 Claude Code 變成另一個噪音來源。模型擅長讀程式碼、整理脈絡、提出假設；最後要不要修、怎麼排優先順序、何時上線，仍要由熟悉服務的人決定。
把 Claude Code 放進五段流程
第一段是威脅模型。先讓 Claude Code 讀 README、路由、schema、權限檢查、部署設定與最近的事故紀錄，整理誰能呼叫這個服務、資料從哪裡進來、哪些欄位不能被外部控制、哪些操作需要管理員權限。Anthropic 方法文也提到，false positives 常來自模型誤會 trust boundaries；威脅模型就是先把這個誤會降下來。
第二段是沙箱。掃描前先建立能 build、能跑測試、能重現主要路徑的乾淨環境。Anthropic 建議在設定環境時才開網路，依賴裝好後 snapshot，掃描時只保留必要的模型 API 連線。小團隊不一定要一次做到完整隔離，但至少要讓 Claude Code 的命令、檔案改動與外部連線被記錄，不能在正式資料或正式金鑰旁邊試漏洞。
第三段是 discovery。這時才讓 Claude Code 針對高風險模組找候選問題，例如未驗證 redirect、權限檢查漏接、檔案上傳副檔名與 MIME 檢查落差、server-side request、SQL query 拼接、shell command、反序列化或 webhook signature。提示詞要要求模型列出假設，不要只列結論。
第四段是 verification 與 triage。每個 finding 都要回答：外部使用者是否能碰到這條路徑？需要什麼權限？目前有沒有 middleware、schema validation、feature flag 或網路層擋住？如果需要特定資料狀態才能觸發，要把前提寫出來。找不到可達路徑的 finding 先不要進修補 queue。
第五段是 patching。Claude Code 可以產生修補草稿、測試與說明，但 PR 要小。安全改動最好一個 PR 解一類問題，附測試結果、影響路徑、回滾方式和人工審查人。Alberta 案例提到 Claude Code 在缺少自動測試時先寫測試；這點比「AI 自動修好」更值得學，因為沒有測試的修補很難知道是不是只是換一種壞法。
Finding 交給工程師前要長什麼樣
一個可交付 finding 至少要能讓工程師在十分鐘內判斷要不要排進修補。標題不要寫「可能有 injection」這種模糊句；要寫成「admin/export 對 format 參數缺少白名單，外部使用者可觸發非預期檔案產生」這類可檢查描述。
內容要包含六個欄位：檔案與行號、可達路徑、攻擊前提、資料或服務影響、建議測試、建議修補。若模型無法提供觸發步驟或反證方式，就把它留在 research backlog，不要送進 sprint。工程師最怕的是 AI 把沒有證據的猜測包裝成高優先級，最後擠掉已經確認該修的問題。
可以要求 Claude Code 在最後多做一輪反方檢查：假設這個 finding 是 false positive，最可能被哪個檢查、middleware、schema、權限或部署設定擋住？這一輪常常能砍掉一半以上的噪音，也能逼模型把證據寫得更清楚。
修補時先寫測試，再讓人審 diff
修補安全漏洞時，先問現有測試能不能保護行為。沒有測試，就先讓 Claude Code 寫一個會在舊版失敗、在修補後通過的測試；如果漏洞太難直接重現，至少補一個針對權限、輸入驗證或錯誤處理的回歸測試。測試跑不起來時，不要把 patch 當成完成。
人工審查也要看兩層。第一層是安全審查：finding 是否真的被消掉，旁邊是否還有同類變體，修補是否引入新的 bypass。第二層是產品審查：合法使用者會不會被擋、錯誤訊息會不會變得難懂、客服或營運流程需不需要同步。Claude Code 可以幫忙列 diff summary，但最後簽核要回到服務任務負責人與資安 reviewer。
如果團隊已經讓 AI agent 能讀 repo、開 branch 或跑命令，請把權限和紀錄也一起補上。延伸可接 Zero Trust for AI Agents：Claude Tag 的 agent identity 權限怎麼設，把 agent 身分、允許工具、網路出口、審查紀錄與停用方式拆清楚。安全掃描本身不該成為新的權限漏洞。
哪些 repo 可以先試，哪些先等一下
適合先試的，是已有測試或容易補測試、服務任務清楚、風險路徑可切小、工程師願意審 diff 的 repo。老系統也可以試，但第一輪要更窄，例如只看登入 callback、檔案上傳或一個批次匯出端點。
先不要把 Claude Code 放到沒有任務負責人、沒有測試、沒有 staging、金鑰散在 repo 裡、或牽涉不可回復資料寫入的系統上。這些地方要先處理存取權限、金鑰、備份、log 與回滾，再讓 AI 協助讀碼或修補。若連人類 reviewer 都很難安全改，模型只會讓改動變快，不會讓風險變小。
想補一般 AI 安全工程底盤，可接著看 AI 安全工程：從 prompt injection 到權限邊界怎麼防；如果想比較自動漏洞探索和傳統 AppSec 排程，可搭配 Microsoft M-DASH agentic vulnerability discovery 這類案例看，但不要把任何單一廠商案例當成通用 benchmark。
一週試跑版本
第一天選一條服務，請服務任務負責人和資安 reviewer 寫下威脅模型與不能碰的路徑。第二天建立沙箱、跑既有測試、補缺少的環境變數範例。第三天讓 Claude Code 做 discovery，但只收需要證據的 finding。第四天做反方驗證與 triage，只留下高信心問題。第五天挑一到兩個 finding 產生測試與 patch 草稿，人工審 diff，決定要合併、退回或改成長期重構。
這個版本看起來比「全 repo 掃描」慢，卻比較容易交付。跑完一週後，團隊應該知道三件事：Claude Code 對哪種程式碼最有幫助、finding 要怎麼寫工程師才願意接、以及下一輪需要補哪個測試或沙箱能力。只要這三件事變清楚，第二輪才值得擴大範圍。
來源與延伸閱讀
- Claude Blog：Using LLMs to secure source code
- Anthropic：Government of Alberta uses Claude to find and fix cybersecurity vulnerabilities
- Claude Code Docs：Overview
- Claude Code Docs：Agent SDK overview
❓ FAQ
Claude Code 可以取代 SAST 或人工 code review 嗎？
不建議這樣排。SAST 適合穩定規則與大量基礎掃描，Claude Code 適合讀上下文、整理可達路徑、補測試與產生修補草稿；人工 reviewer 則負責確認風險、業務影響與上線時機。三者放在同一條流程裡，會比互相取代更安全。
Alberta 掃 466 million lines of code 的數字可以當成評估標準嗎？
不適合直接當標準。那是 Anthropic 發布的政府案例，環境、工具、repo 結構、人力與授權都和一般團隊不同。比較值得借鏡的是它把掃描、修補、測試、工程師審查與持續安全 review 分開；掃描速度不該被拿來當採購承諾。
第一次試跑要不要讓 Claude Code 自動開 PR？
可以讓它開草稿 PR，但不要讓它自動合併。第一次試跑的重點是看 finding 品質、測試是否能跑、diff 是否容易審，以及服務任務負責人能不能接受修補方式。等幾輪都能穩定交付小 PR，再考慮把更多步驟接進 CI 或 issue triage。