紅隊發現 → 修復建議

如何將攻擊端發現對應到防禦建議、AI 漏洞的嚴重性評分、可執行的修復指引，以及「報告到修復」的完整流程。

找出漏洞只完成工作的一半。另一半是將這些發現轉化為防禦方能理解、排序並落實的修復。本頁涵蓋從原始發現到驗證完成的整個流程。

「發現到修復」的流程

發掘 → 分類 → 嚴重性評分 → 修復對應 → 報告 → 修復 → 驗證

每個階段都需要結構化的思考：

階段 1：分類

以一致的分類法對發現分類。OWASP Top 10 for LLM Applications 提供標準框架：

階段 2：嚴重性評分

AI 漏洞無法整齊地對應傳統 CVSS 評分。請改用調整後的框架：

綜合分數 = 加權總和，對應至嚴重性：

• 1.0–1.5：低
• 1.6–2.5：中
• 2.6–3.5：高
• 3.6–4.0：嚴重

修復對應

對每一類發現，對應至具體的防禦控管：

提示注入類發現

資料暴露類發現

代理/工具類發現

撰寫有效的修復指引

1. 1

   要具體，勿泛泛

   差：「改善輸入過濾。」好：「在 /api/chat 端點部署 Azure Prompt Shield，靈敏度設為中。此項可封鎖 Finding #3 示範的分隔符逸出手法。」

2. 2

   附上落實工作量估計

   每條建議標註估計工作量：Quick Win（小時）、Moderate（天）、Significant（週）。有助防禦方排序。

3. 3

   提供驗證條件

   對每項修復指明如何驗證生效：「部署 prompt shield 後，重跑 F3-1 至 F3-7 的測試案例，全部皆應回傳封鎖回應。」

4. 4

   分層提出建議

   提供短期緩解（本週部署過濾器）與長期修復（下一季重新設計提示架構）。

修復優先順序矩陣

當防禦方面臨 20 項以上發現時，需要排序框架：

追蹤發現直到結案

「報告到修復」流程不止於交付。追蹤的最佳實務：

1. 發現登錄冊 —— 維護發現資料庫，含狀態（open、in-progress、fixed、verified、accepted-risk）
2. 重測週期 —— 於回報修復後 2–4 週排程重測，確認修復有效且未引入退化
3. 退化監控 —— 將成功的 exploit payload 加入持續測試套件，以自動偵測退化
4. 指標 —— 追蹤各嚴重性層級的平均修復時間（MTTR），可顯示組織防禦姿態是否正在改善

延伸閱讀

• LLM 應用的縱深防禦 -- 全面修復的分層防禦策略
• 以防禦者視角思考 -- 理解防禦者優先順序以改善報告接收度
• 報告撰寫 -- 整體紅隊報告的結構設計

相關主題

• LLM 應用的縱深防禦 - 全面修復的分層防禦策略
• 以防禦者視角思考 - 理解防禦者優先順序以改善報告接收度
• 防護機制與安全層架構 - 撰寫具體修復建議所需的架構知識
• AI 威脅模型 - 為嚴重性評估提供威脅建模脈絡

參考資料

• "OWASP Top 10 for LLM Applications" - OWASP（2025）- 分類 AI 特有發現的標準漏洞分類法
• "CVSS v4.0 Specification" - FIRST（2023）- 針對 AI 漏洞嚴重性評估調整後的 CVSS
• "NIST AI Risk Management Framework (AI RMF 1.0)" - NIST（2023）- 為 AI 安全發現與修復排序的風險框架
• "Penetration Testing Report Writing Guide" - SANS Institute（2023）- 安全發現與修復指引的結構最佳實務