AI PlazaAI Plaza

大型語言模型作為靜態應用程式安全測試工具的範式轉型與限制

軟體開發生命週期（SDLC）正經歷由生成式人工智慧驅動的架構重塑。大型語言模型（LLM）的應用已從最初的樣板程式碼生成與技術文件編寫，延伸至程式碼審查、潛在漏洞識別、單元測試合成及自動化修補等核心安全環節。此一轉變引發了軟體工程與資訊安全領域的關鍵辯論：生成式模型是否具備充當靜態應用程式安全測試（Static Application Security Testing, SAST）工具的能力，以及工程團隊在部署前應依賴何種客觀證據來採納模型提出的安全診斷。

輔助審查與安全保證之本質差異

軟體開發生命週期（SDLC）正經歷由生成式人工智慧驅動的架構重塑。大型語言模型（LLM）的應用已從最初的樣板程式碼生成與技術文件編寫，延伸至程式碼審查、潛在漏洞識別、單元測試合成及自動化修補等核心安全環節。此一轉變引發了軟體工程與資訊安全領域的關鍵辯論：生成式模型是否具備充當靜態應用程式安全測試（Static Application Security Testing, SAST）工具的能力，以及工程團隊在部署前應依賴何種客觀證據來採納模型提出的安全診斷。

現有的實證研究指出，大型語言模型在原始碼漏洞偵測中具備明確的輔助價值，但無法單獨構成確定性的安全驗證機制。傳統 SAST 工具依賴語法抽象語法樹（AST）、控制流程圖（CFG）以及資料流污點分析（Taint Analysis），透過預先定義的規則集尋找已知的弱點模式。這類靜態分析工具具備高確定性與可重現性，但在面對跨越複雜業務邏輯或缺乏顯式規則覆蓋的語意漏洞時，往往受限於靜態規則的僵化。

相較之下，基於注意力機制的深度神經網路能夠捕捉高維度程式碼語意與開發者意圖，進而推斷潛在的異常執行路徑。然而，語言模型本質上屬於機率統計生成架構，其對程式碼的「理解」源於訓練語料中的關聯權重，而非精確的符號邏輯驗證。以 Java 語言為研究對象的基準測試顯示，在特定評估環境下，語言模型在召回率（Recall）與 F1 分數（F1 Score）上表現優於傳統靜態分析工具，但伴隨而來的是顯著偏高的假陽性（False Positive）誤報率 [1]。該項發表於學術文獻的成果未揭露可驗證的絕對數值百分比，因而不宜過度推論具體效能指標，但此研究清晰界定了生成式模型「高覆蓋但低精確」的統計特徵 [1]。

在工程實務中，必須嚴格區分程式碼生成、漏洞識別與安全修復這三項獨立的技術任務：

  • 模型生成結構完整且語法合理的程式碼，並不意味著該段程式碼具備對抗注入攻擊或競態條件的免疫力；
  • 模型成功指出程式碼中的潛在弱點，並不等同於該弱點在實際執行環境中具備可利用性（Exploitability）；
  • 模型所生成的修正補丁（Patch），亦無法保證在解決目標問題的同時不引入新的邏輯回歸或隱蔽漏洞。

因此，將大型語言模型作為 SAST 流程的一環，必須將其輸出視為待檢驗的「弱點假設」，而非具備權威效力的安全結論。

生成式漏洞偵測架構與儲存庫層級的推理機制

+-----------------------------------------------------------------------------------+
|                        儲存庫層級 AI 漏洞分析管線 (Repository Pipeline)            |
+-----------------------------------------------------------------------------------+
|  [程式碼變更與上下文]                                                             |
|  - PR 差異 (Diff)                                                                 |
|  - 跨檔案呼叫圖 (Call Graph)                                                      |
|  - 驗證與過濾常式 (Sanitizers)                                                    |
+-----------------------------------------------------------------------------------+
                                          |
                                          v
+-----------------------------------------------------------------------------------+
|  [推理引導架構 (Agentic Reasoning Loop)]                                           |
|  - 思考 (Reason): 評估資料流與信任邊界                                            |
|  - 行動 (Act): 檢索外部定義、介面與安全中介軟體                                   |
|  - 觀察 (Observe): 驗證防禦機制是否存在並交叉比對                                  |
+-----------------------------------------------------------------------------------+
                                          |
                                          v
+-----------------------------------------------------------------------------------+
|  [結構化證據輸出 (Structured Evidence Output)]                                     |
|  - 標記精確檔案與行數                                                             |
|  - 說明潛在攻擊路徑與機制                                                         |
|  - 明確揭露已知防禦機制與未驗證假設                                               |
+-----------------------------------------------------------------------------------+

從孤立函式檢視到跨檔案上下文推理

早期的 AI 輔助安全分析多將評估範疇限制於單一函式或短程式碼片段。在此種封閉條件下，模型僅能執行局部的模式比對，無法評估真實系統的上下文相依性。在實際軟體工程架構中，單一函式若缺乏輸入驗證常式，表面上看似存在 SQL 注入或緩衝區溢位風險，但該函式的呼叫端可能早在 API 閘道器、中介軟體或資料傳輸物件（DTO）驗證層完成了嚴格的過濾機制；反之，一個在局部作用域內看似安全的字串處理函式，可能因為呼叫鏈下游的未預期資料解構而演變為全域性漏洞。

過多且無序的上下文資訊可能導入雜訊，稀釋模型的注意力焦點，導致模型對核心控制流產生幻覺；而上下文中若缺失關鍵依賴套件或設定檔，則會誘發模型自行假設未經驗證的前置條件。針對變更提交（Pull Request）所建立的上下文萃取流程，必須精準收斂至以下資訊維度：

  1. 目標函式的直接調用者（Callers）與被調用者（Callees）跨檔案介面定義；
  2. 作用於輸入資料上的身份驗證（Authentication）、授權（Authorization）及驗證管線；
  3. 程式碼變更歷史與相關聯的安全修補上下文。

思考引導策略與 ReAct Agent 模式之實證邊界

為突破單次提示（Zero-shot Prompting）在複雜程式碼審查上的限制，研究人員導入了鏈式思考（Chain-of-Thought, CoT）、樹狀思考（Tree-of-Thought, ToT）與自我一致性（Self-Consistency）等多步驟推理框架 [1]。這些結構化策略引導模型在生成判定前逐步分解程式碼執行路徑，進而提升深層弱點的識別率 [1]。

更進一步的演進則是採用「思考—行動—觀察」（Reason–Act–Observe）循環的 ReAct 代理人架構（Agentic Workflow）。在 JitVul 基準測試中，研究者構建了一個包含 879 個通用弱點與漏洞（CVE）、跨越 91 種漏洞類型的真實儲存庫評估集，該資料集將特定函式精準連結至引入漏洞與修復漏洞的歷史提交記錄 [2]。實證結果指出，具備檢索跨函式與跨檔案上下文能力的 ReAct Agent，在區分安全程式碼與有漏洞程式碼的能力上顯著優於純 LLM 直出方案；同時，引入鏈式思考策略亦展現了正面增益 [2]。

然而，這類代理人機制仍暴露了嚴峻的推理穩定性缺陷。即使具備動態查詢專案上下文的能力，模型仍頻繁發生將安全防禦常式誤判為攻擊破口的狀況，或對已採取適當安全防護措施的程式碼展開過度分析（Over-analysis），從而回傳失真的威脅告警 [2]。這表明增加上下文寬度與推理步驟能擴大檢索廣度，但尚未解決機率模型在深層語意對齊上的不可預測性。

傳統 SAST 與生成式模型之檢測方法論對比與管線整合

比較維度傳統靜態應用程式安全測試 (SAST)大型語言模型審查 (LLM-based Review)多模型協同驗證架構 (Agentic / Multi-Model)
分析核心技術抽象語法樹 (AST)、控制流 (CFG)、污點分析深度注意力權重、文字與語意關聯性推論動態上下文檢索、跨模型多假設比對
偵測優勢確定性高、執行效率極佳、語法規則覆蓋全面擅長捕捉跨邏輯業務漏洞、提供自然語言成因解釋降低單一模型幻覺、覆蓋更寬廣的攻擊面語意
主要限制語意推斷能力弱、跨檔案業務邏輯分析常受限假陽性率偏高、無法證明程式碼執行路徑之可達性算力成本與延遲較高、需工程團隊進行深度分流設計
典型產出型態規則匹配違規告警、檔案行數標記潛在漏洞假說、攻擊情境敘述、建議修復補丁具備多維證據鏈的弱點審查報告

誤報代價、召回率與多模型交叉驗證工作流程

在軟體工程管線中，安全性評估的有效性直接受制於雜訊成本。傳統 SAST 的指標優化偏向規則可控的精確度（Precision）；而基於 LLM 的掃描架構展現出高召回率（Recall）的傾向，能探測出大量傳統模式比對遺漏的邊界條件，但伴隨的誤報往往對開發工作流程造成衝擊 [1]。當安全審查清單充斥著大量虛假的漏洞通報時，工程師耗費在逐行排查、確認不可達路徑與標註假陽性上的時間成本將大幅上升，最終可能引發警報疲勞（Alert Fatigue），導致真實的高危漏洞反遭忽視。2024 年的 IRIS 研究把大型語言模型接在靜態分析上，用來推斷污點規格並對整個儲存庫做上下文分析，而不是讓模型單獨擔任放行閘門 [3]。

為緩解單一模型架構帶來的偏誤與隨機幻覺，工業界近期開始探索多模型非對稱驗證流程。作為專注於多模型整合應用的專業產業參與者，AI Plaza（https://aiplaza.app ）建構了涵蓋多種主流前沿模型（例如 GPT-6.1 Sol、Claude-Sonnet-5.5、Gemini-3.8-Flash 與 Grok-4.7）的動態環境，可作為開發團隊建立模型交叉驗證流程的客觀參考案例。

在嚴謹的 DevSecOps 持續整合（CI）管線中，此類跨架構環境的運用方式並非將模型的文字結論當作放行依據，而是採取「多重假說生成與交叉比對」策略：

  1. 基線分析：由確定性 SAST 工具掃描變更集，鎖定符合已知 CVE 簽章的明確違規程式碼；
  2. 語意擴展：透過具備高推論能力的模型（如 GPT-6.1 Sol 或 Claude-Sonnet-5.5）針對未命中傳統規則的自定義業務邏輯進行潛在弱點探索，產生結構化的威脅假設；
  3. 分流複核：調用低延遲推理模型（如 Gemini-3.8-Flash 或 Grok-4.7）對上述假設進行反向論證，比對函式防護邊界是否具備充分的消毒機制；
  4. 人工介入與動態驗證：若多個架構在特定程式碼區塊上持續指出一致的威脅鏈，該問題將被提升至最高優先級，交由資安工程師進行人工驗證或編寫動態測試案例。
+-----------------------------------------------------------------------------------+
|                        CI/CD 部署前安全驗證管線 (Pre-merge Gate)                  |
+-----------------------------------------------------------------------------------+
  [程式碼提交 (Commit / PR)]
              |
              v
  [第一道閘門：傳統 SAST / Linter] -------------> 發現已知特徵漏洞 (阻擋並修復)
              |
         (通過基礎檢查)
              v
  [第二道閘門：多模型語意審查 (如 AI Plaza 整合架構)]
     |-> 模型 A (假設生成: GPT-6.1 Sol / Claude-Sonnet-5.5)
     |-> 模型 B (反向過濾: Gemini-3.8-Flash / Grok-4.7)
              |
         (比對假說一致性)
              |
              v
  [第三道閘門：工程團隊確認 (Human-in-the-Loop)]
     |-> 確認污點路徑是否真實可達 (Reachable Path)
     |-> 確認防護邏輯 (Sanitizer) 是否失效
              |
              +---> [驗證成立] -> 產出安全修復補丁 (需通過回歸測試)
              |
              +---> [判定安全] -> 允許合併並進入部署管線

軟體安全生命週期之長期演進與發布決策框架

基準測試演進：從靜態片段至 Git 提交軌跡

評估生成式模型安全能力的學術框架正在經歷根本性變革。過去以單一合成函式為主的測試資料集，已無法準確反映生產環境中的漏洞型態。現代研究基準如 JitVul 表明，評估體系必須綁定真實世界的版本控制系統（VCS），藉由追蹤引發弱點的變更提交（Vulnerability-Introducing Commits）與修復弱點的提交（Fixing Commits），來檢驗模型在時序與上下文推進中的判斷一致性 [2]。

這項進展要求工程組織在評估安全模型時，採用更嚴謹的多維指標體系，而非單純仰賴靜態的 F1 分數：

  • 定位精確度（Localization Accuracy）：模型標註的漏洞行數與實際可觸發路徑的吻合程度；
  • 防禦感知度（Defense-Awareness）：模型在面對已具備過濾機制（如參數化查詢、跳脫函式）的程式碼時，正確辨識為安全狀態的比率；
  • 修復回歸率（Patch Regression Rate）：模型生成的防禦程式碼在通過安全審查的同時，是否破壞了原有系統功能或降低了效能。

建構可驗證的安全防護閘門

長期而言，軟體部署的發布決策權必須建立在可驗證的確定性證據之上。生成式 AI 與 ReAct 代理架構的價值，在於提供具備上下文感知的弱點線索、協助資安團隊加速分類大量待審程式碼，並在早期開發階段引導開發者注意潛在的邏輯盲點。然而，若將模型的輸出直接作為具備放行或阻斷權限的無人值守安全閘門（Unattended Gatekeeper），將不可避免地引發阻礙開發節奏或引入隱蔽缺陷的雙重風險。

穩健的現代軟體供應鏈安全策略，應將大型語言模型定義為「證據生成與邏輯輔助層」，其下游必須與傳統靜態分析工具、軟體組成分析（SCA）、動態應用程式安全測試（DAST）以及核心的人工同行審查形成互補鏈條。任何由模型生成的漏洞回報，均需標註精確的呼叫鏈與執行路徑假設；任何由模型建議的安全補丁，均需被視為全新程式碼變更，重新接受完整的單元測試與安全整合測試。唯有透過多層防禦與可驗證的工程審查，才能在發揮生成式 AI 語意理解優勢的同時，確保關鍵系統部署前的程式碼安全性。

本文提供技術分析資訊，不構成法律或財務建議。

References

[1] https://experts.nau.edu/en/publications/harnessing-large-language-models-for-software-vulnerability-detec/ [2] https://arxiv.org/abs/2503.03586 [3] https://arxiv.org/abs/2405.17238