倫理與負責任揭露
AI 紅隊的倫理框架、AI 漏洞的負責任揭露流程、何時與如何回報發現，以及處理漏洞賞金計畫。
法律合規設下可接受行為的底線；倫理則設下上限。AI 紅隊中許多技術上合法的活動，倫理上仍可能有疑慮。AI 資安研究的職業倫理需對傷害、比例性與社會影響進行主動考量。
AI 紅隊的倫理框架
比例性原則
每一項測試都應權衡所調查漏洞的嚴重性與測試本身可能造成的傷害。
| 測試影響 | 可正當化之時 | 不可正當化之時 |
|---|---|---|
| 產生有害文字輸出 | 測試安全過濾之有效性 | 為散布而產生內容 |
| 自訓練資料擷取 PII | 經客戶同意評估記憶風險 | 為其他目的蒐集 PII |
| 造成模型退化 | 以客戶核可之 DoS 測試檢視韌性 | 對服務使用者之生產系統造成退化 |
| 繞過內容過濾 | 於授權委任中評估過濾穩健性 | 繞過你無授權測試系統的過濾 |
| 揭露系統提示 | 於範疇內評估提示安全 | 自競爭對手系統擷取提示 |
雙重用途困境
AI 紅隊研究本質上是雙重用途：同樣技術既助防禦亦助攻擊。發表與分享發現的倫理考量：
評估攻防平衡
發表此技術對防禦者幫助大、還是對攻擊者幫助大？若該漏洞已被野外利用，揭露可加速防禦。若為新穎技術，可考量協調揭露。
評估可重現性
能力較差的攻擊者要複製此發現有多難？若該技術需相當專業或資源，發表風險較低。若提供複製貼上即可的攻擊，請考慮限縮細節。
考量受影響族群
多少系統與使用者受影響？單一部署中的漏洞，與影響某廣用模型所有實例的漏洞不同。
採分階段揭露
先分享漏洞類別與緩解指引，待修補可用後再提供完整技術細節。
AI 漏洞的負責任揭露
AI 漏洞與傳統軟體漏洞有幾項重要差異，影響揭露流程。
AI 漏洞與傳統漏洞的差異
| 面向 | 傳統軟體 | AI 系統 |
|---|---|---|
| 修補時程 | 數週至數月 | 可能需重訓模型（數月）或架構變動 |
| 影響範疇 | 特定軟體版本 | 同模型所有部署 |
| 可遷移性 | 限於同軟體 | 可能跨模型與供應商 |
| 驗證 | 確定性重現 | 機率性——可能無法穩定重現 |
| 嚴重性評估 | CVSS 已成熟 | 尚無廣泛採用的 AI 漏洞評分 |
揭露流程
記錄漏洞
記錄確切條件、輸入、輸出與重現步驟。記下成功率（AI 漏洞常為機率性）與任何模型特定條件。
辨識揭露收件人
判定誰該收到此報告：模型供應商、應用部署方，或兩者。若漏洞位於底層模型，即便你由部署方委任，仍必須通知模型供應商。
初次接洽
使用供應商之資安回報通道（security@、漏洞賞金平台或專職的 AI 安全回報）。若無通道，以一般管道聯繫資安團隊。對敏感細節加密。
設定揭露時程
傳統漏洞慣例為 90 天。需重訓模型之 AI 漏洞 120–180 天可能更合適。與廠商議定時程。
協調公開揭露
可能的話與廠商合作發布聯合公告。先分享緩解指引、後分享技術細節。為研究者具名致謝。
何時應立即揭露
某些情況值得加速揭露：
- 漏洞已於野外被主動利用
- 漏洞對實體安全構成立即風險
- 廠商已被通知但於合理期間內拒絕行動
- 漏洞影響關鍵基礎設施或公共安全系統
AI 系統的漏洞賞金計畫
主要 AI 供應商已建立漏洞賞金計畫，但各計畫對 AI 特有議題的範疇差異顯著。
當前 AI 漏洞賞金地景
| 供應商 | 計畫 | AI 安全範疇 | 典型賞金區間 |
|---|---|---|---|
| OpenAI | Bug Bounty（Bugcrowd） | API 安全、有限安全議題 | $200 – $20,000 |
| Google DeepMind | Google VRP | 部分 ML 特定類別 | $500 – $31,337 |
| Anthropic | 負責任揭露 | 接受安全與資安發現 | 個案議定 |
| Meta | Meta Bug Bounty | 接受 Llama 模型議題 | $500 – $300,000 |
| Microsoft | MSRC Bug Bounty | Azure AI、Copilot 議題 | $500 – $30,000 |
AI 漏洞賞金通常涵蓋
- AI API 中的驗證與授權繞過
- 因 AI 系統組態錯誤造成的資料暴露
- AI 基礎設施中的伺服端漏洞
- 速率限制與資源耗盡議題
- 部分模型安全議題（各供應商差異顯著）
通常不涵蓋
- 越獄與提示注入（視為已知限制）
- 模型幻覺與事實錯誤
- 偏見與公平性議題（常由另外通道處理）
- 不指向資安瑕疵的內容政策違規
常見倫理兩難
兩難 1：發現無關漏洞
於授權委任期間發現範圍外系統的嚴重漏洞。
兩難 2：客戶希望壓下發現
客戶要求不要將某嚴重漏洞納入最終報告。
倫理義務很清楚：發現應被準確回報。若客戶不想修復，那是他們的風險決策，但報告應反映實情。若客戶提供書面確認，可將該發現附「風險接受」註記納入。
兩難 3：漏洞影響其他組織
共用模型或平台的漏洞影響你客戶以外的組織。
與你的客戶協調決定合適揭露。若漏洞位於底層模型，模型供應商必須被通知。你的委任合約應含此情境之條款（見授權與合約）。
兩難 4：測試產出真實有害內容
你的測試產出詳盡、可行動的有害內容（例如真實合成指示）。
將此類輸出視為敏感資料。不要於報告中原文納入有害內容——僅摘要類別與嚴重性。於漏洞記錄完成後安全刪除原始輸出。將該安全缺口回報模型供應商。
相關主題
- AI 紅隊的法律框架 -- 與倫理義務互補的法律要求
- 授權、合約與責任 -- 揭露與資料處理的合約條款
- AI 安全基準與評估 -- 評估 AI 安全的系統性做法
- 報告撰寫 -- 如何專業地記錄並呈現發現
參考資料
- "Coordinated Vulnerability Disclosure Guidelines" - CERT/CC, Carnegie Mellon University（2024）- 適用於 AI 系統的負責任漏洞揭露標準框架
- "The Menlo Report: Ethical Principles for ICT Research" - Department of Homeland Security（2012）- 資通訊技術研究的奠基倫理原則
- "AI Red Teaming: Ethical Considerations" - Partnership on AI（2024）- 針對 AI 系統對抗測試之倫理指引
- "Responsible Disclosure for AI Vulnerabilities" - OWASP Foundation（2024）- AI 特有資安發現之社群揭露指引
對於需重訓模型才能修補之 AI 漏洞，建議揭露時程為何？