報告範本與範例
中級5 分鐘閱讀更新於 2026-03-13
完整的 AI 紅隊報告範本：執行摘要、技術發現、方法論章節、修復路徑圖與附註範例。
報告範本與範例
本頁提供可直接使用的 AI 紅隊報告各章節範本。每份範本皆附註，說明各段落應放什麼內容，以及應避免的常見失誤。
完整報告結構
一份完整的 AI 紅隊報告採用下列結構：
| 章節 | 頁數 | 主要對象 | 目的 |
|---|---|---|---|
| 封面 | 1 | 全體 | 委任識別、機密分級 |
| 目錄 | 1 | 全體 | 導航 |
| 執行摘要 | 1–2 | 領導階層 | 業務風險概觀、重點建議 |
| 委任細節 | 2–3 | 全體 | 範圍、方法論、時程 |
| 發現 | 10–30 | 工程師、資安 | 單一漏洞文件 |
| 攻擊敘事 | 3–5 | 技術主管 | 端到端攻擊鏈故事 |
| 風險評估 | 2–3 | 領導階層、合規 | 整體姿態評估 |
| 建議 | 3–5 | 工程、領導 | 具優先順序的修復計畫 |
| 附錄 | 不定 | 工程師 | 完整證據、重現細節 |
封面範本
# AI 紅隊評估報告
**客戶：** [組織名稱]
**目標系統：** [系統名稱與描述]
**評估期間：** [起日] -- [迄日]
**報告日期：** [日期]
**報告版本：** [1.0]
**機密分級：** [CONFIDENTIAL]
**編製者：**
[紅隊組織名稱]
[主要評估者姓名與職稱]
[聯絡資訊]
**分送對象：**
本報告機密分級為 [CONFIDENTIAL]，僅供下列指定收件人使用。
未經 [客戶安全聯絡人] 的書面授權，請勿散布。
| 收件人 | 角色 | 分送 |
|---|---|---|
| [姓名] | CISO | 主要 |
| [姓名] | 工程副總 | 副本 |
| [姓名] | 資安工程負責人 | 副本 |委任細節範本
## 委任細節
### 範圍
| 參數 | 值 |
|---|---|
| 目標系統 | [名稱、URL、版本] |
| 測試類型 | [黑箱 / 灰箱 / 白箱] |
| 範圍內 | [具體元件、端點、模型] |
| 範圍外 | [明確排除之元件] |
| 存取層級 | [未驗證 / 標準使用者 / Admin] |
### 方法論
本評估遵循 [框架名稱，例如 OWASP LLM Top 10、
NIST AI RMF] 方法論，涵蓋下列測試類別：
| 類別 | 規劃測試 | 執行測試 | 涵蓋率 |
|---|---|---|---|
| 提示注入（直接） | [N] | [N] | [%] |
| 提示注入（間接） | [N] | [N] | [%] |
| 安全/越獄繞過 | [N] | [N] | [%] |
| 資訊洩漏 | [N] | [N] | [%] |
| 工具/函式濫用 | [N] | [N] | [%] |
| 資料外洩 | [N] | [N] | [%] |
| **合計** | **[N]** | **[N]** | **[%]** |
### 時程
| 日期 | 活動 |
|---|---|
| [日期] | 委任啟動、範圍確認 |
| [日期範圍] | 偵察與初期測試 |
| [日期範圍] | 主動測試階段 |
| [日期] | 測試完成、證據整併 |
| [日期] | 草稿報告交付 |
| [日期] | 最終報告交付 |
### 團隊
| 姓名 | 角色 | 重點領域 |
|---|---|---|
| [姓名] | 委任負責人 | 整體協調、高階回報 |
| [姓名] | 資深分析師 | 提示注入、越獄測試 |
| [姓名] | 分析師 | 工具利用、資料外洩 |
### 使用工具
| 工具 | 用途 | 版本 |
|---|---|---|
| [工具名稱] | [用途] | [版本] |單一發現範本
## F[NNN]：[具描述性的標題]
| 屬性 | 值 |
|---|---|
| **嚴重性** | [嚴重 / 高 / 中 / 低] |
| **類別** | [OWASP LLM 類別或自訂分類] |
| **攻擊面** | [使用者輸入 / 系統提示 / 工具介面 / ...] |
| **可利用性** | [輕易 / 中等 / 困難] |
| **成功率** | [X/Y 次嘗試（Z%）] |
| **OWASP LLM Ref** | [LLM01 / LLM02 / ...] |
### 描述
[2–3 句：漏洞為何、業務影響為何。
以技術讀者為對象但避免不必要術語。]
### 技術細節
[漏洞機制的詳細說明。
納入相關架構脈絡。]
### 重現步驟
**環境：** [模型、版本、temperature、系統提示雜湊]
1. [步驟 1 及精確 payload]
2. [步驟 2]
3. [步驟 3]
4. 觀察：[預期結果與客觀成功判準]
**證據：** 見附錄 [X]、證據檔 [清單]。
### 影響評估
- **機密性：** [影響描述]
- **完整性：** [影響描述]
- **可用性：** [影響描述]
- **業務影響：** [具體業務後果]
- **法規：** [相關合規意涵]
### 修復
**主要建議：**
[具體技術行動，含落實指引]
**替代方案（若主要不可行）：**
[替代做法，註明取捨]
**工作量估計：** [工程時間]
**驗證：** [如何確認修復生效]
### 參考
- [相關 CVE、研究論文或公開事件]修復路徑圖範本
立即（0–2 週）
發現 行動 負責人 工作量 F001（嚴重） 部署輸出 PII 過濾 ML 工程 3 天 F003（嚴重） 縮小系統提示範圍 平台團隊 1 天 短期（2–8 週）
發現 行動 負責人 工作量 F002（高） 加入安全分類器層 ML 工程 3 週 F005（高） 實作工具呼叫驗證 後端團隊 2 週 中期（2–3 個月）
發現 行動 負責人 工作量 F004、F006（中） 重新設計提示架構 ML 工程 4 週 F007（中） 加入異常使用的監控/告警 SRE 2 週 持續
計畫 行動 負責人 週期 回歸測試 建置 CART 管線 資安 每季 模型升級測試 每次模型升級皆進行紅隊 資安 每次發版 團隊訓練 為 ML 工程師辦 AI 安全訓練 資安 每年
報告變體
不同委任類型需調整報告結構：
即上方完整範本。適用於具明確起迄日期的「某時間點」委任。
對於持續性自動化測試計畫，將敘事結構替換為儀表板式報告：
## CART 月報 - [年月]
### 主要指標
| 指標 | 本月 | 上月 | 趨勢 |
|---|---|---|---|
| 執行測試總數 | [N] | [N] | [箭頭] |
| 整體 ASR | [%] | [%] | [箭頭] |
| 新增退化 | [N] | [N] | [箭頭] |
| 平均偵測時間 | [小時] | [小時] | [箭頭] |
### 偵測到的退化
[新失敗項目的表，含根因與狀態]
### 涵蓋變動
[測試套件新增/移除之內容]
### 建議
[測試涵蓋或門檻之調整]對於由法規驅動的委任（EU AI Act、NIST AI RMF）：
## 合規對照
| 要求 | 章節 | 相關發現 | 狀態 |
|---|---|---|---|
| EU AI Act Art. 9 - 風險管理 | 4.1 | F001、F003 | 不合規 |
| NIST AI RMF MAP 1.5 | 4.2 | F002 | 部分合規 |
| ISO 42001 A.7.3 | 4.3 | 無 | 合規 |在風險評估之後加入合規對照章節。每項發現應附其對應之具體法規要求。
常見範本失誤
| 失誤 | 問題 | 修正 |
|---|---|---|
| 直接從舊報告複製 | 錯誤的客戶名、錯誤的系統細節 | 交付前使用「尋找與取代」檢核表 |
| 嚴重性評級不一致 | 折損可信度 | 依嚴重性矩陣一致地套用於所有發現 |
| 缺少重現步驟 | 發現無法驗證或修復 | 每項發現皆須具備可獨立執行之重現步驟 |
| 缺乏正向觀察 | 報告讀來像攻擊紀錄，而非改善工具 | 加入「有效控管」章節 |
| 泛泛建議 | 「改善安全」沒有行動性 | 每條建議須具體到可直接開 JIRA 票 |
相關主題
參考資料
- "PTES Reporting Guidelines" - Penetration Testing Execution Standard（2024）- 專業安全評估的報告結構與內容要求
- "OWASP Testing Guide: Reporting" - OWASP Foundation（2024）- 安全評估交付物的標準化範本與格式
- "ISO/IEC 27035: Information Security Incident Management" - International Organization for Standardization（2023）- 可用於 AI 安全發現文件的回報標準
Knowledge Check
紅隊報告中單一發現最重要的特性為何？