Claude Security 公測上線完整解析：找外包做開發的中小企業老闆該怎麼把 AI 程式碼資安納入合約與廠商評估流程

500 個。這是 Anthropic 把 Claude Security 內部跑在熱門 open-source codebases 上、短短一個 research preview 期間挖出的「前所未見」漏洞數量：很多 bug 經過了多年 expert review 仍然漏掉。如果你正在找外包做客製化系統或 AI 應用，這個數字應該讓你坐直一點：你交給廠商的那份 code，可能藏著連他們自己都不知道的洞。

2026/4/30 Anthropic 正式把 Claude Security 從 closed preview 推到 public beta，所有 Claude Enterprise 客戶立即可用，Team 與 Max plan 接下來陸續開放。它跑在 Opus 4.7 上（Anthropic 目前最強的漏洞偵測模型），用 multi-stage validation pipeline 對每個 finding 獨立驗證，並附上 confidence rating，換句話說，它直接針對「傳統 SAST 工具誤報率過高」這個老問題開刀。

對企業內有資安團隊的大公司來說，這是又多了一把武器。但對占台灣企業 98% 的中小企業老闆來說，問題不在自己會不會用，而在「我外包出去的那個系統，廠商有沒有用、要不要用、報告長什麼樣、發現 Critical 漏洞誰修、誰賠」。這篇文章從中小企業老闆採購端的角度，把 Claude Security 拆給你看：它是什麼、跟 Snyk / GitHub Advanced Security / Semgrep 差在哪、合約該怎麼寫、評估外包商要問哪 12 題、60 天怎麼導入。

Claude Security 是什麼：從 closed preview 到 public beta 的關鍵差別

先把產品定位講清楚。Claude Security 是 Anthropic 在 Claude Code 之上額外推出的一條安全產品線，定位是AI-native 程式碼安全掃描。它它跟 lint 工具或傳統 SAST（Static Application Security Testing），而是用 LLM 模擬「資深資安工程師看 PR」的判斷方式，去找出真正可被利用的漏洞。

根據 The New Stack 的報導，這次從 closed preview 進入 public beta 的最大差別有三個：第一，所有 Claude Enterprise 客戶不用再申請等候，登入即用；第二，模型底座升級為 Opus 4.7，這是 Anthropic 目前為止對漏洞偵測能力做過最多 RLHF 調校的模型；第三，開放了 GitHub Action 整合（anthropics/claude-code-security-review），這意味著任何使用 GitHub 的團隊，包含你外包出去的開發團隊，都能把它直接接進 PR 審查流程，每一個 commit 都被掃。

Closed preview 期間做出了什麼成績

2026 年 2 月起的 research preview 階段，Anthropic 把 Claude Security 跑在多個 production 等級的 open-source codebase 上。這些 codebase 已經被全球資安研究者翻過無數次。結果它仍然找出了超過 500 個先前從未被回報過的漏洞，其中包含被反覆 expert review 多年仍然漏掉的 logic bug、authentication bypass 與 race condition。

這個數字之所以驚人，是因為 open-source 等於「全世界都在 review」。如果連這些被高度檢視的專案都還能找出 500+ 個新洞，那麼一個只有 2-3 位工程師、外包 6 個月後就交付的客製化系統，洞的密度大概只會更高、不會更低。

它不只是「跑一下、看報告」

Claude Security 在使用層面提供了排程掃描、指定目錄掃描、dismiss findings、export CSV / Markdown 報告，以及 webhook 推送到 Slack 與 Jira。這套設計很明顯是為了讓開發團隊把資安掃描變成 daily workflow，而不是專案結尾才跑一次的儀式。對你這個出錢的老闆來說，這代表你可以要求外包商「每週寄一份 CSV report 給我看」，而這個要求對廠商來說技術上完全可行、沒有藉口。

它解掉了傳統 SAST 工具一直被嫌棄的兩個老問題

如果你問任何一位資深工程師對傳統 SAST 工具的印象，十之八九會聽到兩個字：「吵」和「鈍」。吵，是 false positive 太多，工程師看到第 50 個誤報後就會停止再看任何 finding；鈍，是只能用 pattern matching 抓「長得像漏洞的 code」，碰到需要理解業務邏輯的 logic bug 就抓不出來。Claude Security 直接對這兩個痛點開刀。

第一個問題：false positive 的疲勞

傳統工具的工作模式是「掃到一個可疑 pattern → 標紅 → 工程師自己判斷」。問題是，可疑 pattern 跟真實漏洞之間的差距非常大：一個用了 hard-coded string 的 SQL query 可能根本沒有被外部輸入觸達，標紅出來只是浪費時間。Claude Security 用 multi-stage validation pipeline 解這件事：每一個 candidate finding 都會經過獨立的多輪驗證（例如「這個輸入真的會走到這條路徑嗎？」「這個變數真的被使用者控制嗎？」），最後給一個 confidence rating。confidence 太低的會直接被過濾掉，不會丟到報告裡。

結果就是：工程師看到的每一個 finding，背後都已經有「為什麼這是真的可利用」的推論過程。看一份 50 個 finding 的報告，跟看一份 5 個高 confidence finding 加完整 reasoning 的報告，是兩種完全不同的體驗。

第二個問題：抓不出 logic bug

傳統 SAST 對「buffer overflow」「SQL injection」這種有明確語法 signature 的漏洞還算稱職，但對 authentication bypass、IDOR、business logic flaw 就束手無策。原因是這些漏洞沒有固定 pattern，要看懂整段業務流程才知道哪裡有破口。Claude Security 跑在 Opus 4.7 上，它可以實際讀懂 controller → service → repository 的呼叫鏈，理解「這個 endpoint 雖然有 auth check，但 check 用的是 query parameter 而不是 session user」這種真正會出事的 bug。

Cybersecurity News 的分析 指出，Claude Security 在 research preview 階段找出的 500+ 漏洞中，有相當比例屬於這類 logic bug。這正是傳統工具一直交不出來的成績。對採購方的意義是：你可以在合約裡明確區分「pattern-based 掃描」與「logic-aware 掃描」，要求廠商兩種都要跑。

跟 Snyk / GitHub Advanced Security / Semgrep 的四維度對比

在你跟外包商談「要不要用 Claude Security」之前，先把它跟市場上的主流工具放在同一張表上比一比。這四個工具的定位其實不完全重疊，了解差別才知道該不該疊著用、誰是誰的替代品。

如果你的外包專案是純前端官網或簡單表單系統，老實說 Semgrep 加上 GitHub Advanced Security 的免費部分大概就夠用。但只要這個專案碰到AI agent、LLM API 串接、自定義業務邏輯、多權限角色，Claude Security 的 logic-aware 能力就會帶來實質差距。從 DevOps.com 的分析 也能看到，目前 CrowdStrike、Palo Alto Networks、SentinelOne、Trend.ai、Wiz 都已經把 Opus 4.7 嵌入自家資安平台，這代表 Anthropic 模型本身在資安任務上的能力已經被產業共同背書。

外包做客製化系統的老闆，為什麼今天就要把這件事放上桌面

把場景具體化一下。假設你是一家做工業設備代理的中小企業老闆，去年砸了 180 萬找外包做了一套客戶服務 AI agent，掛在官網接客戶詢價、規格諮詢、報修申請。系統上線三個月後，你接到客戶電話：「我家的維修紀錄怎麼被另一家公司看到？」追下去發現是 LLM 在生成回覆時，把同一個 prompt context 的 chat history 跨 session 帶過去。這在傳統 SAST 工具的字典裡完全不存在，因為它根本這是 prompt design 跟 session 管理的洞，落在 code-level 之外。

這就是為什麼 AI 系統的資安問題不能照舊 SOP 處理。OWASP 在 2026 年更新的 LLM Top 10 把 Prompt Injection、Sensitive Information Disclosure、Excessive Agency 等列為高風險項目，這些風險在你過去找廠商做 ERP 或 CRM 系統的時代，幾乎不在資安檢核表裡。

三個你應該立刻擔心的場景

1. 「AI agent 串接公司內部 API」：你的外包系統會去呼叫庫存、訂單、客戶資料的 API，一旦 prompt 被注入惡意指令，可能整套資料被拉走。
2. 「客戶上傳檔案給 AI 解析」：合約 PDF、報價單、規格書。只要解析路徑沒有 sandbox，惡意檔案就能逃逸到主機。
3. 「外包商用 Claude / Codex 直接生 code」：這是 2026 的常態。AI 生成的 code 可能會引用過時或有漏洞的 npm 套件、把 token hardcode 在環境變數設定範例裡，掃描如果沒跟上，問題會在 production 才爆。

這三個場景的共同點是：傳統的「找一家做網站的廠商，上線前驗收功能」流程已經接不住了。你需要在合約端把 AI 程式碼資安掃描寫進去，並且要有可驗證的交付物。這也是為什麼我們在 企業 AI 廠商資安紅線指南 這篇文章裡花了很大篇幅談 prompt injection 防禦框架。那是合約之外的執行層細節，跟今天這篇合在一起看就是完整的圖。

合約裡一定要寫進去的 8 條紅線（含 SLA 與責任分擔）

接下來進入這篇文章的硬核部分。下面這 8 條紅線是中小企業外包合約諮詢經驗中，整理出的「最低標準」：少一條，事後出包都會吵到法務。每一條後面都會說明「為什麼這麼寫」和「廠商通常的反對說詞怎麼破」。

先補一個對照座標：下面這 8 條紅線，多半能在資訊安全管理系統的控制項裡找到對應。如果你也遇過客戶問「你們有沒有通過驗證」，卻不確定對方到底在問什麼，可以先讀 CNS 27001 與 ISO 27001 完整指南，再回來對照這 8 條。

紅線 1：每週至少一次完整 AI 程式碼掃描

白紙黑字寫「廠商承諾在開發期間每週一次、上線後每月一次，使用 Claude Security 或同等級工具（如 Snyk Code、GitHub Advanced Security）對整個 codebase 進行完整掃描，並提供 CSV / Markdown 格式報告予業主」。重點在「或同等級工具」：不要鎖死品牌，給廠商替代彈性，但要附「同等級」定義（支援 logic bug 偵測、有 confidence rating）。

紅線 2：Critical / High 漏洞的修補 SLA

這是最容易吵架的條款。建議寫法：「Critical 等級漏洞於發現後 48 小時內修補完成並通過複掃；High 等級於 7 個工作日內；Medium 於下一個 sprint 內；Low 列入 backlog」。理由要寫清楚：Critical 通常是可遠端利用、影響生產資料的洞，48 小時是業界共識下限。廠商如果說做不到，要請他們解釋為什麼。

紅線 3：production token 與 API key 的使用限制

明確禁止「使用 production 環境的 API key、資料庫憑證、第三方 token 進行任何 AI 工具的 context 提供」。這條是因為，當廠商用 Claude / Cursor 寫 code 時，IDE 會把 codebase context 送進 LLM；如果這個 codebase 裡 hardcode 著 production token，就等於把 token 公開了。要求廠商一律使用 staging 或 mock 環境的憑證。

紅線 4：code 留存與 AI 訓練政策

要求廠商使用的 AI 工具必須是「企業版且關閉訓練資料留存」的（如 Claude Enterprise、GitHub Copilot Business、Cursor Business），並提供書面聲明。免費版的 ChatGPT 和 Claude 預設可能會保留對話內容做模型改進，你的客戶資料就這樣外洩了。

紅線 5：所有第三方依賴的 SBOM

SBOM（Software Bill of Materials）就是「這套系統用了哪些套件、什麼版本」的清單。要求廠商在每次 release 時附上 SBOM，並用 Snyk 或同類工具掃過、附上 vulnerability report。AI 生成 code 最容易踩的坑就是引用了 deprecated 或有 CVE 的套件，SBOM 是唯一能追溯的單據。

紅線 6：原始碼與資安報告的歸屬

所有原始碼、CI/CD 設定、資安掃描報告、SBOM、修補紀錄，於專案結束時必須完整移交業主，業主擁有完整著作財產權。這條看起來理所當然，但實務上很多廠商會「不小心」把 repo 留在自己 GitHub org 底下、CI secret 也只有他們有，出事時你連去查日誌都沒辦法。

紅線 7：資安事件的通知義務與責任分擔

這條建議找律師加工。基本原則：「廠商於發現資安事件或漏洞 24 小時內必須以書面通知業主，並協助處理。若漏洞源於廠商開發的 code、且屬可預防的範圍（如未遵守上述紅線 1-5），相關修補費用、客戶通知成本、主管機關罰款由廠商承擔上限 XXX 萬」。上限金額視專案規模從 50 萬到 500 萬不等。

紅線 8：上線後 6 個月內的免費資安修補窗口

驗收後 6 個月內，凡屬於可被 Claude Security 等工具掃出的「應掃未掃」漏洞，廠商必須免費修補。這條的存在是為了防止「驗收一過就把人收走」的情況：很多事故都是上線 2-3 個月才被外部研究者掃出來，那時廠商已經結案、要再付錢才願意修。

把這 8 條塞進合約流程的決策路徑

評估外包商的 12 題檢核表：問出他們是不是真的會做

合約寫好是一回事，廠商有沒有能力做到又是另一回事。下面這 12 題是 onsite 評估或視訊會議時的提問清單，重點是看廠商的回答有沒有細節：含糊帶過的「我們很重視資安」就是紅燈。

這 12 題的真正目的，是讓你判斷「他們有沒有把 AI 程式碼資安當成 day-1 的事」，而非用來考試廠商。一個會被你問到答不出來的廠商，未來出包時你大概也問不到答案。我們在 找外包做 AI 系統的 7 個坑 裡曾經整理過另一份偏向「交付品質與專案管理」的檢核表，可以跟這 12 題一起用：一份問資安，一份問工程紀律。

60 天導入路線圖：從合約簽完到第一份報告交到你手上

如果你已經簽完合約、選好廠商，下一個問題就是「實際 60 天內要怎麼跑」。下面這張表是把 8 條紅線跟 12 題檢核轉成可執行的 timeline，你可以直接拿這個跟廠商開 kick-off 會議。

這個 60 天節奏假設你的專案規模在中小型（3-8 位工程師、6-12 個月開發週期）。如果是更大型的專案，每個階段往後拉 1.5 倍時間；如果是純 PoC 階段的小專案，可以壓縮到 30 天。重點是不要跳過任何階段，特別是 Day 36-49 的演練：大多數中小企業都是在事件發生時才第一次走通報流程，那時候已經慌到不行了。

老闆最常問的 6 個問題

把資安納入採購流程，是中小企業老闆 2026 年最值得做的一件事

AI 程式碼資安在 2026 年 4 月底之後，從「大公司的奢侈品」變成「所有用 GitHub 開發的團隊都能跑」的標準工具。對找外包做客製化系統的中小企業老闆來說，這意味著一件事：你不再有理由說「我不懂技術所以管不到資安」。合約裡的 8 條紅線、評估時的 12 題、導入時的 60 天 timeline，這三套工具加起來就是一個非工程背景的老闆也能跑得起來的最低標準。

過去幾個月有幾位老闆把這套流程跑進現有外包合約，結果都類似：廠商一開始有點反彈，但簽完之後雙方關係反而更穩定，因為規則明確的合作比模糊的合作更省力。出事的時候大家都知道誰要做什麼，而不是先吵三天責任歸屬。

如果你正在評估找外包做 AI 應用、或者手上已經有專案想加上資安條款，可以參考 恆遠的 AI 顧問服務 或 客製化開發服務，我們會根據你的場景把這 8 條紅線跟 12 題客製成適合你的版本。延伸閱讀也建議看 Anthropic 收購 Stainless 對 SDK 工具鏈與台灣中小企業的影響，理解整個 Anthropic 生態系正在如何重組，採購時就能看得更遠。

延伸閱讀：中小企業 AI agent 部署資安完整指南：1M 暴露 AI 服務、PraisonAI CVE 3 小時 44 分被攻擊事件復盤，60 天止血行動清單，把合約紅線往前延伸到「機器部署之後」，AI 服務上線後的網路暴露面、API key 洩漏與 MCP 工具權限濫用，這篇接續處理。