OpenHack：點樣將 LLM 由聊天助手變成真正嘅安全 Code Reviewer

換句話講，開發團隊可以喺日常開發流程中直接跑安全分析，而唔需要另外再做一次人工安全審計。

為何一般 LLM Code Review 容易出問題

雖然 LLM 理論上可以理解程式碼，但如果只用簡單 prompt，例如「幫我搵漏洞」，結果通常唔太可靠。Hadrian 指出幾個常見問題：

• 誤報（False positives）高：AI 會將正常程式模式誤判為安全漏洞
• 幻想漏洞（Hallucination）：模型憑空「創造」其實不存在嘅問題
• 分析結果不一致：同一段程式碼，換個 prompt 或上下文就會得出唔同結論

OpenHack 嘅核心做法係用一套 結構化方法論 取代隨機 prompt，令 AI 按固定步驟調查問題。

情境式漏洞分析（Scenario‑Based Scoping）

OpenHack 最重要嘅概念之一係 情境式分析。

唔係叫 AI 全面掃描所有問題，而係要求佢針對特定攻擊場景去調查，例如：

• 追蹤使用者輸入點樣流入系統
• 尋找 Local File Inclusion（LFI）漏洞
• 檢查憑證儲存方式或雲端設定

呢種方式可以令模型集中注意力，並帶住清晰嘅攻擊目標去分析程式碼，從而減少泛泛而談嘅安全建議。

獨立 Triage：將發現同驗證分開

OpenHack 另一個重要設計係 將漏洞發現同驗證分開處理。

典型流程大概係：

1. 一個 AI agent 找出潛在漏洞
2. 另一個步驟或 agent 進行 triage（審核）
3. 收集證據後先確認問題

呢個設計鼓勵模型提供具體證據，例如：

• 可追蹤嘅程式碼路徑
• 攻擊鏈
• 配置或憑證暴露

結果係減少低質報告同誤報。

荷蘭政府開源系統審計案例

Hadrian 表示，類似 OpenHack 嘅方法曾經用於審計 荷蘭政府機構使用嘅開源應用程式。

根據公司說法，AI 輔助審查喺幾個鐘內發現 數百個安全問題。

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

• 未經驗證嘅 Local File Inclusion（LFI） 漏洞
• 導致 Azure 憑證暴露
• 最終可能引向 Azure 環境遠端程式碼執行（RCE）

不過要注意，呢些成果主要由供應商自己報告，目前仍需要更多獨立研究驗證。

點解 Hadrian 要開源

Hadrian 將 OpenHack 放上 GitHub，並採用 MIT 開源授權，同時提供：

• 完整文件
• prompts
• CLI 工具
• Python 3.9 以上支援

公司表示，目標係 「拉平攻防差距」。如果 AI 找漏洞嘅能力只掌握喺少數公司或攻擊者手上，防守方就會落後。

透過開源方法論，開發者同安全團隊可以利用常見 LLM，自行分析自己嘅程式碼庫。

AI 安全審計嘅新趨勢

OpenHack 其實反映緊一個更大趨勢：AI 代理正在逐漸參與程式碼安全審計。

現代 AI 開發工具已經可以：

• 理解整個程式碼庫
• 推理系統架構
• 自動執行多步任務

像 OpenHack 呢類結構化 workflow，就係嘗試將呢些能力轉化成 系統化漏洞研究工具，而唔只係隨機評論程式碼嘅 AI reviewer。

隨住 AI coding agent 越來越普及，未來安全審查可能愈來愈依賴呢種模式：

• 明確範圍
• 收集證據
• 獨立驗證

只有咁樣，AI 做嘅安全分析先有機會真正可信。