AWS Continuum 把修漏洞變安全建議

以前是先寫完再補救，現在是寫碼時就先把風險壓進建議裡。

我用一堆 AI 寫碼流程一陣子了，老實說，最煩的從來不是模型不會寫，是它寫得太順，順到像在幫我把雷先埋好。程式碼一段段吐出來，看起來很像樣，安全掃描卻總是在最後一刻跳出來補刀。你一邊想趕進度，一邊還要回頭猜這個修補到底會不會把別的地方弄壞。我最受不了的是，那些告警常常不是太晚，就是太吵，最後開發者只會更想忽略它。

這次我看到 AWS 的這篇文章 AWS partners with Anthropic and OpenAI to bring AWS Continuum into developer workflows，才覺得這路線有點意思。它不是在喊什麼空泛口號，而是直接把安全檢查塞回 Claude Code、Codex、Kiro 這種開發者真的會用的地方。AWS 要做的不是多一個掃描工具，是把判斷、排序、驗證、修補，往前推到寫碼當下。

真正麻煩的從來不是找漏洞，是決定哪些真的要管

「AWS Continuum for code vulnerabilities (Preview) is built to be that tool to help secure your code at machine speed.」

翻譯一下就是，AWS 不想再把重點放在「我能不能抓到問題」，而是「我能不能在機器速度下把問題處理完」。這句話很直白，也很誠實。因為現在模型越強，找出來的東西只會更多；真正拖垮團隊的，往往不是偵測本身，而是後面那串 triage、驗證、確認影響範圍、再決定要不要修。

我自己看過不少團隊栽在這裡。掃描器一口氣噴出幾十條 finding，資安同事看了皺眉，開發同事看了翻白眼，最後大家都在忙著證明「這個其實沒那麼嚴重」。問題是，沒有人想一直做這種重工。你要的是能把 finding 跟真實環境對起來的系統，不是只會列清單的機器。

AWS 這篇文章的重點很明確：漏洞不是不能找，而是找到了之後要知道它在你的 AWS 環境裡到底有多要命。這差很多。抽象世界裡的高風險，到了實際部署裡可能只是低優先；反過來，某些看起來不起眼的設定，放進你的 IAM、網路路徑、暴露面之後，反而才是真洞。

實操上我會這樣做：如果你在做內部安全助手，先別急著把 raw finding 當產品。你至少要多一層判斷，回答三件事：這個洞在現在的環境能不能打到、值不值得先修、開發者下一步該做什麼。答不出來，你做出來的只是比較會講話的掃描器。

• 先把 finding 分成「可利用」「可疑但未確認」「只是噪音」。
• 再把每條 finding 對到實際部署情境，而不是只看靜態規則。
• 最後才給開發者修補建議，別一上來就丟一堆恐嚇式訊息。

模型不是流程，AWS 這句話講得很老實

「The next challenge customers face is building the correct harness and orchestration to turn these models into a single interface that goes from detection through remediation.」

也就是說，模型本身只是零件，真正難的是外面那層 harness 和 orchestration。這我超有感。很多團隊很愛把 LLM、向量庫、幾個 API 串一串，就說自己有 AI 工作流了。結果一換模型就壞，一改權限就裂，一個工具回傳格式變了，整條鏈就像紙糊的。

AWS 這裡其實是在提醒大家：你要的是可運作的系統，不是會聊天的模型。harness 是把模型包起來的那層東西，裡面要有工具呼叫、guardrails、記憶、環境上下文、回饋迴路。少了這層，模型再聰明也只是坐在地上的引擎，跑得動但接不起來。

我之前幫人看過一套內部 AI 工具，表面上很完整，實際上每個步驟都靠不同 repo、不同腳本、不同人手動補。最麻煩的是，這些 glue code 往往沒人想認領。出事的時候大家都說那只是臨時接法，但臨時接法一旦長成正式流程，就會變成真正的系統。

實操寫法很簡單：先把你現在所有隱藏的接線找出來。誰在轉 prompt、誰在檢查 policy、誰在存 context、誰在決定要不要放行。再問一個更殘酷的問題：如果你今天把模型換掉，哪一段會立刻壞掉。答案如果散在六個 repo 和一串 Slack 訊息裡，那你沒有 harness，你只有一坨腳本。

• 模型品質決定你能不能抓到問題。
• 流程品質決定你能不能穩定處理問題。
• 工作流品質決定開發者會不會真的用。

Continuum 本質上是一個有分工的 agent loop

「Under the hood, Continuum is an agent-team loop architecture.」

這句話很重要，因為它把這東西從「單一 AI 助手」拉回比較像團隊作業的結構。它不是只丟一個掃描器給你，也不是叫一個 bot 自己猜答案。它是讓不同角色各做各的：有人找問題、有人排序、有人驗證、有人把修補建議送回開發流程。

白話一點，就是 AWS 想把原本跨工具、跨人、跨 ticket 的工作，壓成一條連續迴路。你寫碼，系統掃描；系統把 finding 對到你的 AWS 環境；系統驗證這個洞到底有沒有影響；最後再把結果回灌到 coding assistant，讓它下一次不要再亂提同一條路。

我以前手動湊過類似流程，真的很煩。掃描工具說有問題，另一個工具說可能沒事，資安同事要你補證據，開發同事只想知道到底要不要改。這種時候如果沒有 loop，最後就是人腦在當整合層。你以為自己在寫 code，其實你在幫工具翻譯工具。

實操上，我會建議你把自己的安全自動化拆成四步：偵測、脈絡化、驗證、建議。少一個都別急著說自己是端到端。如果你只能做到偵測，那就誠實叫它掃描器；如果你做到最後一步，才有資格說它真的在幫開發者做事。

把安全放進 Claude Code、Codex、Kiro 才是真的有用

「Within Claude Code, Codex, and Kiro coding environments, on-demand vulnerability scans identify potential issues and send findings to Continuum.」

這段我覺得最實際。AWS 沒有叫開發者離開編輯器去看另一個儀表板，也沒有再發明一個新的資安後台。它是直接把安全檢查塞進開發者本來就在用的環境裡。這種做法很土，但土得對。因為只要多跳一次頁面，很多人就懶了；只要多一個工具在旁邊吵，大家就會想先把它關掉。

這裡的流程大概是這樣：開發者在 Claude Code、Codex 或 Kiro 裡寫程式；按需觸發漏洞掃描；Continuum 把 finding 接過去，對照客戶的 AWS 環境；再把結果回送到 assistant，讓 assistant 接下來的建議不會繼續往危險方向走。這比「寫完再丟 CI，等資安開 ticket」順太多了。

我不是說 CI 掃描沒用，當然有用。但如果 assistant 在生成階段就知道某條路很危險，它根本不該一開始就把那條路端出來。少走一個死路，後面就少一堆返工。這種省時，不是省一點，是整個流程的摩擦都少一圈。

實操寫法：如果你要把安全放進開發工具，不要做成「存檔後跳警告」。你要讓 assistant 在生成當下就看見環境限制。越早知道 IAM、網路、暴露面有什麼限制，越少會產生那種看起來很聰明、其實根本不能上線的建議。

• Claude Code 適合讓建議在互動中即時修正。
• Codex 適合把生成與安全回饋放在同一個迴圈。
• Kiro 適合把驗證過的建議直接回到工作流裡。

真正值錢的是環境脈絡，不是告警本身

「Continuum prioritizes them within the context of the customer’s AWS environment (configurations, AWS Identity and Access Management (IAM) policies, network topology, and exposure surfaces) and validates them in a sandbox.」

這句我很買單，因為它終於把「環境脈絡」講清楚了。漏洞本身只是一個抽象事件，放進你的 AWS 環境才會變成真正的風險。IAM 權限很窄、網路路徑很封閉、暴露面根本碰不到，風險等級就會完全不一樣。很多 scanner 的問題，就是它只會看洞，不會看洞外面那層現實。

我看過太多團隊不是過度反應，就是完全不理。過度反應通常是因為工具沒脈絡，看到關鍵字就嚇到；完全不理則是因為工具說不出影響，久了大家只當它在吵。AWS 這裡想做的，是把脈絡變成預設輸入，而不是事後補的資料欄位。

sandbox 驗證也很重要。它代表系統不是只靠信心分數在唬人，而是先在受控環境裡確認這條 finding 的行為，再把修補建議推回去。這會大幅降低誤報和亂修。對開發者來說，最討厭的不是被提醒，而是被提醒之後還要自己證明提醒是錯的。

實操上，我會要求你的安全自動化至少接到這些資料：IAM、網路路徑、部署設定、服務暴露面。沒有這些，你的工具就只能猜。還有，sandbox 不要省。很多團隊都說之後再驗證，結果之後永遠不來。你如果想讓開發者信任安全建議，就得先拿出證據，不是丟一個漂亮的分數。

AWS 其實是在賣少一堆交接

「This collapses what was traditionally a multi-step, multi-team process (write, scan, triage, prioritize, fix, rescan) into a single outcome: the code suggestion itself.」

這句話很直白，也很誠實。現在的安全流程本來就一堆交接：寫完、掃描、分類、排序、修補、再掃一次。每一次交接都會掉 context，每掉一次，開發者就更不想管。最後不是沒修，而是修得很慢，慢到大家都忘了為什麼要修。

AWS 真正在推的，是把摩擦提早到作者還在線上的時候。assistant 如果知道某條路很危險，就不要再推那條路；如果某個修補已經驗證過，就直接給開發者一個能接受的版本。這樣做不是讓資安消失，而是讓資安不必等到事情變爛才出現。

我看原文時有注意到一點：AWS 提到早期設計夥伴已經有成果，但我看到的段落在引述處就截掉了，所以我不會亂補數字或亂接後半句。這種事我寧可老實一點。重點不是那句沒補完的讚美，而是方向很清楚——assistant 本身要變成安全決策發生的地方。

實操寫法：把你的流程拿來數交接次數。每一條 finding 從出現到真的被處理，中間經過幾個工具、幾個人、幾次切換。然後想辦法砍掉一半。只要你能把驗證和修補建議拉近到作者那一步，速度會快很多，垃圾 finding 也會少很多。

可抄的模板

# AI 寫碼安全工作流模板

這個模板適合你想把安全檢查塞回開發助手，而不是另外養一套吵人的掃描平台。

## 流程

1. 開發者在 AI 助手環境中寫碼。
2. 對目前草稿觸發一次按需漏洞掃描。
3. 把 finding 送進安全協調層。
4. 對每條 finding 補上環境脈絡：
   - IAM 權限
   - 網路路徑
   - 部署設定
   - 暴露面
5. 在 sandbox 裡驗證這條 finding 是否真的成立。
6. 回傳三種結果給 coding assistant：
   - 可以繼續
   - 需要修補
   - 需要人工確認
7. 讓 assistant 根據結果調整下一輪建議。

## 判斷規則

- 如果在目前環境裡根本打不到，就降級優先順序。
- 如果可以打到，而且已經驗證成立，就立刻給修補建議。
- 如果驗證不清楚，就不要自動修，直接要求人工確認。
- 如果同一類問題一直重複出現，把它當工作流缺陷，不只是程式缺陷。

## 給 assistant 的提示詞

你正在為正式的 AWS 生產環境產生程式碼。
在提出任何做法前，先檢查：
- 這個動作是否需要更高權限的 IAM
- 這個動作是否增加網路暴露
- 這個動作是否引入已知漏洞模式
- 有沒有更安全的替代方案

如果危險路徑其實不必要，先提更安全的方案。
如果有可用修補，請用一句話說清楚代價。

## 輸出格式

每個問題回傳：
- finding_id
- severity
- environment_context
- validation_status
- recommended_fix
- developer_action

## 基本護欄

- 不要把原始掃描結果當成最終真相。
- 不要把脈絡藏起來不給開發者看。
- 沒驗證前，不要自動套用修補。
- 就算語法正確，也不要推薦違反政策的程式碼。

## 最小實作清單

- [ ] 把 assistant 輸出接到掃描結果
- [ ] 加上環境脈絡補強
- [ ] 加上 sandbox 驗證
- [ ] 把驗證結果回灌給 assistant
- [ ] 記錄每一次交接
- [ ] 每週檢查誤報

我會先從這個模板開始，就算你現在不用 AWS Continuum 也沒差。真正有用的是這個形狀：偵測、補脈絡、驗證、再建議。這才是我想放進任何 AI 寫碼工具裡的流程。

如果你要自己做一套，記得要有立場一點。開發者不需要另一個什麼都會講一點、最後什麼都不負責的 AI 外殼。真正有用的是知道什麼時候該閉嘴、什麼時候該提醒、什麼時候該直接給可修的版本。

原始來源是 AWS Security Blog 這篇 AWS partners with Anthropic and OpenAI to bring AWS Continuum into developer workflows，另外也參考了 Claude Code、OpenAI Codex、Kiro 的官方頁面。上面這篇拆解裡，產品敘述與引文來自原文，我的判讀、脈絡整理和模板是我自己整理出來的。