為什麼 AWS 的全倉庫安全掃描比更快的 SAST 更重要

AWS Security Agent 的全倉庫掃描，比只追求更快的 pattern-based SAST 更能抓到真正危險的系統性漏洞。

AWS 這次押對方向了：安全掃描的關鍵不是更快，而是先看懂整個倉庫，因為真正會傷到團隊的漏洞，多半不是單點語法錯誤，而是跨檔案、跨流程、跨信任邊界的設計失敗。

在預覽說明裡，AWS 舉的例子都不是小題大作：一個驗證函式漏掉單引號，卻牽涉五組 regex profile；另一個 stored procedure 直接繞過那層驗證；還有一個 XSS 問題，同一個檔案裡一條路徑用了 Encode.forHtml()，另一條卻沒用。這些都說明，光靠局部 pattern 去掃，常常只能看到表面症狀，看不到真正的攻擊面。

第一個論點

安全失敗通常是系統性的，不是局部的。現代應用最危險的地方，往往不是某一行少了 escape，而是某個假設只在半條路徑成立。AWS 提到的 HTML encoding 不一致，就是典型案例：同一個檔案裡有安全處理，不代表整條資料流都安全。只要另一個分支沒跟上，攻擊者就能從那個缺口進來。

這也是全倉庫分析比單點 SAST 更有價值的原因。假設一個大型服務有 200 個以上的路由與數十個 helper function，pattern-based 工具能很快掃出已知 sink，卻不一定能判斷哪條路徑真的可達、哪個前置驗證被繞過、哪個授權檢查只在某些條件下生效。AWS 的方法是先建立安全模型，再找 bug，方向本身就比「先比對樣式」更接近真實風險。

第二個論點

上下文比 pattern matching 更重要。傳統 SAST 擅長抓明確模式，例如硬編碼密鑰、直接 SQL sink、未轉義輸出，這些都很有用。但當問題變成「五個 regex profile 少了一個例外」或「驗證函式存在，但另一個 stored procedure 完全不經過它」，pattern 工具就會失靈，因為它缺的是推理，不是速度。

AWS 在公告裡最有說服力的地方，是它沒有停在 EXECUTE IMMEDIATE 這種表面呼叫，而是一路追到驗證函式、列出五個 regex profile、說明單引號對資料庫引擎的影響，最後再指出另一個 procedure 的 bypass。這種結果不是「多抓到幾個告警」而已，而是把原本要靠人工讀完整個系統才看得出的設計缺陷，直接攤在團隊面前。對工程團隊來說，這比掃描速度重要得多。

反方可能怎麼說

最強的反對意見很直接：AI 掃描容易噪音太多、推理過頭、還會給人錯誤的安全感。安全團隊看過太多工具聲稱自己很聰明，最後卻吐出一堆模糊告警，或者把一條看似合理的攻擊路徑講得頭頭是道，實際上部署環境根本打不通。在這個角度看，傳統 SAST 至少更窄、更可預測，也更容易稽核。

這個擔憂是真的，而且 AWS 也沒有假裝全倉庫掃描是萬靈丹。它的驗證流程刻意把候選結果再讀一次，分開標示已驗證證據與無法驗證的上下文，還附上 severity 與 confidence。這不是要取代 deterministic 工具，而是把它放在該在的位置。可預測的規則檢查，交給規則工具；跨檔案、跨流程、跨授權邏輯的問題，交給能理解整體倉庫的系統。這樣分工才合理。

你能做什麼

如果你是工程師、PM 或創辦人，不要把 repository-wide scanning 當成最後一道門，而要把它當成上游審查層：在大版本上線前、接手陌生 codebase 時、以及安全審查前先跑一次，專門找跨檔案邏輯錯誤、編碼不一致、授權繞過與信任邊界問題。接著把高風險結果交給人做二次確認，因為真正的目標不是用工具取代判斷，而是把人的判斷用在最值得的地方。