告別盲盒開發！如何利用 AWS Kiro 代理式 IDE，打造「紅隊自動化演練系統」Prototype呢？

前言：當 AI 寫程式不再是「碰運氣」，不是 1/12..也不是 1/72，更不是 1/144 !

你是否也曾有過這種經驗：在一般的 AI 聊天視窗或 聊天型AI 裡輸入「幫我寫一個紅隊自動化測試工具」，AI 劈里啪啦生出了一堆沒頭沒尾的程式碼。一旦執行報錯，你又得重新解釋、對齊脈絡，這種盲目的開發過程，被大家戲稱為 "Vibe Coding"。

在開發安全攻防工具時，"Vibe Coding" 是非常致命的。安全演練工具只要有一點邏輯邊界沒抓好，就可能失控打掛 Production。

為了打破這個僵局，嘗試使用了 AWS 近期滿周歲的代理式 IDE 「AWS Kiro」，實作了專案 Kiro-RedTeam-Ops —— 一套專為台灣中小企業設計的紅隊自動化演練系統。透過 Kiro 的 Spec-Driven Development（規格驅動開發）、Steering Files（行為引導） 與 Agent Hooks，成功產出了 DB Repository 架構，也確保了整個工具的「合規性與安全性」。

本文將與大家分享這場「Agentic Engineering」的實戰體驗與底層架構！

一、 為什麼是 AWS Kiro呢？它如何顛覆傳統開發呢？

傳統 AI 工具是「直接寫 Code」，但 AWS Kiro 倡導的是**「先規範，再實作」**。
它具有三大核心支柱：

• Specs（規格驅動）：Kiro 不會一上來就盲目寫程式。它會要求先定義 requirements.md（需求與驗證標準）、design.md（架構與 sequence diagrams） 與 tasks.md（任務分解）。規格對齊了，才真正生成程式碼。
• Steering Files（行為引導規則）：你可以透過 Markdown 檔案，規定 Kiro「絕對不能使用哪些高風險 Library」或「寫程式時必須遵守的合規防線」。
• Agent Hooks（事件驅動自動化）：當你修改檔案或測試腳本時，Kiro 在背景觸發測試、文檔更新或靜態代碼分析。

二、 Kiro-RedTeam-Ops 的架構與 Kiro 實作路徑

在開發這套紅隊系統時，訂定的目標是設計一個高併發、能非同步處理演練結果與安全漏洞的底層 Repository 模式。

1. 用 Kiro Spec 設計 Repository 介面

在開始寫 Code 之前，利用了 Kiro 的 Spec Mode，先梳理了 IBaseRepository 的技術架構：

# src/repositories/base.py
from abc import ABC, abstractmethod
from typing import List, Optional, Dict, Any, TypeVar, Generic

T = TypeVar('T')

class IBaseRepository(ABC, Generic[T]):
    """Generic base repository interface."""
    
    @abstractmethod
    async def create(self, entity: T) -> T: 
        pass
    
    @abstractmethod
    async def get_by_id(self, entity_id: str) -> Optional[T]: 
        pass
    
    @abstractmethod
    async def update(self, entity_id: str, updates: Dict[str, Any]) -> Optional[T]: 
        pass

Kiro 在讀取這個規格時，自動指出了 Asyncio 在處理高併發紅隊演練時的邊界效應，並幫我對齊了所有 CRUD 的介面設計。  

### 2. 用 Steering Files 確保實作的安全性與強健度，為了防止 AI 生成不安全的 Query，在專案中配置了 .kiro/steering/db-conventions.md：

Markdown
# Database Steering Rules
1. Always use Motor AsyncIOMotorClient for asynchronous operations.
2. Ensure MongoDB ObjectId conversions are wrapped in try-except blocks to prevent runtime crashes.
3. Every repository must implement create_index for query optimization.

有了這層約束，Kiro 幫我生成了符合所想的 DBRepository 基底實作： 

Python
# src/repositories/mongodb_base.py
class MongoDBRepository(IBaseRepository[T], Generic[T]):
    
    def _doc_to_entity(self, doc: Dict[str, Any]) -> T:
        if doc is None: 
            return None
        if '_id' in doc:
            doc['id'] = str(doc.pop('_id')) # 確保 ObjectId 安全轉換為字串
        try:
            return self.entity_class(**doc)
        except Exception as e:
            self.logger.error(f"Failed to convert document to entity: {e}")
            raise ValidationError(f"Invalid document format: {e}") # 拋出強類型異常

Kiro 在轉換 _id 時加上了異常處理，並透過 Pydantic 實現了資料驗證，符合了我們在 Steering 裡下達的約束！


##  三、 資安與合規：用 Kiro 實現 Target Authorization 與 Risk 計算

在紅隊自動化系統中，「合規與範圍授權」和 Exercise Result 是核心業務之一。 

透過 Kiro 的引導，設計了：

### 1. TargetConfigRepository：強制儲存授權合規紀錄（IP 範圍、書面授權人與有效期限...,etc）。  

### 2. ExerciseResultRepository：動態偵測到新的 Findings 時，使用非同步重新計算全域 Risk Score。  

Python
# src/repositories/exercise_result_repository.py
class ExerciseResultRepository(MongoDBRepository[ExerciseResult]):
    
    async def add_finding(self, exercise_id: str, finding_data: Dict[str, Any]) -> Optional[ExerciseResult]:
        """新增漏洞 Findings，並立即非同步重算風險分數"""[cite: 2]
        exercise = await self.get_by_id(exercise_id)
        if not exercise: 
            return None
        
        updated_findings = exercise.findings + [finding_data]
        updates = {"findings": [f.model_dump() for f in updated_findings]}
        
        updated_exercise = await self.update(exercise_id, updates)
        if updated_exercise:
            # 觸發 CVSS 動態評估演算法
            new_risk_score = updated_exercise.calculate_risk_score()
            await self.update(exercise_id, {"risk_score": new_risk_score})

Kiro 甚至利用其 Requirements-to-spec 的能力，主動提醒我：「如果多個紅隊模組同時寫入同一個 exercise_id 的 Findings，可能會有 Race Condition。」  

這種「被 AI 代理指出架構設計缺陷」的開發體驗，非常驚艷！


##  四、 AI 時代下的思維：將安全融入 Kiro 自動化流程（Securing the Pipeline）

雖然 Kiro 幫我們高效產出了代碼，但作為 AI 時代下的一員，我們還必須在部署與 Ops 層面進行縱深防禦：

### 1. Kiro 執行權限管控：Kiro 本身支援 AWS IAM 與 SSO 整合驗證。我們在執行自動化紅隊演練時，應為 Kiro 運行的環境賦予最嚴格的「最小權限原則（Least Privilege）」，防止 Agent 因第三方漏洞利用代碼出錯而導致基礎設施受損與資訊資產損失。

### 2.審計軌跡與 KMS 加密：演練紀錄 ExerciseResult 攸關企業核心漏洞機密。 在 AWS 上部署時，除了對 DB 本身進行 TLS 傳輸加密與靜態加密外，更應將 Kiro 產出的日誌即時推送至 AWS CloudTrail，並利用 AWS KMS (Key Management Service) 對 S3 上的備份進行加密，確保日誌防篡改與機密性 !


##  五、 結語：AI 代理時代的開發新視野
專案 Kiro-RedTeam-Ops 的成功實踐，證明了 AWS Kiro 已經超越了單純的「程式碼補全助手」。它是一個能理解我們整體專案脈絡、強制執行企業架構標準、並透過 Spec 與設計文件確保開發不走偏的 Agentic Partner。如果你厭倦了在傳統 AI Chat 視窗裡不斷地複製貼上與 debug，推薦你可以試試 AWS Kiro，體驗不同的「Agentic Engineering」！


Ps: 本專案已完全開源在 GitHub：arielchangdev/Kiro-RedTeam-Ops (歡迎 Star、提交 PR，一起加入自動化紅隊與 AI Agent 的開發浪潮！)


你是否也曾遇到過 AI "Vibe coding" 的痛點呢？你認為 Spec-Driven 真的能解決這個問題嗎？
在自動化紅隊演練的工作流中，你認為「人工確認 Spec」這個關卡，是否可以完全被 AI 代理自動化取代呢？歡迎大家在留言區分享你的看法喔！