過去半年以來，LLM（Large Language Model, 大型語言模型）的應用方式蓬勃發展，尤其是以AI Agent的形式為軟體工程帶來深遠影響。隨著相關能力持續成熟，LLM 與 Agentic AI 在安全軟體開發（Secure Software Development）領域的應用價值也持續提升。
然而，無論模型能力如何進步，基於LLM的AI Agent仍具有機率特性。即使具備強大的分析與推理能力，其輸出仍具有非確定性（non-deterministic），可能產生幻覺（hallucination），也可能忽略看似簡單的功能、程式邏輯或潛在問題。
另一方面，靜態分析（Static Analysis）長期以來即是從原始碼中識別軟體缺陷與安全問題的重要技術。當 LLM 也開始具備程式碼分析能力後，兩者在缺陷偵測上的差異為何？又應該如何在軟體開發與資安治理流程中配置兩者的角色？
對多數使用者而言，LLM（大型語言模型）就像一個"黑箱"。將程式碼搭配提示詞（Prompt）輸入模型後，LLM 會針對全部或部分內容進行分析並產生回應。部分結果可能相當精準，但也可能出現錯誤或遺漏。提示詞或程式碼內容如何影響分析結果並不容易預測，不同 LLM、不同模型版本，以及提示詞與輸入內容的長度，都可能造成結果差異。
筆者嘗試以LLM對 1,000 行程式碼左右的小型專案進行測試，LLM 能產生相對完整且品質良好的分析結果；然而，當程式規模擴大至 100 萬行時，其品質便難以維持。該LLM建議：單一檔案約 3,000 行是較適合處理的規模；面對更大型的程式碼庫，LLM則建議採用靜態分析工具。除此之外，LLM 受限於其運作特性，對需要進行跨檔案分析的問題也較不擅長，例如A檔案中的函式呼叫B檔案中的函式，若風險判斷涉及跨檔案的資料流，LLM的分析難度便會進一步提高。
因此，在軟體開發流程中，尤其涉及高可靠性（High-Integrity）軟體時，不宜將 LLM 作為主要或唯一的分析依據。這並不代表 LLM 不適合導入軟體開發，而是更適合作為測試與驗證流程中的其中一項分析來源，與既有工具及人工審查機制搭配使用，而非作為軟體品質與安全判斷的唯一依據。
除了分析結果具有不確定性，目前 LLM 的使用成本也限制了其在大型軟體專案中的高頻率應用。例如，在一個20 萬行程式碼的專案中，若每次程式碼異動後，都要求 LLM 逐行檢查所有程式碼是否存在 MISRA 規範違規或未定義行為（Undefined Behavior），在成本與執行效率上仍不具實務可行性。
相較於 LLM，靜態分析（Static Analysis）具有更高的確定性、可信度與可預測性，因此更適合整合至定義明確的軟體開發流程，尤其適用於汽車、航空、醫療設備等具高可靠性要求的領域。靜態分析工具亦可針對特定開發流程進行工具資格認證（Tool Qualification），藉此掌握工具的運作方式、可能的失效情境，以及分析結果在何種條件下具有可信度。
靜態分析工具回報的問題主要可分為兩類：程式設計規範（Coding Style）問題，以及未定義行為（Undefined Behavior）警告。程式設計規範的檢查相對單純，例如 MISRA-C 2025 Rule 2.3 規定，專案中不得存在未使用的型別宣告。這類問題通常能以較高的可靠度進行偵測，關鍵在於判斷結果不依賴程式實際可能經過的執行路徑。
然而，當警告涉及原始碼中可能的執行路徑時，分析複雜度便會大幅提升。例如 MISRA-C 2026 Rule 2.2 在標準中被列為「不可判定」（Non-decidable），代表從理論上而言，任何演算法或靜態分析工具都無法在所有可能情況下，自動且完整地驗證這項規則。
若要找出所有違反此規則的情況，靜態分析工具必須分析原始碼中的所有可能執行路徑，並從中識別潛在錯誤，此時便會面臨「狀態爆炸」（State Explosion）問題。以 Linux Kernel 為例，其可能存在的程式執行路徑數量，甚至被形容為超過宇宙中的原子總數。
為處理龐大的程式狀態空間，靜態分析工具會採用「抽象直譯」（Abstract Interpretation）技術，對程式可能產生的狀態進行分析。當程式規模持續擴大，例如超過 10 萬行程式碼（Lines of Code, LOC）後，已難以完整計算所有可能的狀態，因此分析工具必須透過摘要（Summary）及相關最佳化技術降低分析複雜度。
這也代表靜態分析仍可能遺漏實際存在的問題，形成「漏判/偽陰性」（False Negative）。因此，分析結果未發現錯誤，並不能直接代表原始碼不存在任何問題。反之亦然，靜態分析也可能因採取過度近似（Over-approximation）的分析方式，回報實際上並不存在的問題，此類情況稱為「誤判/偽陽性」（False Positive）。
誤判本身通常不直接構成安全問題，但仍需要進一步評估並留下紀錄。其主要影響在於增加開發團隊的處理負擔；當誤判數量過多時，可能造成警告疲勞（Alert Fatigue），進而降低開發人員對分析結果的關注程度及對檢測工具的信任。從軟體開發流程與治理角度而言，這種情況相當不健康。
在成本與執行效率方面，靜態分析通常也較 LLM 更適合高頻率執行。每次程式碼異動後，都可在開發環境或 CI/CD Pipeline 中自動執行靜態分析。依程式碼庫規模不同，分析通常可在數分鐘至數十分鐘內完成，並快速將結果回饋至開發流程，使問題能在開發階段即時被識別與處理。
LLM 與靜態分析工具並非相互取代，而是可透過兩階段的協作模式，分別發揮各自優勢：
1. 每次程式碼異動皆執行靜態分析，並取得完整的分析結果。
2. 由 LLM 解讀靜態分析結果，並提出相對應的修正建議。
3. 由開發人員審查修正內容，確認後整合至程式碼。
4. 持續重複上述流程，形成常態化的檢測、分析與修正機制。
定期使用 LLM 檢視應用程式的特定區塊並提出改善建議，尤其適合應用於靜態分析較難涵蓋的問題。例如，評估應用程式是否可能面臨阻斷服務（Denial-of-Service, DoS）攻擊風險、密碼等敏感資訊在儲存前是否經過適當的加密保護，以及近期程式碼異動是否偏離既有的系統架構定義與設計原則。
這樣的協作模式，保留了靜態分析的優勢，並利用LLM 的高階理解能力來提高精準度，還包含適性建議，大幅改善既有作業的缺點。
此外，原有的開發機制及已完成工具資格認證（Tool Qualification）的靜態分析工具仍可持續使用，企業透過 LLM能在可靠的基礎上，更順利地通過功能安全（Functional Safety）與相關安全認證。
對於尚未將大型語言模型（LLM）導入軟體開發流程的組織而言，值得進一步評估其應用方式與效益。LLM 可為軟體開發與安全分析提供有價值的輔助資訊，並協助開發團隊提升問題理解與處理效率。
關於靜態分析結合 LLM 的實際應用流程，可參考相關示範影片，進一步了解兩項技術如何整合至軟體開發與安全檢測流程。
若對 CodeSonar 有興趣歡迎留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/codesonar-product