AI Penetration Testing Report Writing

Comprehensive guide to writing effective penetration testing reports for AI system assessments.

概覽

滲透測試報告是任何安全評估的主要交付成果。對於人工智慧系統評估，報告撰寫提出了傳統滲透測試報告指南無法解決的獨特挑戰。人工智慧漏洞通常是機率性的（在一定比例的時間內工作，而不是確定性的）、上下文相關的（需要特定的對話歷史或系統狀態），並且難以使用現有的漏洞分類方案進行分類。調查結果可能涉及產生的有害或冒犯性內容，從而引發關於證據中包含哪些內容的問題。 許多利害關係人缺乏背景知識來理解為什麼提示詞注入或安全旁路對他們的組織很重要。 本文提供了編寫人工智慧滲透測試報告的詳細指南，這些報告在技術上嚴謹、清晰地傳達風險並推動補救行動。我們涵蓋報告結構、查找文件標準、人工智慧特定漏洞的嚴重性分類、證據處理以及破壞報告有效性的常見陷阱。

報告結構

總體組織

有效的人工智慧滲透測試報告遵循分層結構，允許不同的受眾在不閱讀整個文件的情況下提取他們需要的資訊。 封面和文件控制：標題、客戶名稱、評估日期、報告版本、分類等級和分發限制。 AI滲透測試報告中可能包含有害內容的範例，因此分類尤其重要。 目錄：對於通常超過 30 頁的報告至關重要。 執行摘要（1-3 頁）：為非技術領導所編寫。描述評估範圍、整體風險程度、以業務術語總結的主要發現以及策略建議。本節對於沒有技術背景的人來說應該是可以理解的。避免行話。使用諸如「人工智慧系統可以被操縱來洩露客戶資料」之類的術語，而不是「目標很容易透過 RAG 文件投毒來間接提示詞注入，從而導致 PII 滲漏」。 評估概述（2-3 頁）：描述測試的內容、測試方式以及任何約束或限制。包括範圍邊界、測試方法、使用的工具、時間表以及測試期間遇到的任何問題。對於 AI 評估，請明確說明測試的模型版本，因為結果可能不會在模型更新後持續存在。 結果摘要（1-2 頁）：表格或視覺化摘要會依嚴重性、類別和狀態顯示所有結果。這讓讀者在深入細節之前可以快速概覽。包括發現的嚴重性分佈圖和漏洞類別的細分（提示詞注入、安全繞過、資料外洩等）。 詳細調查結果（長度可變）：報告的核心。每個發現都有自己的部分，其結構一致，如下所述。 策略建議（2-3 頁）：超越個人發現補救措施的更高層級建議。這些解決了系統性問題、架構改進和流程變更，從而整體改善組織的人工智慧安全狀況。 附錄：完整的測試日誌、方法細節、工具配置和補充證據。

尋找文檔模板

每個發現都應遵循一致的模板。一致性使調查結果更容易透過補救進行審查、比較和追蹤。 尋找標題：清晰、具體且具描述性。 「直接提示詞注入繞過客戶支援聊天機器人中的內容政策」比「提示詞注入漏洞」更好。標題應該傳達漏洞是什麼以及它存在的位置。 尋找 ID：用於追蹤的唯一識別碼（例如 AI-2026-001）。跨業務使用一致的編號方案以促進交叉引用。 嚴重性評級：使用定義的嚴重性等級。我們建議採用四級量表（嚴重、高、中、低），並輔以適用於 AI 系統的類似 CVSS 的評分方法（在下面的嚴重性分類部分中討論）。 漏洞類別：對應到已建立的分類法。使用 MITRE ATLAS 技術 ID（例如，LLM 提示詞注入的 AML.T0051）、OWASP LLM Top 10 識別碼（例如，LLM01：提示詞注入）和 CWE 識別碼（如果適用）。多種分類是合適的，可以幫助使用不同框架的客戶。 描述：對漏洞的清晰解釋，為可能不熟悉特定於 AI 的攻擊技術的技術受眾編寫。包含足夠的背景信息，以便不熟悉特定攻擊類別的人能夠理解其機制和風險。避免假設讀者知道提示詞注入、越獄或模型提取是什麼——在第一次使用時定義這些術語或提供解釋連結。 證據：人工智慧研究結果最關鍵的部分。记录完整的交互序列，包括：

• 使用的確切提示或輸入
• 系統的完整回复
• 時間戳記和會話標識符（如果可用）
• 模型版本或系統版本
• 嘗試次數和成功率
• 用於互動式測試的螢幕截圖或螢幕錄製
• 用於程式化測試的 API 請求/回應日誌 對於人工智慧的發現來說，背景非常重要。單一提示/回應對通常是不夠的——記錄導致漏洞的完整對話序列，因為許多人工智慧漏洞需要特定的對話上下文才能觸發。 影響評估：描述漏洞的具體業務影響。攻擊者可以實現什麼目標？哪些數據有風險？哪些決定可能被操縱？盡可能量化：「攻擊者可以透過重複提示詞注入以每小時大約 50 個的速度提取客戶電子郵件地址」比「攻擊者可以提取一些客戶資料」更具可操作性。 重現步驟：編號的逐步說明，允許不熟悉測試的人重現發現結果。對於人工智慧發現，包括完整的對話序列、任何所需的系統配置或狀態，以及預期行為與觀察到的行為。 補救建議：具體的、可操作的補救步驟。盡可能提供多種選項，從快速緩解措施到全面修復。 對每個選項，請注意預期的效果、實際工作量以及任何限制。 參考文獻：相關 MITRE ATLAS 條目、OWASP 指南、學術論文或供應商文件的鏈接，為發現提供更多背景資訊。

AI 漏洞的嚴重性分類

AI 嚴重性評級的挑戰

傳統的漏洞嚴重性框架（例如 CVSS）是為確定性軟體漏洞而設計的。 AI 漏洞帶來分類挑戰： 機率利用：在 30% 的時間內有效的提示詞填充仍然是一個真正的漏洞，但其嚴重性與在 95% 的時間內有效的提示詞注入相比如何？傳統框架沒有本質上利用機率的概念。 上下文相關的影響：相同的漏洞（例如，安全過濾器繞過）根據系統的上下文而具有完全不同的嚴重性。繞過內部程式碼審查工具上的內容過濾與繞過面向公眾的兒童教育聊天機器人的風險不同。 主觀內容傷害：一些人工智慧發現涉及有害內容的生成。評估安全繞過的嚴重性需要對內容危害做出判斷，這本質上比評估緩衝區溢位的嚴重性更主觀。 代理式系統中的級聯效應：代理式系統中的次要提示詞注入可能會透過工具呼叫級聯產生重大影響。最初的漏洞可能看起來很小，但透過代理的功能可利用的影響可能至關重要。

推薦的嚴重性框架

我們建議使用一個嚴重性框架來評估三個維度並將它們組合成最終評級： 維度 1 — 可利用性（1-4 級）：

• 4：任何沒有專業知識的使用者都可以輕鬆利用
• 3：可利用人工智慧系統的基本知識或已發布的攻擊技術
• 2：需要專業知識、客製化工具或擴展交互
• 1：需要深厚的專業知識、大量資源或特定的先決條件 維度 2 — 影響（1-4 級）：
• 4：未經授權存取敏感數據，未經授權的行為會造成重大後果，完全安全繞過可產生危險內容
• 3：有限的資料暴露、部分安全繞過、影響使用者的人工智慧決策的操縱
• 2：系統配置資訊外洩、安全執行不一致、AI輸出品質下降
• 1：輕微資訊外洩、表面問題、理論風險，實際利用路徑有限 維度 3 — 範圍（1-3 級）：
• 3：影響架構層級的所有使用者或系統
• 2：影響使用者或使用案例的重要子集
• 1：僅影響攻擊使用者的會話 最終嚴重性：
• 嚴重：可利用性 3-4，影響力 4，任何範圍
• 高：可利用性 3-4，影響力 3，或可利用性 2+，影響力 4，範圍 2+
• 中：可利用性 2+，影響力 2+，或較低的組合與高範圍
• 低：可利用性 1-2，影響 1-2，範圍 1 該框架是一個起點。根據客戶的具體情況、監管環境和風險偏好調整嚴重程度。始終記錄嚴重性評級背後的推理，以便客戶可以做出自己的判斷。

處理機率發現

對於成功率可變的發現，請在顯著位置記錄成功率，並在嚴重性評估中解決它： 「此提示詞注入在 20 次嘗試中，有 7 次成功繞過了內容過濾器（成功率 35%）。雖然不確定，但這個成功率足以讓有動機的攻擊者通過重複嘗試獲得一致的結果。按照此成功率，攻擊者預計平均會在 3-4 次嘗試內成功繞過。」 提供背景說明為什麼機率發現仍然很重要。許多利害關係人認為，如果攻擊並非每次都有效，那麼它就不是真正的漏洞。幫助他們理解，可以進行無限嘗試的攻擊者（對於可訪問 API 的 AI 系統來說這是典型的情況）最終會成功，並且 35% 的成功率意味著自動測試幾秒鐘內就會成功。

證據處理

證據中的敏感內容

AI紅隊演練不可避免地會產生包含敏感內容的證據：提取的PII、生成的有害材料、繞過安全過濾器的輸出以及系統配置詳細資訊。小心處理這些證據。 編輯標準：在將證據螢幕截圖和日誌中的真實 PII 包含在報告中之前對其進行編輯。將實際姓名、電子郵件地址和其他識別碼替換為明確的佔位符，例如 [REDACTED-EMAIL-1]。密文應該是一致的（相同的密文項目始終使用相同的佔位符）但徹底。 有害內容處理：在記錄安全繞過結果時，請包含足夠的證據來證明漏洞，但不要包含無端有害的內容。證明系統可以為危險活動產生指令的發現不需要包括完整的指令 - 一個帶有註釋的截斷示例，如“[響應繼續詳細說明 - 為報告而截斷]”就足以證實該發現。 內容警告：如果報告必然包含令人不安或令人反感的內容作為證據，請在相關部分的開頭添加內容警告。 對於報告審閱者來說，這既是一種職業禮貌，也是一種實際考量。 安全傳輸：透過安全管道（加密電子郵件、安全文件共享平台或手動交付以進行高度敏感的評估）交付報告。 AI滲透測試報告通常將傳統滲透測試報告（系統漏洞）的敏感度與AI評估特有的其他敏感內容類別結合。

證據完整性

證據不完整是調查結果受到爭議或被忽視的最常見原因。對於每一個發現： 證明它是真實的：包括足夠的證據，證明測試期間不在場的人可以驗證發現是真實的，而不是捏造或誤解的。 證明它是可重現的：提供足夠精確的步驟，以便客戶的團隊可以在自己的測試環境中重現結果。 證明它很重要：將技術發現與具體的業務影響聯繫起來。 「系統可以忽略其安全準則」是一個技術聲明。 「攻擊者可能會導致面向客戶的聊天機器人推薦危險的藥物劑量資訊」是一種將推動補救措施的業務影響。

為不同的受眾寫作

技術觀眾

客戶的開發和安全工程師需要足夠的細節來理解漏洞機制，重現發現結果，並實施有效的修復。 準確說明機制：準確解釋攻擊的工作原理。對於提示詞注入，包括具體的技術（角色扮演升級、基於編碼的旁路、指令層次結構操作等），並解釋為什麼它在當前的實踐中取得了成功。 提供正確等級的補救措施：不要只說「實行輸入驗證」。指定驗證內容：「實施一個基於 LLM 的輔助分類器，在將使用者輸入傳遞給主模型之前評估注入嘗試的使用者輸入。分類器應該是一個單獨的模型實例，擁有自己的系統提示詞，僅專注於識別對抗性輸入。請參考 OWASP LLM Top 10 關於實作模式提示詞注入預防的指南。」 參考正確的標準：技術受眾受益於 MITRE ATLAS 技術 ID、CWE 識別碼以及相關學術論文或工具文件的連結。

行政觀眾

對於永遠不會閱讀技術細節的讀者來說，執行摘要必須獨立作為一個連貫的文檔。 以業務風險為主導：“評估發現了三個關鍵漏洞，這些漏洞可能允許外部攻擊者操縱人工智慧系統洩露客戶財務數據。基於系統約 50,000 名活躍用戶的用戶群，潛在的暴露包括姓名、帳號和交易歷史記錄。” 盡可能量化：使用數字來傳達規模。以嚴重程度劃分的漏洞數量、估計暴露量、與行業基準的比較（如果有）。 提供明確的優先事項：“我們建議在擴大系統的用戶群之前立即修復三個關鍵問題。這些問題的修復工作預計需要 2-3 週的工程時間。” 避免行話：如果必須使用技術術語，請在括號中定義。 “系統容易受到提示詞注入（攻擊者製作特殊輸入來覆蓋系統指令的技術）的攻擊。”

董事會與監管觀眾

為董事會或監管審查所準備的報告或摘要需要額外考慮： 風險框架：將調查結果映射到組織使用的風險框架（NIST AI RMF、ISO 42001、歐盟人工智慧法案要求）。明確說明所發現的漏洞是否代表合規性差距。 趨勢背景：在可能的情況下，將發現的結果置於更廣泛的威脅環境中。 「這種類型的即時注入漏洞被列為 OWASP 法學碩士申請前 10 名中最嚴重的風險類別，並且已在整個行業的類似系統中得到識別。” 成熟度評估：相對於產業預期，對組織的人工智慧安全成熟度進行整體評估。這不僅有助於董事會了解具體的調查結果，還有助於了解組織的整體準備。

常見的報告寫作陷阱

損害可信度的陷阱

過度分類嚴重性：將每個發現評為「嚴重」或「高」會破壞嚴重性評級的可信度，並使優先順序變得不可能。始終如一地應用嚴重程度，不要害怕中和低評級。如果客戶擁有一個安全良好的系統，那麼一份主要包含中等發現和良好架構建議的報告比誇大嚴重性以顯得更有影響力的報告更有價值。 一般建議：「實踐更好的輸入驗證」是不可行的。每項建議都應該足夠具體，以便工程師可以僅根據報告開始實際工作。如果適用，請參考特定的工具、函式庫、模式或框架。 對於不熟悉人工智慧的讀者來說，缺少上下文：許多報告讀者將第一次遇到人工智慧安全漏洞。不要假設熟悉提示詞注入、符元限制、溫度設定或 RLHF 等概念。提供足夠的背景信息，使讀者無需外部研究即可理解研究結果。 術語不一致：在方法部分定義術語並一致使用。請勿互換使用「提示詞填滿」、「提示操作」和「輸入覆蓋」。選擇一個術語（最好是 OWASP 或 MITRE 標準術語）並在全文中使用它。

削弱可操作性的陷阱

沒有重現步驟的結果：如果客戶無法重現結果，則無法驗證補救措施。每項發現都必須包括完整的、經過測試的再現步驟。 沒有優先順序的修復：在沒有明確優先順序的情況下呈現 30 項發現結果會讓開發團隊不知所措。按系統組件或修復主題對結果進行分組，並提供優先修復路線圖，以說明修復之間的依賴關係。 缺少根本原因分析：一份報告識別了 10 個提示詞注入實例，但沒有指出它們都有一個共同的根本原因（例如，缺少二級分類層），因此錯過了推薦解決所有 10 個發現的單一架構修復方案的機會。尋找模式並解決根本原因，而不僅僅是症狀。 忽略約束的建議：建議客戶在使用第三方 API 模型時“使用對抗性範例重新訓練模型”，這表明對其約束存在誤解。根據客戶的實際能力量身訂做建議。

報告審核和品質保證

內部審查流程

每份報告在交付前都應至少經過一次同儕審查。 技術審查：同行從業者審查研究結果的準確性、完整性和可重複性。他們應該嘗試使用記錄的步驟重現關鍵發現。 編輯評審：審查者專注於清晰度、一致性和受眾適宜性。檢查執行摘要是否真正可供非技術讀者理解，術語是否一致，以及報告從頭到尾閱讀是否連貫。 合規性審查：對於監管背景下的合作，請驗證報告是否滿足相關合規性要求並使用適當的框架語言。

交付前檢查清單

在提交任何 AI 滲透測試報告之前，請先驗證：

• 所有發現重現步驟均已測試
• PII 和敏感資料經過適當編輯
• 有害內容被最小化到證據所需的程度
• 嚴重性評等一致且合理
• 執行摘要獨立且無行話
• 模型/系統版本已記錄
• 記錄機率結果的成功率
• 所有引用的工具和框架都包含版本訊息
• 報告分類等級適當
• 交付方式滿足客戶的安全要求

範本和範例

尋找範例

以下是一個有據可查的人工智慧發現的濃縮範例： 查找 ID：AI-2026-003 標題：透過 RAG 知識庫間接提示詞注入實現客戶資料擷取 嚴重性：嚴重（可利用性：4，影響：4，範圍：3） 類別: MITRE ATLAS AML.T0051.001 (LLM 提示詞注入 — 間接), OWASP LLM01 (提示詞注入) 描述：客戶支援聊天機器人使用 RAG 從內部知識庫檢索上下文。 可以為知識庫添加內容的攻擊者（例如，透過提供知識庫的可公開存取的回饋表）可以嵌入指令，使聊天機器人從其他使用者的對話中提取和揭露資訊。 系統不會清理檢索到的知識庫內容或將其與模型上下文視窗中的系統指令區分開來。 影響：攻擊者可以從其他使用者的對話中系統地提取客戶名稱、帳戶詳細資訊和支援歷史記錄。鑑於系統每天處理約 10,000 個支援對話，潛在的風險是巨大的。這可能違反了 GDPR 第 5(1)(f) 條有關資料處理完整性和保密性的規定。 成功率：20 次嘗試中有 17 次 (85%) 成功從模擬客戶對話中提取資訊。 補救建議：

1. 在插入模型上下文之前，（立即）對所有檢索到的知識庫文件進行內容清理 2.（短期）部署二級分類模型來偵測知識庫內容中的注入嘗試 3.（中期）在知識庫檢索和使用者對話情境之間實現具有明確信任邊界的架構分離

參考文獻

• MITRE ATLAS（人工智慧系統的對抗性威脅格局）。 https://atlas.mitre.org/ — AI 系統發現的漏洞分類分類法。
• OWASP 法學碩士申請前 10 名，2025 年版。 https://owasp.org/www-project-top-10-for-large-language-model-applications/ — LLM申請漏洞的風險分類架構。
• NIST AI 風險管理架構 (AI RMF 1.0)，2023 年 1 月。 https://www.nist.gov/artificial-intelligence/ai-risk-management-framework — 用於將 AI 風險發現背景化的框架。
• 常見弱點枚舉（CWE）。 https://cwe.mitre.org/ — 用於補充特定於 AI 的分類法的軟體弱點分類。