2026-05-12 的 Tempest Security Daily 收到三條同向訊號，主題高度收斂：「應用程式安全」這個老議題正在被 AI 與 shift-left 兩股力量同時改寫。一邊是 Qualys 把 AI Code Security 整合進旗艦平台 ETM、為新一代發現 (findings) 設計頭等公民的資料模型；另一邊是 ZDNET 兩篇連續報導，分別從「停止把 bug 出貨」與「打補丁跑步機已經跑不動」兩個角度，宣告傳統「修補式」AppSec 的時代正在結束。三條訊號合起來指向同一個結論：未來能拿到資安預算的，不再是「掃完還能寫出多少待修報告」的工具，而是「能在 bug 被寫進 main 之前就攔下來」的工具。本期以 10 則摘要從工具生態、資料模型、shift-left 經濟學、攻擊面、到台灣團隊的落地路徑完整拆解。
主訊號 A：Qualys 把 AI Code Security 拉進 ETM——新一代 findings 需要新一代資料模型
Qualys 發表《Bringing AI Code Security into Qualys ETM》，宣告把 AI 驅動的程式碼安全納入旗艦 Enterprise TruRisk Management 平台。文章開門見山指出 AI 驅動的程式碼安全正在成為「真實的產品類別」：Anthropic 的 Claude Code Security 與 OpenAI 的 Codex Security 是領頭羊，後續還會有更多玩家加入。這些工具在「對原始碼推理」這件事上的深度，已經超越傳統 SAST 的能力邊界——傳統 SAST 主要靠規則匹配與資料流追蹤，AI 工具則能理解程式碼的意圖、識別不在規則庫裡的邏輯缺陷。對企業而言，這條訊號代表「下一個資安採購週期」的選項清單會被重寫。原文：[https://ift.tt/5NUZVLQ]
主訊號 B：ZDNET——把 bug 攔在出貨前，「預防式安全」要取代「修補式安全」
ZDNET 的《Stopping bugs before they ship: The shift to preventative security》直接把問題拉到產品開發流程的源頭：傳統 AppSec 的運作模式是「軟體寫完 → 掃描 → 報出一堆漏洞 → 排優先級 → 慢慢修」，這條鏈在 AI 加速程式碼產出的時代已經塞不住輸出量。文章主張產業需要把資安能量從事後修補轉向事前預防——也就是讓 bug 連 commit 都進不了 main branch。這個敘事與 Qualys 在同日的發表完美對接：當程式碼產出的速度因為 AI 而提升一個數量級，「修補式」的傳統做法只會讓待修清單越長越無望。原文：[https://ift.tt/O4MpiHc]
主訊號 C：ZDNET——「打補丁跑步機」已經跑不動，傳統 AppSec 不再足夠
ZDNET 的姊妹篇《The patching treadmill: Why traditional application security is no longer enough》用「跑步機」這個比喻精準描述了當今 AppSec 團隊的困境：補丁打得越快，待修清單成長得越快，永遠跑在後面。這條訊號與「預防式安全」互為表裡——前者描述問題，後者提出方向。對企業資安主管而言，這代表必須開始向高階主管解釋為什麼「越掃越多漏洞」不是工具失敗，而是工具與威脅模型脫鉤；真正的解方是把資安活動往左移到 IDE、PR review、與 CI 入口，而非繼續在「漏洞積壓」這座大山上撥沙。原文：[https://ift.tt/4KCQZ7W]
觀察一：三條訊號交集處是同一個論點——AppSec 的重力中心正在前移
Qualys、ZDNET 兩家不同立場（前者是工具廠、後者是媒體分析）在同一天發出方向一致的訊號，本身就是一個值得記錄的市場時刻。三條訊號的共同論點是：應用程式安全的重力中心，正在從「上線後掃描、發報告、排修補」往前移到「程式碼成形的當下就介入」。Qualys 把 AI Code Security 視為新一代 findings 來源並重新設計資料模型；ZDNET 兩篇則從產業敘事角度宣告舊典範的疲態。對台灣的 CISO 與資安主管，這意味著「明年的工具預算審查」會被要求回答一個新問題：你現在的 AppSec 工具鏈，是站在 shift-left 那一邊，還是仍然停在 patching treadmill 上？原文：[https://ift.tt/5NUZVLQ]
觀察二：AI Code Security 不是「更好的 SAST」，它在解的問題本身就不一樣
Qualys 在文章中明確區分了 AI 程式碼安全工具與傳統 SAST 的能力邊界：傳統 SAST 擅長的是「在已知模式上做精確匹配」——SQL injection、command injection、XSS 這類有清楚 source/sink 的問題；AI Code Security 則擅長「推理程式碼意圖」——例如商業邏輯漏洞、權限模型錯配、API 使用方式的不安全組合，這些都是傳統規則庫無法覆蓋的盲區。把這兩類工具當作替代關係去比較會犯典型的「拿香蕉比香蕉皮」錯誤；正確的看法是它們各自佔據 findings 光譜的不同段落，未來會在企業資安平台中並存運行。對工具選型者的提醒是：不要用 SAST 的 KPI（false positive rate、規則覆蓋率）去衡量 AI Code Security 工具，前者衡量的是「精準度」，後者更該衡量的是「能不能發現傳統工具完全看不到的問題」。原文：[https://ift.tt/5NUZVLQ]
觀察三：當 findings 來源變多，「資料模型先行」比堆積更多偵測重要
Qualys 文章用「first-class data model」這個詞描述他們的設計取向——這是值得任何在做 ASPM / vulnerability management 平台選型的團隊細讀的伏筆。當 findings 來源從傳統 SAST 一條，擴張到 AI Code Security、IaC scanning、container scanning、secret scanning、SCA 等多條，每條來源的 finding schema 都不一樣（嚴重程度的定義、位置的指涉方式、修補建議的粒度），如果平台底層沒有一套統一的資料模型先做收斂，企業就會掉進另一種噩夢：每個工具自己有一份待修清單，沒有全公司的單一風險視圖。Qualys 在文章標題就把「資料模型」放在「AI 能力」前面強調，這個排序透露的訊息是：未來幾年贏面比較大的不是偵測能力最炫的廠商，而是把多源 findings 收斂成單一決策入口的廠商。原文：[https://ift.tt/5NUZVLQ]
觀察四：預防式安全的經濟學——「左移一格」就把成本除以一個數量級
ZDNET 的預防式安全敘事背後是一個 AppSec 界長年共識的經濟學論點：bug 越靠近開發階段被發現，修補成本越低；越接近上線甚至上線後，修補成本可能高出兩到三個數量級。過往這條論點之所以推不動實務，是因為「左移」需要工程師在 IDE / PR 階段就能拿到夠快、夠準的回饋——而傳統 SAST 在這個階段往往要嘛太慢，要嘛 false positive 多到工程師會直接忽略。AI 程式碼安全在這條曲線上提供了新可能：模型可以在工程師寫完一個函式的瞬間做出帶上下文的安全反饋，且這個反饋不是「規則 #1234 命中」這種工程師看不懂的字串，而是用自然語言解釋的意圖判斷。這也是為什麼 Qualys 與 ZDNET 兩篇文章會在同一天指向同一個方向——技術條件齊全了，產業敘事才追上來。原文：[https://ift.tt/O4MpiHc]
觀察五：補丁跑步機跑不動的真正成因——是「修補速度」追不上「程式碼產出速度」
ZDNET 對 patching treadmill 的描述如果只停留在「補丁太多」，會錯失問題的真正成因。真正讓 AppSec 團隊跑不動的，是兩條曲線的剪刀差：一條是「修補速度」，受限於工程資源、release window、向後相容性；另一條是「程式碼產出速度」，因為 AI 編碼助手、low-code 平台、microservice 拆分而急速擴張。當第二條曲線的增速比第一條快，待修清單就只會越拉越長，永遠不可能歸零。這條剪刀差的解法不在「更努力地修」（第一條已經受限）也不在「掃得更勤」（會讓清單長得更快），而在於把第一條曲線斜率改變——也就是預防式安全主張的「攔在前面」。對資安主管而言，看懂這條剪刀差，才能在向高階主管報告時不被「為什麼漏洞越來越多」這類問題卡住。原文：[https://ift.tt/4KCQZ7W]
觀察六：當 findings 來源前移，SOC / VM 團隊的工作邊界也會被重新切分
如果預防式安全與 AI Code Security 成為主流，原本由 SOC 與 Vulnerability Management 團隊負責的「事後 findings分類、排優先、追蹤修補」工作量會被前移到開發階段——但這不代表 SOC / VM 團隊的工作消失，而是工作邊界重新切分。新邊界的關鍵問題是：哪些 findings 該由 IDE 階段攔下、哪些該進 PR review、哪些要等到 staging 才出來、哪些是上線後才能被監控發現？傳統做法是「全部都進 VM 平台、用單一儀表板看」；新做法則必須在資料模型上明確標記每條 finding 的「應該被攔下的最早階段」並由各階段負責人 own。對企業組織架構而言，這意味著 AppSec 工程師（負責左移）與 SOC / VM 工程師（負責右側監控與處置）的職責定義需要重寫，否則容易出現「兩邊都以為對方在處理」的灰色地帶。原文：[https://ift.tt/O4MpiHc]
觀察七：台灣場景的差異——預防式安全在中型工程組織的落地路徑
把這三條訊號收斂回台灣現場，三個族群會看到不同的落地路徑：(1) 台灣 SaaS / 新創——競爭壓力大、團隊規模小，最該直接跳過「先建 VM 平台再來談 shift-left」的繞路，直接從 IDE / PR 階段的輕量 AI Code Security 工具開始試水，把資安能量集中在「攔在前面」；(2) 系統整合商與外包公司——客戶通常買的是交付物而非過程，需要把預防式安全的成果（例如 PR 階段的 finding 統計、入庫前的攔截率）寫進交付文件，讓客戶看見資安投資的價值；(3) 大型企業與金融業——已經有 SAST、DAST、VM 平台投資，但這些工具大多在 patching treadmill 上跑，需要先做 findings 資料模型的整合，再把 AI Code Security 作為新一條輸入接入既有平台，而不是另外買一套並行運行。三類團隊都不需要等到「等明年預算」才行動——光是把這三條訊號帶進下一次資安週會，就能讓策略討論往前一步。原文：[https://ift.tt/5NUZVLQ]
今日行動清單：給工程主管與資安負責人
彙整三條訊號，建議讀者本週內可採取以下五項具體動作：(1) 盤點目前 AppSec 工具鏈在「shift-left 光譜」上的位置——把每個工具標註它能在 IDE / PR / CI / staging / production 哪一階段攔下問題，看清楚到底有沒有左移；(2) 把「Claude Code Security 與 OpenAI Codex Security」這個類別納入下個採購週期的評估範圍，至少安排一次 PoC 把它與現有 SAST 並排試跑，比較能發現的問題類型差異而非單純看誤報率；(3) 為 AppSec 與 VM 團隊重畫一張責任地圖，標註每類 finding 的「最早應該被攔下的階段」與對應 owner，把灰色地帶寫清楚；(4) 在向高階主管報告 AppSec 績效時，加入「左移指標」——例如進入 PR 階段前被攔下的 finding 比例，而非僅看漏洞積壓量；(5) 把這份《Bringing AI Code Security into Qualys ETM》與 ZDNET 兩篇分享給工程團隊負責人，作為下一次工程資安策略對齊會議的共同閱讀材料。三條原文連結：[https://ift.tt/5NUZVLQ]、[https://ift.tt/O4MpiHc]、[https://ift.tt/4KCQZ7W]