OpenHack：把 LLM 程式代理變成可靠資安程式碼審查員

AI 編碼代理可以快速閱讀與分析大型程式碼庫，但在安全審查場景中，單純依靠大型語言模型（LLM）往往會出現誤報過多、虛構漏洞（hallucination）以及分析邏輯不穩定等問題。為了解決這些問題，阿姆斯特丹資安公司 Hadrian 推出了開源專案 OpenHack，希望把 LLM 從「聊天式助手」轉變為有流程、有證據的資安審查工具。

OpenHack 的核心不是新的 AI 模型，而是一套結構化工作流程（workflow）與工具包，用來指導 AI 如何逐步調查漏洞、蒐集證據並驗證發現，使 AI 審查結果更可靠。

OpenHack 是什麼

OpenHack 是一個以檔案為基礎的工作區與工具集合，專門設計用於 AI 輔助的原始碼安全審查。專案中包含：

• 預設提示詞（prompts）
• 安全審查流程與文件
• CLI 命令列工具
• 針對漏洞分析的工作模板

這些元素一起協調 LLM 如何分析程式碼並產出安全報告。

OpenHack 可以直接在「代理式 AI 開發環境」中使用，例如：

• Claude Code
• Codex
• Cursor

這些工具允許 AI 代理在開發環境中讀取整個 repository、執行任務並進行多步推理，因此適合執行完整的安全審查流程。

為什麼一般的 LLM 程式碼審查不可靠

如果直接對 AI 下指令：「幫我找出這個 repository 的漏洞」，通常會出現幾個問題：

• 誤報率高：模型把正常程式模式誤判為漏洞。
• 幻覺漏洞：AI 可能「想像」出不存在的漏洞。
• 分析不一致：不同提示詞或上下文限制會導致不同結論。

Hadrian 認為，問題的根源不是模型能力，而是缺乏結構化調查流程。

OpenHack 的做法是把 AI 的工作拆成明確步驟，例如調查、證據收集、驗證與分類，讓 AI 更像資安研究員，而不是隨機評論程式碼的聊天機器人。

情境式漏洞調查（Scenario‑Based Scoping）

OpenHack 的關鍵概念之一是 情境式範圍設定。

與其讓 AI 在整個程式碼庫「隨機找問題」，工作流會要求模型專注於特定攻擊情境，例如：

• 追蹤使用者輸入在系統中的資料流
• 搜尋 Local File Inclusion（LFI）風險
• 檢查憑證與雲端設定

這種方式可以縮小分析範圍，讓模型更容易建立完整的攻擊路徑推理，而不是產生泛泛而談的安全建議。

用「獨立驗證」降低誤報

另一個核心設計是將 漏洞發現與驗證分開。

在典型的 OpenHack 流程中：

1. 一個 AI 代理負責發現潛在漏洞
2. 另一個步驟或代理負責 triage（驗證與分類）
3. 只有在證據充足時才會被確認為漏洞

這種分工設計會要求 AI 提供具體證據，例如：

• 可追蹤的程式碼路徑
• 可行的攻擊鏈
• 相關設定或憑證暴露

因此可以有效過濾掉弱證據或推測性的結果。

在荷蘭政府開源專案中的實測

Hadrian 表示，他們使用類似 OpenHack 的方法審查 荷蘭政府機構使用的開源應用程式。結果在幾小時內就找到了 數百個安全問題。

其中一個案例涉及完整的攻擊鏈：

• 未授權的 Local File Inclusion（LFI）漏洞
• 進一步暴露 Azure 憑證
• 最終可能導向 Azure 環境中的遠端程式碼執行（RCE）

需要注意的是，這些結果目前主要來自 Hadrian 自身的研究報告，仍需要更多獨立驗證。但它展示了 AI 在追蹤複雜攻擊路徑方面的潛力。

為什麼要把 OpenHack 開源

Hadrian 將 OpenHack 以 MIT 授權發佈在 GitHub 上，並提供：

• 完整文件
• CLI 工具
• 提示詞與流程模板
• Python 3.9 以上版本支援

公司表示，開源的目的是「讓防禦方也能使用 AI 進行漏洞發現」，避免這些能力只掌握在少數企業或攻擊者手中。

AI 資安審查正在成為新趨勢

OpenHack 反映出一個更大的趨勢：AI 代理正在被用來探索整個程式碼庫的安全問題。

現代 AI 開發工具已經可以理解專案架構、分析依賴關係並執行多步任務。 當這些能力與結構化安全工作流結合時，AI 就能從「程式助手」升級為系統化的漏洞研究工具。

未來若 AI 參與程式開發越來越普遍，像 OpenHack 這樣強調範圍限制、證據收集與獨立驗證的工作流，可能會成為 AI 安全審查可信度的關鍵基礎。