.png)
為了把安全驗證從「週期性關卡」轉成「隨需可用的能力」，AWS 推出了 AWS Security Agent：主打在開發生命週期中提供可按需觸發的滲透測試與安全審查，讓團隊能更頻繁地驗證風險並獲得可行的修補建議，目前 AWS Security Agent 已在各區域上線。
一、 為什麼傳統工具不夠用了？
傳統的靜態測試（SAST）和動態測試（DAST）在弱點偵測上仍是主力，但它們多半屬於「工具視角的檢測」：各自從程式碼或執行面觀察風險，對雲端原生系統常見的「跨服務、跨權限、跨資料流」情境，容易出現三個落差。
擬與防禦驗證。
1) 風險排序困難
在微服務、API、事件驅動、複雜 IAM 與第三方整合下，真正的高風險往往不是單一點的漏洞，而是多個條件串接成可被利用的攻擊鏈（attack chain）。
傳統工具不一定能理解你的架構設計意圖、資料分類與流向、信任邊界、身分與權限模型，以及組織內部的安全基準，因此常導致：
- 告警需要大量人工判讀
- 風險優先順序難以和「業務影響/資產重要性」對齊
2) 需要大量人力判讀
即使掃描找到了可能風險，團隊仍需要回答：是否可被實際利用、利用路徑是什麼、影響範圍多大、修補方式是否符合既有架構與標準。
這部分通常仰賴資深安全人員或滲透測試來完成，成本與可擴展性是瓶頸。
3) 深度測試難以跟上交付
在高頻交付下，深度驗證若仍依賴週期性的人工作業，許多組織因時間與成本限制，人工滲透測試往往只覆蓋少數最關鍵的應用，讓其他系統在兩次測試之間承擔暴露風險。
二、 什麼是 AWS Security Agent
AWS Security Agent 是 AWS 推出的「安全前沿代理（frontier agent）」，用來在整個軟體開發生命週期中主動協助應用程式安全：它能依據你提供的設計文件、原始碼與組織的安全要求進行安全審查，並提供滲透測試來找出並回報經驗證的安全風險。
AWS Security Agent 把安全驗證嵌入三個關鍵節點：設計 → 開發 → 交付前/上線驗證。
三、AWS Security Agent 三大核心能力（Design/Code/Pentest）
1. 設計安全審查（Design Security Review）
在撰寫任何程式碼之前，團隊可以把架構圖、設計文件或技術規格交給 AWS Security Agent 進行安全審查；它會依照你們在組織層級預先定義的安全要求（例如資料存取政策、記錄/稽核標準、加密與身分驗證相關規範）來檢視設計是否存在高風險決策或政策違規，讓問題在「還沒進入實作」的階段就被看見並修正，降低後期因架構方向不符而必須大幅返工的成本。
2.程式碼安全審查 (Code Security Review)
在開發流程中，AWS Security Agent 可在開發者提交 Pull Request 時對程式碼變更進行檢視，重點不只是找出常見弱點類型（如 OWASP Top 10 常見風險），也會把「是否符合組織規範」納入判斷（例如指定的授權/驗證元件、日誌與可觀測性要求、資料處理規範等），並把修補建議直接回饋到開發者日常使用的工作流程中，讓安全審查從少數專家把關，變成可在多個團隊與多個代碼庫中一致擴展的日常機制。
3.隨需滲透測試 (On-demand Penetration Testing)
當應用已可運行（通常會在測試或預備環境）且需要做「可利用性」層級的深度驗證時，AWS Security Agent 可依你指定的目標 URL 與測試範圍（必要時包含驗證資訊與應用背景脈絡）發起多步驟攻擊情境，嘗試把風險從「可疑點」推進到「可被實際利用」的證據，並產出可重現的攻擊路徑、影響說明與對應修補方向，把原本可能需要數週排程的人工滲透測試，轉為可按需啟動、在數小時內完成的能力。
四、 AWS Security Agent 運作機制（規範定義／任務執行／開發回饋）
AWS Security Agent 的操作流程可分成「規範定義、任務執行、開發回饋」三個入口：
1) 規範定義（Governance）
由管理者在 AWS 管理控制台集中定義組織層級的安全性要求（例如加密、資料存取、記錄/稽核、允許的授權元件等），並管理 Agent Spaces，把不同團隊/專案的規範與資產邊界清楚切開，讓後續審查有一致的「判斷基準」可依循。2) 任務執行（Execution）
安全人員透過 Web 應用程式實際發起工作（設計審查、程式碼審查、隨需滲透測試）並檢視結果與證據；其中在滲透測試場景，為了貼近真實應用情境，它可以在你的環境與網路條件下對目標進行測試（包含私有環境/私有資源的需求），並可透過 AWS Secrets Manager取得測試所需的認證資料，讓驗證能涵蓋需要登入或特定權限路徑的真實流程。3) 開發回饋（Developer Feedback Loop）
在開發流程端，透過 GitHub 整合把審查意見與修復建議回到 Pull Request（PR）脈絡中，讓開發者能在既有的 code review 節點就看到風險、理解原因並採取修補動作，降低資安建議「落在工具報表、離開工程工作流」而難以落地的問題。五、AWS Security Agent 實作步驟（從建立 Agent Space 到輸出報告）
1.進入 AWS Console 搜尋「AWS Security Agent」，建立第一個 Agent Space，建議每個專案一個空間。
2. 在 Console 中啟用 AWS 管理的安全性要求，並依組織需求補上或調整自訂規範（例如加密、資料存取、記錄/稽核、允許的元件/庫等）。這一步的目的，是讓後續的設計與程式碼審查有一致的「判斷尺標」，避免結果只停留在通用建議、難以落地。
3. 在發起滲透測試前，先完成網域擁有權驗證，並確認測試目標與範圍（建議優先對測試/預備環境執行）、必要的驗證方式與測試路徑。
4. 驗證完成後即可啟動滲透測試。執行期間可透過測試日誌了解目前的探索與驗證行為，掌握測試進度、涵蓋範圍與關鍵發現，讓測試不再是「黑盒子」等待結果。
5. 測試完成後，將結果整理成報告（包含可重現的路徑/證據與修補建議），並把修補工作納入既有的缺陷管理或 PR 流程，確保「發現 → 修補 → 再驗證」能持續循環，而不是一次性專案。
總結來說，AWS Security Agent 的價值不只是新增一個掃描工具，而是把安全驗證從「少數時間點、少數系統、受排程限制」的模式，推向更可按需啟動、可重複驗證、能融入交付流程的工作方式；當你把規範先定義好、把任務執行常態化、再把結果回到開發工作流裡，就能逐步把安全測試從定期瓶頸，轉成持續驗證的一部分。
