還記得 2019 年 Capital One 的雲端大 breach 嗎？前 AWS 工程師 Paige Thompson 靠一個防火牆配置失誤，直接撬開核心資料庫，洩漏上百萬用戶個資。OCC 隨後開出 8000 萬美金罰單，金融業才驚覺傳統邊界防禦在雲端時代有多脆弱。七年過去，Capital One 沒收手，反而堅定走 open-source first 策略，更加入 OpenSSF 治理委員會。如今他們將內部打磨的 AI 安全工具 VulnHunter 以 Apache 2.0 送上 GitHub，這不只是技術發布，更是血淚教訓後的自信宣言。在 AI 攻擊門檻暴跌的當下，為什麼要把這把鑰匙交給全產業？
痛在哪？誤報淹沒工程師，AI 攻擊已經不等人類了
我們做過 DevSecOps 的人都知道，傳統掃描器最讓人崩潰的就是誤報率。它們通常採用「逆向比對」——先在程式碼裡抓出看起來危險的模式，再往回找有沒有攻擊者能進來。結果呢？工程師每天要處理幾百筆告警，真正要修的可能只有幾筆。VulnHunter 的破局點在於「攻擊者優先的前向分析」。它會先鎖定 API、檔案上傳介面這些真實攻擊者會叩門的入口，然後一路跟蹤資料流向與內部安全檢查點，確認攻擊路徑在現實中能不能真的跑通。
但光會找還不夠，它裡面藏了一個自我推翻引擎（Falsification Engine）。找到疑似漏洞後，它會先試著證明「這其實打不進來」。邏輯斷層、假設不成立、環境條件不符，都能讓它直接砍掉告警。等到最後送到工程師眼前的，幾乎都是實錘等級的漏洞，並且附上完整的攻擊路徑圖與一鍵修補建議。這下子，開發者不用再把時間浪費在自證清白上。
我個人覺得，這套邏輯未來一到兩年會徹底改變企業對資安工具的期待。當 Claude Opus 4.8 這類模型能穩定跑在 CI/CD 流水線裡，資安將不再是「上線前最後一關」的守門員，而是伴隨程式碼一起生成的基礎設施。我預測 2027 年底，主流金融機構的開發流程裡，至少會內建一組類似 VulnHunter 的前向分析模組。不是為了趕潮流，而是因為人類的審理速度已經跟不上 AI 的攻擊節奏。
| 維度 | 傳統掃描器 | VulnHunter |
|---|---|---|
| 分析路徑 | 逆向比對（抓模式往回找） | 前向推理（從入口追蹤資料流） |
| 誤報處理 | 工程師人工篩選 | 自我推翻引擎預先過濾 |
| 輸出內容 | 告警編號 + 程式碼片段 | 完整攻擊路徑圖 + 情境化修補建議 |
| 部署模型 | 規則/簽名為主 | Agentic AI（目前基於 Claude Opus 4.8） |
「我們覺得有義務把 VulnHunter 開放，因為現代軟體供應鏈高度連動，AI 威脅的規模已經超過任何單一組織能獨自承擔。」—— Capital One CISO Chris Nims
為什麼要把東西送出去？這是一場供應鏈的共賭
很多人會問，Capital One 自己花了大錢養團隊、跑內部驗證，為什麼不鎖在自家黑盒子裡吃獨食？CISO Chris Nims 的邏輯很直白：現代軟體供應鏈是共用的，單一開源元件的漏洞會連鎖影響全產業。與其讓防禦工具只在自家流水線裡轉，不如開放讓全球社群一起測試、擴充。這其實是一種「以攻代守」的競爭策略——當 VulnHunter 成為業界標竿，其他銀行、金融新創與雲端供應商就必須跟進拉齊基線，否則在開發者體驗與資安效率上就會被甩開。
從 2019 年那場因為一個 Apache Struts 等級的簡單漏洞就讓防禦失守的事件，到現在把 AI 直接推進程式碼撰寫階段，Capital One 其實是在告訴全產業：守門員已經不夠了，安全必須長在程式碼裡面。
延伸思考與常見問題
Q1：VulnHunter 的「自我推翻引擎」跟一般的漏洞驗證有什麼不同？ 答：它不是等工程師去手動確認，而是讓 AI 在內部先扮演「挑刺者」，主動搜尋邏輯斷層與環境條件限制，只有推翻不掉的發現才會流出到人工階段，大幅降低誤報干擾。
Q2：為什麼 Capital One 在 2019 年吃過雲端大虧後，反而更堅定走開源路線？ 答：他們體認到現代軟體供應鏈是共用的，單一元件的漏洞會連鎖影響全產業，與其把防禦工具鎖在自家黑盒子裡，不如開放讓全球社群一起測試與強化。
Q3：目前 VulnHunter 依賴 Anthropic 的 Claude Opus 4.8，這會不會造成供應商鎖定？ 答：官方表示架構具備跨模型擴展潛力，未來能適配其他基礎模型與程式碼環境；目前的 Claude 整合是基於當前生成能力最穩定的選擇，並非長期綁定。