2026-07-28 by 高田鑑識

本文翻譯自：We Now Build Code Faster Than We Can Understand It: The New Risk of AI Speed
原文作者：Avi Hein
原文日期：2026-07-28

有個古老的故事，講述一名學徒對著掃帚施了魔法，讓它自己去打水，結果卻怎麼也停不下來。學徒慌了手腳，把掃帚劈成兩半，沒想到卻變成兩支掃帚繼續以同樣的速度打水，接著愈變愈多，最後洪水氾濫——因為他啟動的這個過程，並不會因為他想喊停就跟著慢下來。2026 年的軟體開發，正面臨同樣的問題。我們需要的不是更多自動化，而是真正能跟上這股已被釋放出來的力量的東西。

企業程式碼庫的安全防護，本來就因為大多包含多種程式語言而充滿挑戰。如今 AI 助理讓這項挑戰雪上加霜——它們會依據任務自行判斷「最合適」的語言來產生程式碼，完全不管你的掃描器讀不讀得懂。TIOBE 指標目前追蹤超過五十種實際在用的程式語言——而且不見得是你想像中的那些語言。舉例來說，Go 與 Haskell 如今在部分熱門網站上，排名已與 Python 並列。

這些 AI 助理寫程式碼的速度，也比人類快上許多。微軟研究院（Microsoft Research）測得，使用 GitHub Copilot 的開發者，完成相同任務的速度比未使用者快 55.8%。Checkmarx《2026 應用程式安全未來趨勢調查》（Future of Application Security survey）點出了這股速度對這份工作造成的改變：開發者的角色，已從「撰寫程式碼」變成「編輯程式碼」，從產出內容變成監督輸出結果。

「更多程式碼、寫得更快、涵蓋更多語言」這樣的組合，正製造出一個大多數團隊既不理解、也沒有能力應付的資安挑戰。而漏洞，正藏身其中。

AI 產生的正式環境程式碼愈多，能夠大規模滲透進來的風險也愈多。根據同一份報告，正式環境程式碼有 81% 至 100% 由 AI 產生的組織，其已知漏洞的上線比例，是 AI 僅產生 1% 至 20% 程式碼組織的 3.4 倍。問題不只在於速度：AI 產生的程式碼即使看起來正確，仍可能承襲了其學習來源中的不安全寫法，使漏洞更難被發現、也更難追蹤源頭。

此外，攻擊者也不會坐等資安防護跟上腳步。Anthropic 針對 N-day 漏洞攻擊的研究發現，WannaCry 在 2017 年修補程式釋出後，花了 59 天才被武器化；而 Mandiant 研究的 25 個歷史漏洞中，有 16 個花了超過一個月才被實際利用。這樣的時間軸，如今已成過去式。同一份研究中，Anthropic 自家模型 Claude Mythos Preview，在 Mozilla 釋出修補程式後，「一小時內」就準備好一個可用的 Firefox 漏洞利用程式——比修補後的瀏覽器版本正式推出，還早了 18 天。

這樣的失衡再清楚不過：攻擊者現在能在數小時內完成攻擊，防守方卻還在努力理解以 AI 速度、跨越比以往更多語言所產生的程式碼。要縮小這個落差，就必須從程式碼上線之前開始著手。

掃描程式碼，向來意味著要選擇一種視角。決定性（deterministic）掃描器，是透過已知規則、特徵碼與模式來檢視程式碼，結果一致——同一段程式碼跑兩次，得到的結果會相同。這種可重現性，正是稽核與合規團隊信賴它的原因。AI 掃描器則採用不同的視角，它更像人類審查者一樣，透過推理來理解程式碼，因此能抓出不符合已知規則或特徵碼的風險；但這樣的彈性，也伴隨著較低的可預測性——同一個問題問兩次，答案可能不一樣。

這兩者從來都不足以單獨勝任。而這正是 Checkmarx 混合式架構拒絕妥協之處：依程式語言而定，系統會執行規則式的決定性引擎、或 AI 推理引擎其中之一，再由「發現分析引擎」（Findings Analysis Engine, FAE）將結果彙整、驗證成單一結果清單。這樣的組合，就是 Next-Gen SAST，專為已知的 N-day 漏洞打造，在不進一步引入其他機制的前提下，達到掃描器所能觸及的最高準確度。單獨使用時，其 F1 分數可達 0.64，相較於傳統 SAST 解決方案常用的基本查詢式掃描方法（F1 分數僅 0.20），有大幅提升。

但已知漏洞與 N-day 漏洞，只是問題的一部分。更困難的挑戰，在於找出那些沒有 CVE 編號、沒有特徵碼、也沒有既定模式可比對的風險。

這正是目前處於搶先體驗（Early Access）階段的 Checkmarx Fusion 所補上的一層防護。它建構在 Checkmarx 次世代混合式 SAST 掃描器之上，同時執行多個前沿 AI 模型，專門搜尋尚無 CVE 或特徵碼可比對的零日漏洞與未知模式發現。Checkmarx 會將這批範圍更廣的結果，送回同一套嚴謹的驗證流程，產出單一、可信賴的結果。

結合使用 Checkmarx SAST 與 Checkmarx Fusion，F1 分數可達 0.74。重點並不是為了加入 AI 而加入 AI，而是要讓開發者能夠信任掃描結果：精準到不會被誤判雜訊淹沒，同時涵蓋範圍夠廣，足以抓出簡單掃描器可能遺漏的重大漏洞。

前沿 AI 模型讓 Checkmarx Fusion 擁有更廣的偵測視角，能夠揪出單靠靜態規則與特徵碼所會遺漏的複雜或新型漏洞。而且，由於 AI 模型演進飛快，Checkmarx 並未綁定任一單一模型——今天最好的模型，明天未必還是最好的。因此，隨著模型不斷進步，Checkmarx 會替換成當下表現最佳的模型，同時維持決定性核心引擎、程式碼情境與驗證流程不變。

「乾淨的檢測結果」，不等於「已修復的漏洞」。Checkmarx Fusion 目前是 Checkmarx SAST 的最後一層防護，而同樣的模式，也正逐步導入其他掃描類型，將防護範圍延伸至整個應用程式開發生命週期，讓資安不會止步於「發現問題」。這並不是每個團隊一開始就需要的層級，而是當標準掃描涵蓋範圍已經不夠、當「找得準」和「找得快」同樣重要時，團隊才會需要用到的層級。

而這樣的需求只會愈來愈迫切。新模型推出的速度，比資安藍圖能夠因應的速度還快，而每一款新模型，都可能改變攻擊者所能發現與利用的範圍。Claude Mythos Preview 從修補程式釋出到完成漏洞利用只花一小時的案例，正是這種狀況在現實中的寫照：修補程式釋出後一小時內，就出現了可用的漏洞利用程式。

一套只能抓出「自己已知」漏洞的掃描器，永遠會慢攻擊者一步。Checkmarx Fusion 的存在，就是要為那些需要更深入驗證、對自己所交付內容更有信心的團隊，補上這個落差。

那名學徒真正的錯誤，並不是施了那個法術，而是誤以為自己還能控制接下來會冒出多少支掃帚。Checkmarx Fusion 正是為了故事的這個版本而生——掃帚冒出的速度比任何人預期得都快，而總得有人知道，哪一支才是真正重要的。