AI 紅隊報告寫作
撰寫 AI 紅隊報告：執行摘要、發現範本、AI 適配風險評級、補救建議，與要避免之常見錯誤。
AI 紅隊報告寫作
報告為紅隊委任之唯一有形可交付物。技術上出色之評估配差勁撰寫之報告具零組織影響。報告必須將發現傳達予控制預算之執行層、實作修復之工程師，與追蹤風險之合規團隊——每個需不同細節層級。
受眾驅動之結構
單一報告必須服務多個受眾。結構化之使每個可提取所需：
| 受眾 | 讀取 | 需要 | 格式 |
|---|---|---|---|
| 執行層領導（CTO、CISO） | 執行摘要、風險評估 | 業務影響、投資決策 | 1-2 頁、無程式碼、美元金額 |
| 工程領導 | 摘要、發現概觀、建議 | 補救優先度、架構變更 | 3-5 頁、高層級技術 |
| 安全工程師 | 具技術細節之完整發現 | 確切 exploit 步驟、根本原因、修復驗證 | 詳細技術、程式碼、截圖 |
| 合規／法務 | 風險評估、合規映射 | 法規意涵、稽核證據 | 風險框架語言、法規參照 |
報告結構
執行摘要（1-2 頁）
委任概觀、關鍵發現摘要、整體風險評級、前 3 建議、估計補救投資。
委任細節（2-3 頁）
範圍、目標、方法論、時程、團隊組成。
發現（報告大部分）
按嚴重性或攻擊鏈組織。每個遵循配證據與重現步驟之標準範本。
攻擊敘事（3-5 頁）
端對端攻擊鏈、現實世界威脅映射、執行時間軸。
風險評估（2-3 頁）
整體態勢、業界基準、趨勢分析（為重複委任）。
建議（3-5 頁）
配快速勝利與策略改善之優先補救計畫。
附錄
詳細證據、工具輸出、完整重現步驟、方法論細節。
執行摘要
寫作原則
- 以影響為首：「客戶資料被暴露」而非「RAG 管線中之提示注入」
- 量化：美元金額、使用者計數、利用時間
- 避免術語：無「XSS」、「SSRF」或「embedding 空間碰撞」，不配平易語言解釋
- 直接：「系統處於關鍵風險」而非「評估揭示某些關切領域」
- 含正面：註記何防禦運作良好以信譽
執行摘要範本
## Engagement Overview
[Organization] engaged [Red Team] to conduct a [type] assessment
of [system] from [date] to [date], targeting [scope] with the
objective of [goal].
## Key Findings
| Severity | Count | Top Example |
|----------|-------|-------------|
| Critical | N | [1-line description] |
| High | N | [1-line description] |
## Critical Risk Summary
[2-3 sentences: most significant risk in business terms]
## Overall Risk Rating: [CRITICAL/HIGH/MEDIUM/LOW]
[1-2 sentences justification]
## Top Recommendations
1. [Action] - [impact]
2. [Action] - [impact]
3. [Action] - [impact]
## Estimated Remediation Investment
| Priority | Effort | Timeline | Cost |
|----------|----------|-----------|----------|
| Critical | X days | Immediate | $amount |
| High | X weeks | 30 days | $amount |發現文件
發現範本
每個發現遵循一致結構：
| 章節 | 內容 |
|---|---|
| 標頭 | 發現 ID、標題、嚴重性、狀態、類別、OWASP LLM Top 10 映射 |
| 摘要 | 2-3 句：什麼、攻擊者可做什麼、業務影響 |
| 技術細節 | 根本原因分析（存在之原因）、攻擊向量描述 |
| 重現步驟 | 具特定輸入之確切編號步驟 |
| 證據 | 時戳、SHA-256 雜湊之截圖與捕獲 |
| 影響分析 | 機密性、完整性、可用性 + 業務影響 |
| 受影響元件 | 具版本之元件名稱 |
| 建議 | 立即（0-7 日）、短期（7-30 日）、長期（30-90 日） |
| 參考 | 標準、CVE、內部文件 |
AI 適配之風險評級
標準CVSS不充分捕捉 AI 特定風險。以三個因素補充：
評級因素
| 因素 | 分數範圍 | 要評估什麼 |
|---|---|---|
| 可利用性 | 0-10 | 攻擊複雜度、存取要求、可重現性、自動化潛力 |
| 影響 | 0-10 | 範圍（單使用者 vs. 所有使用者）、資料敏感度、安全意涵、持久性 |
| 可偵測性 | 0-10（反轉：較高 = 較難偵測） | 記錄涵蓋、異常可見性、歸屬難度、偵測延遲 |
複合分數
Score = (Exploitability + Impact + Detectability) / 3
9.0-10.0: Critical 4.0-6.9: Medium
7.0-8.9: High 0.0-3.9: Low評級範例
| 發現 | 可利用性 | 影響 | 可偵測性 | 分數 | 評級 |
|---|---|---|---|---|---|
| 多輪越獄 | 7 | 4 | 5 | 5.3 | Medium |
| RAG 投毒 + 資料外洩 | 8 | 9 | 8 | 8.3 | High |
| 經 HuggingFace typosquat 之 Pickle RCE | 6 | 10 | 7 | 7.7 | High |
補救建議
優先化範本
| 階段 | 時程 | 發現 | 動作 | 擁有者 | 努力 |
|---|---|---|---|---|---|
| 緊急 | 本週 | AIRT-001 | 部署輸出過濾 WAF 規則 | Security Ops | 4 小時 |
| 緊急 | 本週 | AIRT-003 | 於模型載入器停用 trust_remote_code | ML Eng | 2 小時 |
| 關鍵 | 30 日 | AIRT-001 | 實作 RAG 內容掃描 | ML Platform | 5 日 |
| 關鍵 | 30 日 | AIRT-002 | 對推論伺服器端點加入身分驗證 | Infrastructure | 3 日 |
| 策略 | 90 日 | ALL | 部署 AI 特定 WAF | Security | 3 週 |
| 策略 | 90 日 | ALL | 模型來源驗證管線 | ML Platform | 2 週 |
常見報告寫作錯誤
錯誤 1：技術自戀
為給其他安全研究者留下深刻印象而非驅動組織動作而撰寫。
「我們達成新穎之多輪對抗提示注入，利用模型之脈絡內學習能力建構語意越獄，經漸進脈絡操弄規避 RLHF 訓練之拒絕邊界。」
「我們經一系列漸進轉移對話脈絡之訊息繞過 AI 安全控制。攻擊不需專門工具，可由任何使用者執行。結果為 AI 助手提供可能 [特定業務影響] 之受限資訊。」
錯誤 2：無影響之發現
「模型易受經 DAN 風格提示之越獄。」
「模型之安全控制可於約 3 訊息內被繞過，允許其生成 [特定內容]。對日服務 N 位病患之醫療保健應用，此於 [法規] 下造就責任並可導致病患傷害。」
錯誤 3：錯失攻擊鏈
- 發現 1：系統提示洩漏（中）
- 發現 2：系統提示中之 API 金鑰（高）
- 發現 3：訂單 API 缺乏授權（高）
「發現 1、2 與 3 結合形成關鍵攻擊路徑：未身分驗證使用者提取系統提示（F1），其含訂單 API 金鑰（F2），經未受保護 API 啟動對所有客戶訂單之存取（F3）。個別發現為 Medium-High，但鏈為 Critical。」
報告品質檢核表
內容品質
- 每個發現具清楚重現步驟
- 證據具時戳與完整性驗證（雜湊）
- 業務影響於每個發現陳述
- 建議特定且可行動
- 執行摘要中無技術術語
- 攻擊敘事訴說連貫故事
準確度
- 所有重現步驟於提交前重新驗證
- 嚴重性評級於發現間一致
- 範圍邊界準確記錄
- 時間軸匹配證據時戳
完整性
- 所有於範圍內系統被處理（即便無發現）
- 納入正面觀察（何運作良好）
- 環境限制記錄
- 為未來工作註記範圍外觀察
安全
- 報告於靜態與傳輸中加密
- 分發列表記錄且受限
- 報告中無實際客戶／使用者資料
- 證據檔案按 ROE 要求儲存
以下何為於紅隊報告呈現三個相關漏洞（系統提示洩漏、提示中之 API 金鑰、未身分驗證之 API）之最有效方式？
相關主題
- 完整委任 —— 產出報告之端對端委任方法論
- AI 特定威脅建模 —— 告知風險評級與發現分類之威脅模型
- CART 管線 —— 持續測試產出遵循相同報告範本之發現
- AI 應用安全 —— 於報告中頻繁記錄之應用層級發現
參考資料
- OWASP Testing Guide —— 報告結構與方法論文件
- MITRE ATLAS —— 為報告之標準化 AI 威脅分類
- NIST AI Risk Management Framework (AI RMF 1.0, 2023) —— 為 AI 發現分類之風險框架