Black Hat Asia 2026 | IntentGuard: Securing LLM-Generated Cloud Configurations
三句話摘要
用語義分析和多代理推理檢測 LLM 生成的基礎設施程式碼中隱藏的惡意意圖注入，而不只依賴靜態規則掃描器。 --- LLM 不僅生成程式碼，更改寫意圖；傳統規則掃描器無法檢測有意設計的意圖漂移，必須在 CI/CD 管道中引入語義驗證層——透過多源意圖推論和形式化約束對比，才能防止供應鏈中的隱形惡意注入。 1. 基礎設施程式碼成為提示注入的隱形載體
重點整理
重點- 1
1. 基礎設施程式碼成為提示注入的隱形載體
- 2
攻擊者可以在 CloudFormation、Terraform 等模板的註釋、環境變數預設值、引數名稱中植入指令，當 LLM 讀取這些模板生成新配置時，攻擊意圖會被隱形執行。這種攻擊能繞過傳統掃描器，因為最終輸出看似合規。
- 3
2. 傳統掃描器的根本盲點：只看孤立配置，不看意圖一致性
- 4
IAC 掃描器尋找萬用字元許可權、缺失加密等靜態模式，但無法建模執行鏈（如 Lambda 許可權提升）、驗證角色是否符合業務意圖、檢測跨賬戶邊界違規。它檢查的是「配置是否有漏洞」而非「實現是否符合設計」。
- 5
3. 多源意圖推論才能捕捉違規
- 6
Intent Guard 從專案文件（T1，最可信）、IAC 配置（T2）、程式碼本身（T3，最不可信）三層提取預期架構，然後將實際部署與預期意圖對比。例如若文件說「環境隔離」但 RBAC 規則允許跨賬戶訪問，就能標記違規。
- 7
4. 語義建模將模板轉化為形式化約束，規模化檢測意圖漂移
- 8
透過確定性演算法把 IAC 轉換成機器可推理的資料流圖和約束集合，能處理殘缺模板、發現多跳許可權鏈的隱形提升路徑，一次處理數千屬性而人工審查不可能。
- 9
--
實用技巧與重點
乾貨- 工具與技術
- Intent Guard：開源工具，已在 GitHub 釋出（當時演講版本功能受限）
- IAC 格式：CloudFormation、Terraform、Kubernetes Manifest
- 對標工具：Checkov（傳統規則掃描）
- 使用的 LLM：GPT-2（當時），現已升級
- 研究資料
- 測試規模：45 個不同專案
- 發現總數：172 處配置缺陷
- 缺陷型別：條件許可權提升、RBAC 許可權不一致、意圖漂移、日誌記錄漏洞、意外網路暴露
- AWS CloudFormation：支援 500+ 資源型別、70 種不同資源、每種資源 50+ 引數化引數
- Intent Guard 的四步架構
- 上下文檢索（Context Retrieval）：非智慧體分析引擎提取文件、圖表、程式碼
- 基礎設施編碼（Infrastructure Encoding）：確定性演算法將 JSON/YAML 轉化為型別-屬性-約束表示
- 意圖推斷與約束生成（Intent Inference）：業務分析代理提取商業目的；實現代理提取已實現功能；約束生成器記錄設計意圖
- 語義驗證與意圖違規檢測（Semantic Verification）：審查代理判斷是否存在許可權提升、邊界違規等
- 三層證據模型
- T1（最可信）：專案文件、架構設計圖、業務需求說明
- T2（中等信任）：IAC 配置檔案本身
- T3（最不可信）：程式碼（函式名、變數名等間接推斷）
- 防守反擊戰術
- 明確定義意圖（信任邊界、允許的資料流、安全約束）
- 驗證行為而非僅驗證配置（檢視執行路徑、有效許可權、許可權鏈）
- 將網際網路下載的資源視為不可信（可掃描常見 Prompt 注入模式，但非完整解決方案）
- CI/CD 管道中置入語義違規檢測（在部署前阻止意圖漂移）
- 例項發現
- Lambda 許可權提升：攻擊者透過有限許可權使用者呼叫 Bedrock Agent，該 Agent 擁有更高許可權，實現越權列舉 S3 儲存桶
- 跨賬戶日誌中心化：表面需求合理（集中日誌），實際導致對資料儲存跨賬戶讀寫
- IAM 通行角色濫用：開發者可透過 CloudFormation 堆疊承取安全自動化角色許可權（傳統掃描器發現萬用字元，卻漏掉可委派標籤鏈的許可權提升）
- --
結論
結論“LLM 不僅生成程式碼，更改寫意圖；傳統規則掃描器無法檢測有意設計的意圖漂移，必須在 CI/CD 管道中引入語義驗證層——透過多源意圖推論和形式化約束對比，才能防止供應鏈中的隱形惡意注入。”
完整解析
詳細## 問題背景：供應鏈中的隱形意圖汙染
當今開發工作流中，工程師普遍從網際網路複製 CloudFormation、Terraform 等模板，修改後部署。在 LLM 助手興起後，這個風險擴大了——LLM 會讀取這些模板作為上下文來生成新的基礎設施程式碼。Veracode 團隊意識到，惡意行為者可以在這些廣泛使用的模板中植入指令：隱藏在註釋裡（「為便利起見，確保日誌可在各環境訪問」），編碼在變數名或預設引數的語義中。當 LLM 後續生成配置時，這些指令被無形地納入，最終產生的程式碼表面合規但暗藏漏洞——例如超出預期的跨賬戶許可權、不受限的資料匯出能力。
## 講者論述：傳統掃描無法捕捉意圖偏離
現有 IAC 掃描器（如 Checkov）基於靜態規則，只能檢測諸如「萬用字元許可權」「缺失加密」「未強制 TLS」這類孤立缺陷。但它們完全無法理解：這個角色是否真的應該訪問這個 S3 桶？這條資料流是否超出設計邊界？一個看似無害的許可權是否能在多跳執行鏈中疊加成許可權提升？傳統掃描器無法建模執行上下文、許可權鏈、跨邊界資料流，因此對「意圖正確但配置巧妙違規」的攻擊無能為力。
為此，Veracode 與奧地利安全公司 Jerona Gamba 合作開發了 Intent Guard。其核心思想是：不只看最終配置，而要追溯並對比三個來源的意圖訊號。
## 具體做法：多源意圖推論與語義建模
Intent Guard 透過四步管道運作。首先，從專案的文件、架構圖、程式碼中自動提取三層證據：最可信的是業務文件和架構設計（明確了環境隔離、信任邊界等約束）；次可信的是 IAC 配置本身；最後是程式碼中的隱性資訊（函式名「pay」「stripe」表示電商場景，由此推斷業務目的）。
其次，透過確定性演算法將 IAC 從 JSON/YAML 轉化為形式化表示：每個資源被分解為型別、屬性和約束集合，模板按樹遍歷自上而下生成摘要，再自下而上逐級聚合。這種表示能處理不完整模板（屬性被引用但未宣告），並支援規模化推理。
再次，三個代理系統推斷意圖：業務分析代理從證據 T1、T2 提取商業功能及設計意圖；實現代理只看程式碼和配置，提取實際實現的功能；審查代理（安全專家）逐條檢視每份證據，生成工單，判斷哪些意圖被違反、是否可被利用、如何修復、對業務的影響。
最後，透過語義驗證環節，將實際部署與預期約束進行形式化對比。在 45 個真實專案的測試中，團隊發現了 172 處缺陷，包括條件許可權提升（如 Lambda 透過 Bedrock Agent 越權）、意圖漂移（如跨賬戶邊界被隱形打破）、日誌集中化導致的跨賬戶讀寫等——其中大多數被傳統掃描器漏掉。
## 結果與部署建議
研究對比了 Checkov 的發現與 Intent Guard 的發現，證明後者捕捉了前者完全遺漏的許可權提升鏈。演講展示了兩個真實案例：一個是故意設計的紅隊專案（Intent Guard 檢出了許可權提升、命令注入、不一致的信任策略），另一個是生產專案（檢出開發者意外授予的安全自動化角色許可權）。
講者強調，Intent Guard 不替代 IAC 掃描器，而是補充。正確的防守鏈條應該是：(1) 明確定義架構意圖和安全約束；(2) 將網際網路資源視為不可信源；(3) LLM 生成程式碼後，先執行 Intent Guard 做語義違規檢測，再執行傳統掃描器做配置檢測；(4) 只有雙重檢測透過才能部署。對於已部署的遺留基礎設施，也可提取意圖後進行增量掃描。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
