靜態分析遇上大語言模型：精確度、成本與持續更新的三重挑戰

開端：靜態分析與語言模型各自解決什麼問題

靜態分析擅長以可重複執行的規則掃描程式碼；大型語言模型則能協助閱讀告警上下文、整理修補建議與解釋程式行為。兩者結合的價值不在於宣稱某一方必然勝過另一方，而在於把告警分流、驗證與人工判斷串成可追溯的流程。

原文曾列出特定論文、模型與工具的 F1 分數，但未附可核對的研究連結、資料集與實驗設定。這類跨模型、跨工具的單一數字容易被誤讀為通用結論，因此已移除。評估應回到組織自己的語言、框架、規則集與已確認漏洞。

靜態分析的輸出是需要研判的告警，而不是已確認的漏洞。以 CodeQL 為例，官方將其定位為語意程式碼分析引擎，可把程式碼當成資料來查詢，並尋找同類型的漏洞變體。它適合建立可檢視、可重跑的查詢基線。

語言模型可在告警出現後協助彙整資料流、找出相關函式、說明規則觸發原因，或提出待人工驗證的修補方向。不過，模型輸出仍可能遺漏環境設定、框架慣例或執行期條件，因此不宜直接作為關閉告警或合併修補的唯一依據。

第一步是用既有靜態規則建立基線，保留規則版本、掃描時間與原始告警。第二步由工程師或受控的語言模型補充程式脈絡，將告警分類為需立即處理、需補證據或可合理排除。第三步由程式碼擁有者確認判定並留下理由。第四步把已確認結果回饋到規則、測試或審查指引，避免同類問題反覆出現。

評估時至少分開看三件事：已確認問題是否被找出、無效告警花掉多少審查時間、修補是否通過測試。若沒有同一套資料集與人工標註，便不應把不同產品或模型的分數排成高低排名。

成本不只包含模型呼叫，也包含建立程式碼脈絡、人工審查、誤判後重工與規則維護。先從單一服務或少量高風險規則做試點，較能量出實際工作量。程式庫、框架與模型更新後，應重跑代表性測試案例，而不是假設原本的判定仍然成立。

靜態分析提供可重複的偵測基線，語言模型可協助閱讀與分流，但兩者都不能跳過驗證。最實用的起點是選擇一個範圍清楚的程式庫或服務，建立告警到人工確認的閉環，再依已確認的結果逐步調整規則與工作流程。