AWS Continuum 接進 Claude Code 與 Codex：讓 agent 寫的 code 邊寫邊過安全稽核（附今天就能裝的步驟）

瀏覽次數: 1

你用 Claude Code 一個下午可以改掉 30 個檔案。你的 code review 一個下午可以看幾個?

這就是 2026 年多數團隊真實的落差:產出端裝了渦輪,稽核端還是人力推車。更麻煩的是,agent 寫出來的 code 有它特有的失敗模式——它很擅長讓程式跑起來,不太擅長在意「這個 endpoint 掛在 public ALB 前面而且沒驗 JWT 簽章」。而傳統 SAST 丟回來 200 條 finding、180 條是雜訊的體驗,你我都很熟。

2026 年 8 月 5 日 Black Hat USA,AWS 宣布把 AWS Continuum 接進 Anthropic 的 Claude Code、OpenAI 的 Codex,以及自家的 Kiro。這件事有意思的地方不在「AWS 又發了個安全產品」,而在它選擇把安全層塞進兩個競爭對手的編輯器裡——賭的是掌握安全層比掌握模型更重要。

先把話講清楚,免得你白高興:Continuum 與 Claude Code / Codex 的整合,官方措辭是「coming soon」,而 Continuum for code vulnerabilities 本身還在 gated preview,要申請才給。 但這條迴圈的設計思路,今天就值得你搞懂;而且 AWS 已經有一個現在就能裝進 Claude Code 的 DevSecOps plugin,可以先把工作流跑起來。這篇分兩段講:機制,以及今天能照做的部分。

一、它從哪來:AWS Security Agent 改名進化史

這條產品線的時間軸拉出來,你會比較好判斷它現在的成熟度:

2025-12-02 — AWS 在 re:Invent 發表 AWS Security Agent preview,主打自動化安全審查與 context-aware 滲透測試,當時只有 us-east-1。
2026-03-31 — on-demand penetration testing GA,定價 $50 / task-hour,按秒計費、無最低消費;新客戶有兩個月試用,每月含最多 400 penetration testing task-hours。
2026-06-17 — AWS 的 Chet Kapoor(VP of Search, Security, and Observability)發表 AWS Continuum。原本 Security Agent 的 pen testing 與 code scanning 被收編改名為 Continuum pen testing / Continuum code scanning,再加上 Continuum threat modeling(preview)與 Continuum for code vulnerabilities(gated preview)。
2026-06-18 — AWS 的 Channy Yun(Principal Developer Advocate)發文,宣布 Security Agent 加上 Kiro power 與 Claude Code plugin,並開放任何 AI IDE 透過 MCP 接入。
2026-08-05 — Black Hat USA,宣布 Continuum 將整合進 Claude Code、Codex、Kiro。preview 設計夥伴包含 Capital One、MongoDB、Rivian、Robinhood。

這裡有個坑要注意:InfoQ 在 2026 年 7 月的報導就直接點出,社群對 Continuum 與 AWS Security Agent 的差異相當困惑,因為兩邊的能力描述高度重疊、文件也還沒完全收斂。你在搜文件時很容易搜到舊名字,別以為是兩套東西。

二、運作原理:四個階段,一條迴圈

依 AWS Security Blog 的說明,Continuum for code vulnerabilities 把一條漏洞的完整生命週期拆成四個持續進行的階段:

Discovery(盤點)

吃掉你既有工具產出的 vulnerability backlog,同時自己掃一輪環境,建出涵蓋第一方與第三方 code 的攻擊路徑地圖。重點是「ingest 既有 findings」——它不假設你要換掉現有掃描器,而是站在它們上面。

Prioritization(排序)

這是第一個真正的差異點。它不是照 CVSS 分數排,而是照你的環境排:這段 code 部署了沒?可達嗎?在 production 嗎?對外曝露嗎?打穿了業務損失多大?

AWS 的說法是 Continuum 同時 reason over 兩種資料:

結構化:AWS 內的基礎設施、IAM 權限、網路拓撲、程式碼
非結構化:組織文件、溝通紀錄、業務優先級

實務上的差別是這樣的:同一條 SQL injection,一個在只被內網 Lambda 呼叫的路徑上,一個在掛著 public ALB 的 handler 裡,傳統掃描器給你兩條一模一樣的 High;Continuum 應該給你天差地遠的排序。

Validation(驗證)

第二個差異點,也是我覺得最值得學的設計:它會在隔離 sandbox 裡真的把 exploit 打出來,產出可重現的 PoC,用「證據」而不是「推論」來判定真偽。

這個設計的價值不只在降 false positive,而在它改變了交付給 coding agent 的東西的品質。一條「這裡看起來可能有風險」的 finding,丟給 Claude Code 只會換來一段防禦性的、可能過度的改寫;一條附了可重現攻擊步驟的 finding,agent 才知道要修什麼、以及怎麼驗證修好了。

誠實標註:AWS 宣稱 sandbox 驗證能降低 false positive,但目前沒有公開任何降幅百分比或基準測試。 看到別家報導寫出具體數字,請回頭要 primary source。

Mitigation & Remediation(緩解與修補)

先給快速、可回滾的緩解(改網路規則、調權限政策),並附上 blast radius 說明;再走長效修——而長效修會進入你自己的 review 與部署流程,不是它直接推上去。

貫穿全場的兩個設計

Model-agnostic 的 agent-team loop。 AWS 的描述是「a sophisticated harness that orchestrates」:選模型、接客戶環境、交出驗證過的 code。它刻意不綁死單一模型,好在新模型出來時立刻換上。用 agent = model + harness + scaffolding 的框架看,Continuum 賣的其實是 harness 加上 context,模型是可替換零件。這也解釋了為什麼它願意接進 Claude Code 和 Codex:反正模型層本來就不是它的護城河。

Graduated trust(分級信任)。 它從 learn mode 起步,human in the loop,每個建議都攤開推理過程;你信得過之後再升級到 enforce mode,讓它自動處理更多。這個設計對導入節奏很重要——你不會第一天就把 production 的網路政策交給一個 agent 改。

接進 coding agent 之後,迴圈長這樣

你在 Claude Code / Codex / Kiro 裡發起一次 on-demand 掃描
findings 送到 Continuum
Continuum 用你 AWS 帳號的組態、IAM 政策、網路拓撲、曝險面做排序
在 sandbox 驗證哪些是真的
把已排序、已驗證的情報回傳給 coding assistant
assistant 據此調整它的建議

關鍵在第 5、6 步:這不是「掃完丟給你一份報告」,而是把安全情報餵回 agent 的 context,讓它下一輪的產出就帶著這些約束。

三、今天就能照做的部分

以下是現在可以裝、可以跑的。Continuum 那條線還在 gated preview,但 AWS Security Agent 這條線已經有官方 plugin。

3.1 Claude Code:裝 DevSecOps plugin

/plugin install aws-agents-for-devsecops@claude-plugins-official
/reload-plugins

或者從 AWS 自己的 marketplace 裝:

/plugin marketplace add aws/agent-toolkit-for-aws
/plugin install aws-agents-for-devsecops
/reload-plugins

這個 plugin 由 AWS 發布,包了兩個 agent:AWS DevOps Agent(查 log/metrics/traces、release readiness review、事故調查)與 AWS Security Agent(code security scanning、penetration testing、漏洞修補)。前置條件是設好 AWS credentials,並且會遵守你既有的 IAM 政策與 tool allowlist。

3.2 Codex:先加 marketplace

codex plugin marketplace add aws/agent-toolkit-for-aws

然後啟動 Codex,用 /plugins 瀏覽並安裝。AWS 文件的 Codex 章節示範的是裝 aws-core;DevSecOps plugin 在同一個 marketplace 裡。

Agent Toolkit for AWS 目前有四個 plugin:aws-core(服務選型、CDK/CloudFormation、serverless、容器、資料庫、儲存、可觀測性、帳務、SDK、部署)、aws-agents(用 API Gateway / Bedrock AgentCore 建 agent)、aws-data-analytics(S3 Tables、Glue、Athena)、aws-agents-for-devsecops。

3.3 Kiro 與其他 MCP agent:直接接 MCP

Kiro 不需要 plugin,直連 AWS MCP Server。編輯 ~/.kiro/settings/mcp.json:

{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.4",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata",
        "AWS_REGION=us-west-2"
      ]
    }
  }
}

存檔後重啟 client。另外裝 skills:

npx skills add aws/agent-toolkit-for-aws/skills

Kiro 這邊還有一個 Kiro power(aws-security-agent-kiro-power),背後也是 AWS Security Agent MCP server。啟用方式很土但有效:直接跟 Kiro 說「Set up AWS Security Agent」。

3.4 只想要 AWS MCP Server 本身

這是 Sébastien Stormacq 在 2026-05-06 宣布 GA 時給的 Claude Code 指令:

claude mcp add-json aws-mcp --scope user \
  '{"command":"uvx","args":["mcp-proxy-for-aws==1.6.0","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}'

Endpoint 目前有 us-east-1 與 eu-central-1(https://aws-mcp.eu-central-1.api.aws/mcp)。認證走 IAM + SigV4,proxy 負責橋接到 OAuth 2.1;後來也加了原生 OAuth 支援,可以不跑本地 proxy。它暴露四個工具:call_aws、search_documentation、read_documentation、run_script(sandbox 內跑 Python)。

注意版本號會變(文件上從 1.6.0 一路到 1.6.4),照最新官方文件抄,別照這篇抄。

3.5 Prompt 招式:別問「這段安全嗎」

裝好之後最常見的浪費,是丟一句「幫我檢查安全性」。這種 prompt 換回來的是一份泛泛的 OWASP 清單。給範圍、給判準、給產出格式:

掃描 src/api/ 底下所有 route handler。
只回報符合以下條件的問題:
(1) 資料流可從未認證的外部請求到達
(2) 你能寫出具體的重現步驟
每條輸出:檔案:行號 / 攻擊路徑一句話 / 重現步驟 / 最小修補 diff。
找不到符合的就明說「無」,不要為了湊數降低標準。

第二招,要求它先讀環境再排序——這正是 Continuum 在做的事,你可以手動逼 agent 做簡化版:

先用 call_aws 查這個服務的 API Gateway 是否 public、
對應 Lambda 的 execution role 有哪些 policy,
再依「實際可達性」重排上面 findings 的優先級,並說明你調整每一條的理由。

第三招,把規則寫進 CLAUDE.md / AGENTS.md,讓它每次都帶著跑:

## 安全約束
- 新增或修改任何 route handler 後,必須主動掃這個檔案
- 不接受「看起來可能有風險」的結論,要給重現步驟或明說不確定
- 不得自行放寬既有的 IAM policy;需要新權限時列出來問我

3.6 不等 Continuum,自己土炮同一個 pattern

Continuum 那條迴圈的核心其實只有兩件事:寫完立刻掃、掃出來的證據回灌 agent context。這兩件事你用 Claude Code hooks 就能做出便宜版。在 .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "semgrep --config auto --error --quiet $CLAUDE_FILE_PATHS || true"
          }
        ]
      }
    ]
  }
}

每次 agent 改完檔案就跑一次 semgrep,輸出回到 agent 眼前,它會自己接著修。這不是 Continuum,沒有 context graph、沒有 sandbox 驗證,但迴圈形狀是一樣的,而且今天、免費、零申請。實際欄位名稱請以 /hooks 指令顯示的當前 schema 為準。

四、數據與限制:能查到的數字只有這些

目前公開資料裡,唯一一份有具體數字的第三方驗證,是 AWS Solutions Architect Shinya Tahara 在 2026 年 4 月發表的 penetration testing 實測:

項目	結果
測試標的	私有 VPC 內 EC2 上的 Flask app,植入 5 個已知漏洞
偵測率	4 / 5(80%)
誤報	0
額外發現	1 個未預期的 Integer Overflow
漏掉	Path Traversal
抓到的	SQL Injection(CVSS 9.8)、Stored XSS(6.4)、IDOR(6.5)、JWT 驗證繞過(10.0)
耗時	約 2 小時 43 分(含約 32 分鐘 PREFLIGHT)
費用	以 $50/task-hour 計約 $136

這份數字的適用前提要講清楚: 這是 penetration testing 那條產品線的數字,不是 Continuum for code vulnerabilities 的數字,兩者別混用;標的是刻意植入漏洞的玩具 app,不代表真實 legacy codebase 的表現;而且是 2026 年 4 月的版本。

其他該誠實標註的:

沒有任何公開的 false positive 降幅數據。AWS 只說 sandbox 驗證「能減少誤報」。
Continuum for code vulnerabilities 是 gated preview,要填表申請;Claude Code / Codex / Kiro 整合是 coming soon,沒有公布日期。
AWS Security Blog 的 Continuum 發表文沒有任何量化客戶成果,只提到與金融服務、汽車、科技業客戶合作。
唯一的客戶引述來自 Rivian CISO Mike Johnson:Continuum 連接源碼與企業知識,讓團隊能準確定位漏洞並確認被標記的問題是否真的有意義——這是質性評價,不是數據。

五、什麼時候該用,什麼時候別用

適合的場景:

主力在 AWS 上。Continuum 的價值幾乎全部來自它的 context graph——IAM、網路拓撲、曝險面。這些它在 AWS 裡拿得又快又全。
backlog 已經爆炸。你有五千條 finding、沒人有空分類,「自動驗證哪些是真的」的投資報酬率最高。
有 pentest 預算但排不進人力。$50/task-hour、on-demand,對照外部顧問的排程週期,這條線是最容易算清楚帳的。
greenfield 專案。從第一行 code 開始就在迴圈裡,比事後補救便宜太多。

該慎用或別用的:

非 AWS 為主的環境。Security Agent 官方說支援 on-prem、hybrid、multicloud、SaaS,但 Continuum 的排序優勢建立在 AWS context 上;在 GCP-first 的架構裡,你付的錢買不到那份 context。
每次 commit 都跑 pentest。按 task-hour 計費,一次跑接近三小時。這東西該綁在 release gate,不是 pre-commit hook。便宜快的(lint、semgrep、依賴掃描)才適合綁每次編輯。
拿它取代 code review。它驗證的是「這個漏洞是不是真的」,不是「這段設計對不對」。business logic 的錯它抓不到,那 5 個植入漏洞裡的 Path Traversal 它也漏了。
合規門檻高的原始碼。整條迴圈意味著你的 source code、環境組態、甚至設計文件與溝通紀錄會進入 AWS 的分析管線。AWS 聲明資料不用於訓練、API 活動記錄到 CloudTrail,但這個決定該由法遵一起做。
preview 期就把流程綁死。命名還在變(Security Agent → Continuum)、能力邊界還在動、整合日期未定。現在適合建立習慣,不適合建立依賴。

六、對工程團隊的意義:這週可以做的三件事

1. 把安全檢查分成兩層,分別綁在不同時間點。 便宜的(semgrep、依賴掃描、secret 偵測)用 hook 綁 PostToolUse,agent 每改一次就跑一次,成本近乎零、回饋在 agent 還記得脈絡時就到。貴的(pentest、Continuum 這類深度驗證)綁 release gate 或每週排程。多數團隊的問題不是沒工具,是把貴的工具放在錯的頻率上。

2. 把「證據」寫進你的驗收標準。 Continuum 最值得抄的不是它的產品,是它的原則:不接受未經驗證的 finding。在你的 CLAUDE.md 裡明文寫「不接受『看起來可能有風險』,要給重現步驟或明說不確定」,你會馬上發現 agent 的安全報告品質、以及它自己的修補品質,一起上升。這條規則對付的其實是 LLM 最擅長的失敗模式——講得很有道理但沒查證。

3. 現在就去申請 preview,但別為它改流程。 Continuum for code vulnerabilities 的申請頁在 AWS Continuum 產品頁上。同時把 aws-agents-for-devsecops plugin 裝起來、跑幾次真實的 repo 掃描,累積你自己的判斷:它抓到什麼、漏了什麼、雜訊多不多。等整合真的 ship,你已經有 baseline 可以比對,而不是從零開始評估。

值得實測的點是:當 finding 帶著「已在 sandbox 驗證」的標籤回到 Claude Code 的 context 裡,agent 的修補行為到底有沒有實質變好——這是整個設計的核心賭注,也是目前沒有任何公開數據支持的一環。