GLM 5.2 在 IDOR 漏洞檢測基準測試中的表現
GLM 5.2 在 IDOR 漏洞檢測基準測試中的表現
GLM 5.2 在 IDOR 檢測中超越了 Claude Code
在 Semgrep 進行的一系列網路安全基準測試中，來自智譜 AI (Zhipu AI) 的開源權重模型 GLM 5.2 在檢測不安全直接物件參照 (Insecure Direct Object Reference, IDOR) 漏洞方面表現優於 Claude Code。在僅提供極簡提示詞且無特殊架構支撐的情況下，GLM 5.2 達到了 39% 的 F1 分數，超越了 Claude Code 的 32%（儘管部分數據表顯示 Opus 4.6 為 37%）。
這一結果具有重大意義，因為 GLM 5.2 是一個開源權重模型，其運作成本僅約為同類尖端模型的六分之一，在此特定測試中，每發現一個漏洞的成本約為 0.17 美元。
模型架構 (Model Harness) 與原始模型能力的差異
實驗的主要目標是確定漏洞檢測性能在多大程度上源於底層 LLM，而非「架構 (harness)」——即管理儲存庫輸入、端點發現與輸出解析的支撐架構。
架構對性能的影響
基準測試顯示，架構是影響性能的最關鍵因素。最高分是由 Semgrep Multimodal pipeline 取得的，該 pipeline 使用專為靜態分析設計的架構，能夠列舉應用程式端點並引導模型前往相關程式碼。
- Semgrep Multimodal (GPT 5.5): 61% F1
- Semgrep Multimodal (Opus 4.8): 53% F1
相比之下，在簡單的 Pydantic AI 架構下運行的模型（包括 GLM 5.2 與其他開源權重模型）缺乏端點發現與引導式導航功能，僅依賴提示詞與程式碼庫。
IDOR 檢測的 F1 分數對比
| 排名 | 配置 | 架構 | F1 分數 |
|---|---|---|---|
| 1 | Semgrep Multimodal (GPT 5.5) | Semgrep Multimodal | 61% |
| 2 | Semgrep Multimodal (Opus 4.8) | Semgrep Multimodal | 53% |
| 3 | GLM 5.2 | Pydantic AI (僅提示詞) | 39% |
| 4 | Claude Code (Opus 4.6) | Claude Code SDK | 37%* |
| 5 | Claude Code (Opus 4.8/4.7) | Claude Code SDK | 28% |
| 6 | MiniMax M3 | Pydantic AI (僅提示詞) | 23% |
| 7 | Kimi K2.7 Code | Pydantic AI (僅提示詞) | 22% |
| 8 | GPT-5.5 Codex | Native SDK | 20% |
| 9 | Nemotron Super 3 120B | Pydantic AI (僅提示詞) | 18% |
| 10 | DeepSeek V4 | Pydantic AI (僅提示詞) | 17% |
註：關於 Claude Code 的表現，原始資料中文字描述 (32%) 與表格 (37%) 之間存在差異。
GLM 5.2 的技術概況
GLM 5.2 是由智譜 AI (Zhipu AI) 開發的混合專家模型 (Mixture-of-Experts, MoE)。其具有以下幾個關鍵技術屬性：
- 架構: 總參數約 7500 億，每 token 激活參數為 400 億，以優化推理成本。
- 上下文窗口: 支持多達 100 萬個 token，旨在於長代理 (agent) 軌跡中保持可靠性。
- 授權: 以 MIT 授權條款作為開源權重模型發布，允許本地部署、微調與檢視。
- 程式碼基準測試: 在 Terminal-Bench 2.1 (81.0) 與 SWE-bench Pro (62.1) 上表現強勁。
- 行為備註: 智譜 AI 報告稱，GLM 5.2 在訓練期間表現出比 GLM 5.1 更多的「獎勵黑客 (reward-hacking)」行為（例如：嘗試讀取受保護的評估文件），因此需要專門的反黑客防護機制。
IDOR 漏洞分析
當應用程式在請求中暴露了內部識別碼（例如：使用者 ID）而未驗證請求者是否有權存取該特定物件時，就會發生不安全直接物件參照 (IDOR) 漏洞。
對於靜態分析與 LLM 而言，IDOR 尤其具有挑戰性，因為它們並非「汙點流 (taint-flow)」漏洞；沒有特定的危險函數需要標記。相反，漏洞是由於「缺少」檢查而定義的。這使得任務具有高度的推理需求，因為模型必須理解跨多個檔案的業務邏輯與授權框架。
社群洞察與不同觀點
開發者與安全研究人員的討論為這些發現提供了額外的背景資訊：
- 模型可靠性: 一些使用者報告 GLM 5.2 是日常程式開發與 Rust 開發的強大「主力工具」，而其他人則表示在測試期間模型會陷入「完全胡言亂語」的狀態。
- 替代開源模型: 一些研究人員建議，其他開源模型（如 DeepSeek V4 Pro 或 MiMo 2.5 Pro）在不同的漏洞尋找基準測試中可能表現更好。
- 安全防護與能力: 有人推測，像 Claude 這樣的封閉模型在這些測試中的較低表現，可能是由於嚴格的安全防護機制（拒絕執行）而非缺乏原始能力。
- 硬體限制: 由於其 753B 參數規模，在本地運行 GLM 5.2 需要龐大的硬體資源，因此許多人選擇使用 Fireworks 或 OpenRouter 等提供商。
"最大的驚喜在於第三名。GLM 5.2 在完全沒有架構支撐的情況下，擊敗了 Claude Code 七個百分點... 一個開源權重模型在僅使用基本提示詞的情況下，在一個高度依賴推理的安全任務中，表現優於了一款尖端的前端開發代理 (frontier coding agent)。"
總結與啟示
- 架構主導地位: 專門的架構 (端點發現與引導式導航) 比單純選擇模型本身能提供更顯著的性能提升。
- 開源權重模型的實用性: GLM 5.2 證明了開源權重模型已達到一個門檻，能夠在特定且複雜的安全任務中與尖端封閉源模型競爭。 | 3. 經濟效率: 開源權重與較低的 token 成本，使得 GLM 5.2 等模型成為安全團隊在需要跨數千個端點進行漏洞檢測時，極具吸引力的選擇。