Google Mantis 能自動修漏洞？先看沙箱、誤報與驗收限制

Google Mantis 將 AI 漏洞分析、重現與修補串成流程，但不能直接放進正式環境執行。看懂開源版範圍、沙箱要求、誤報判斷與修補驗收，評估團隊是否適合導入。

發佈於： 2026-09-09 | 更新於： 2026-09-09

內容查核： 2026-09-09 來源查核： 2026-09-09

Google Mantis 值得工程團隊評估，但不適合直接在連著正式系統的工作電腦上放任執行。 Google 在 9 月的入門文章介紹這套開源工具，將程式分析、誤報篩選、重現與修補串起來。開始前應備妥隔離環境、清楚的測試範圍與能接手審查的人。

Mantis 是什麼？不是下載 Google 整套防禦系統

Mantis 是讓程式代理依序完成安全審查的工具組。它會整理程式架構與歷史修補紀錄，建立威脅模型，再安排調查、去重、重現與修補。不同階段各有工作，不是叫同一段對話「幫我找所有漏洞」就結束。

這次新的是入門說明，不是首次公開。Google 六月的介紹已區分開源的核心技能與內部較完整的系統。下載公開程式庫，不等於取得 Google 內部全部整合、資料與維運能力。

官方 README也把它定位為可調整的起點，需配合公司的架構、建置方法與風險容忍度。我的判斷是：它比較適合已有測試與審查流程的團隊，還不適合當成「沒有資安人力，所以全部交給 AI」的替代品。

Mantis 不只讀程式碼；部分階段會生成並執行測試程式，還可能修改檔案。README 明確警告，不能在能存取正式系統、敏感資料或內部網路的機器上直接使用。

「我有叫 AI 只在沙箱跑」仍不夠。官方同時提醒，代理可能犯錯，提示規則不是絕對保證。應由環境實際限制權限，敏感命令保留人工核准。

gVisor 的代理隔離說明補上重要區別：沙箱技術能強化隔離，卻不替你決定哪些動作可以做；控制政策與敏感憑證可以放在代理無法自行改動的範圍之外。這和防範提示詞注入是同一個原則：不要讓被分析的資料，有機會變成擴張權限的指令。

對台灣接案團隊而言，我會先確認客戶是否允許這種分析、程式碼可送往哪些模型服務，以及哪些資料不能進測試環境。開源的是工具程式，不代表模型呼叫免費，也不代表客戶程式碼能任意上傳。

假設 AI 指出一段權限檢查「可能讓不同客戶互相讀到資料」。這只是待查假設，還需要確認使用者身分、實際呼叫路徑與部署條件。另一段程式可能已擋住它，也可能是測試環境缺少必要設定，讓問題暫時無法重現。

官方 README 特別提醒：重現失敗不等於誤報；成功重現也不代表所有情境都能被利用。 因此，驗收應分層記錄：

修補還要檢查正常功能是否被破壞。若 AI 只是把有問題的功能整段停用，錯誤測試可能不再出現，產品卻也不能用了。

NIST SSDF 1.1的 PW.8.2 就將既有漏洞測試納入測試套件，作為防止問題重現的做法；RV.3 則要求分析根因。這些是可借鏡的開發實務，不是使用 Mantis 就自動取得的認證。

我建議先選自己有權檢查、建置可重跑、資料已去識別化的小模組。先講清楚誰是可信使用者、哪些行為算安全問題、哪些只是可接受的功能限制，再觀察 AI 的發現能否由另一位工程師重查。

驗收時不要只數報告有幾份。應記錄有多少問題確認成立、重複了多少、審查花多少時間，以及修補是否通過原有功能測試。可搭配企業程式代理評估決定擴大條件。

這不代表 AI 回報都沒價值。curl 維護者 Daniel Stenberg 在 4 月的經驗文章指出，收到的報告品質提高，卻仍帶來維護負擔；找到更多真的問題，也需要有人排優先順序、修補並發布。

Mantis 的 mantis-advise則嘗試把已驗證修補與歷史問題帶回開發階段，讓代理在改程式前先查既有教訓。我比較看重這個方向：不只增加漏洞清單，還要減少同類問題反覆發生。

沒有隔離環境、沒有人能驗證結果，就先不要跑自動重現與修補。 先把程式代理到 PR 的審查流程補齊，會比一口氣掃完整個客戶專案更有用。

Mantis 是新的 AI 模型嗎？

不是。它是供程式代理使用的安全審查工具組，需要搭配模型、執行環境與團隊規則；開源版也不等於 Google 內部完整平台。

AI 沒有成功重現，就能把問題關掉嗎？

不能只靠這一點判斷。可能是誤報，也可能是測試前提、依賴或環境不完整，應由熟悉程式的人確認後再決定狀態。

適合拿來大量回報開源專案漏洞嗎？

不應大量提交未驗證的 AI 報告。官方要求由安全專業人員確認發現，再依專案的安全回報規範處理，避免增加維護者負擔。

№ · further reading