Google Mantis：AI 輔助找 Bug 要如何才真正有用

重點摘要：AI 安全工具需要驗證閉環

Google Cloud 介紹的 Mantis 專案，展示 AI 輔助應用程式安全正在走向哪裡。它不是讓模型掃描儲存庫後回傳大量可疑問題，而是把漏洞發現、分流、重現、去重與修補驗證組織成一套流程。重點不在於代理能否取代安全工程師，而在於它是否擁有儲存庫歷史、威脅模型、隔離執行環境、可重複使用的工具，以及判斷修復是否有效的明確測試。

這會改變開發者挑選工具的方式。好的安全助手不一定是發出最多警告的工具，而是能協助團隊從可疑程式碼走到可重現的問題、可審查的修補，以及缺陷已消失的證據。

Mantis 正在處理哪一類問題

Google Cloud 的 Mantis 介紹將 Mantis 描述為用於找 Bug 和修復 Bug 的開源 Harness。Mantis 儲存庫也提供安全分析相關的流程與技能。實際上，代理獲得的是有結構的工作環境，而不是一個空白聊天視窗。

這很重要，因為安全發現很少只是文字生成問題。一次有價值的調查，可能要理解功能如何演變，確認輸入周圍的信任邊界，建立小型概念驗證，在沙箱執行測試，把候選修補與原本行為比較，並刪除重複報告。每一步需要的證據不同。能解釋程式碼的模型，不一定能證明可利用性，也不一定能確認修補沒有破壞其他路徑。

為什麼儲存庫歷史和威脅模型很重要

靜態掃描看見的是今天存在的程式碼。擁有儲存庫歷史的代理，還能看到權限檢查為何加入、哪個輸入被視為不安全，以及過去的修復是否不完整。這些脈絡能減少誤報，也能協助優先處理真正影響安全邊界的變更。

威脅模型會追問：誰控制輸入、攻擊者能到達什麼、哪個身分或資料可能受影響，以及成功利用會改變什麼。缺少這些問題時，代理可能把每個異常模式都標成嚴重，也可能因為漏洞在局部看起來普通而錯過細節。

因此，AI 安全工具應該展示證據，而不是只給一個很有自信的分數。報告最好包含相關檔案和路徑、使用的假設、重現步驟、預期影響與分析限制，讓團隊判斷要修補、增加補償控制，或不採取行動。

重現是分水嶺

代理安全流程最有價值的部分，往往是安全地嘗試重現問題。沙箱可以限制網路、憑證、檔案系統與破壞性指令，同時允許代理測試一個狹窄假設。這比單純比對模式更具體。

重現也改善溝通。開發者可以審查小型測試案例，安全人員能確認行為是否越過信任邊界，發布負責人可以要求修補後同一測試仍然通過。留下的是可繼續使用的工程產物，而不只是聊天紀錄。

並非每個漏洞都能自動證明。有些問題依賴正式環境設定、時間條件、身分策略或多個弱控制的組合。這時正確的輸出應是界線清楚並標示不確定性的假設，而不是編造一個完整攻擊。

挑選 AI 安全工具前要檢查什麼

採用代理安全工具前，至少檢查五條界線：

1. 權限： 代理能否讀取密鑰、寫入正式分支或呼叫外部服務？
2. 隔離： 重現是否在一次性環境執行，網路和檔案系統政策是否清楚？
3. 證據： 發現是否連結程式碼、測試、記錄與可重現步驟？
4. 恢復： 人能否暫停、回復或拒絕修補？
5. 資料： 儲存庫、提示與生成的修補會保存多久，是否用於訓練？

如果你正在比較編碼助手、安全掃描器、測試工具或儲存庫工具，可以瀏覽 BTTC 軟體目錄，比較權限、整合、匯出和審查控制。更多技術說明可以查看 BTTC 部落格。

常見問題：用代理處理應用程式安全

AI 代理能取代安全工程師嗎？

不能。它可以加快重複調查、產生測試並整理證據，但風險定義、假設驗證、變更核准與正式環境判斷仍需要人。

重現出的 Bug 就一定是高風險漏洞嗎？

不一定。重現只證明它在測試條件下會發生，嚴重程度還取決於暴露範圍、攻擊者控制能力、受影響資產、所需權限和業務影響。

應該讓代理自動合併修補嗎？

通常不應預設允許。較安全的做法是由代理建立候選修補和回歸測試，再經過人工審查與獨立檢查。

結語

Google Mantis 指向更可信的 AI 輔助安全模式：代理要收集脈絡、驗證有限假設、產出可審查證據，並在受控範圍內確認修補有效。評估開發者工具時，最值得問的是：產品能否幫你證明並安全解決問題，還是只會再產生一張需要人工篩選的清單？