開發者會在他們編寫的程式碼中留下個人印記。命名選擇、縮排模式、常用的 API，以及循環的結構或指標的處理方式，都帶有個人習慣的痕跡。多年來，研究人員一直利用這些風格特徵來識別匿名程式碼樣本的作者，有時準確率甚至令人驚訝。如今，馬薩諸塞大學達特茅斯分校的研究團隊正將同樣的想法應用於另一個問題：風格模式能否揭示哪些程式碼可能包含安全漏洞？

他們的模型名為 VulStyle，將編碼風格與程式碼本身視為一種訊號。其前提是，危險的編碼習慣會聚集出現。例如，一個開發者如果在一個函數中編寫了不一致的緩衝區處理程式碼，那麼他很可能在其他地方也使用相同的程式碼。混合的命名規範、不尋常的嵌套以及不規範的指標使用都可能與導致記憶體損壞以及 C 和 C++ 中其他經典缺陷的 bug 相關。

程式碼風格漏洞檢測 VulStyle 的方法（資料來源：研究論文）

從另一個角度看一個老問題

靜態分析器幾十年來一直在分析存在漏洞的程式碼。近年來，機器學習方法則更著重於程式的標記（token），例如關鍵字和運算符，或用於捕捉資料和控制流經函數的圖結構。 VulStyle 在此基礎上增加了第三層分析，取表達式類型、聲明模式和語句結構等風格特徵，並將它們與精簡的程式碼語法樹和原始原始程式碼結合。

該模型首先使用涵蓋七種程式語言的約 490 萬個函數進行預訓練，然後在五個廣泛使用的漏洞檢測資料集上進行微調。在某些基準測試中，結合風格、結構和標記的偵測器效能優於僅依賴標記的偵測器。作者指出，風格和結構相輔相成：結構資訊錨定了程式碼的功能，而風格訊號則反映了開發者的編寫習慣。

數字背後的基準問題

同一篇論文指出了該領域一個更深層的問題。 VulStyle 在某些資料集上表現出色，而在其他資料集上則表現不佳。在旨在彌補早期漏洞資料集缺陷的基準測試資料集 DiverseVul 上，該模型的 F1 分數急劇下降。作者引用了最近的研究，這些研究表明，一些流行的漏洞檢測基準測試包含噪音標籤，這會誇大報告的效能。近期在相關機器學習安全領域的研究也顯示出同樣的模式。 2026 年的一項研究發現，即使使用相同的標準化特徵格式，基於機器學習的惡意軟體偵測器在某個資料集上訓練後，在另一個資料集上進行測試時也經常出現問題。

對實踐者而言，這種差距才是更有價值的發現。它表明，安全機器學習領域中那些引人注目的準確率數據，往往更反映了數據集建構方式的問題，而非實際的檢測能力。在某個基準測試中表現良好的模型，在來自不同來源的程式碼上，其表現可能截然不同。

安全團隊需要回答的問題

漏洞檢測的重要性日益凸顯。雲端安全聯盟最近的一份簡報指出，漏洞發現與成功利用之間的時間窗口正在不斷縮短，這在一定程度上是由於能夠大規模發現零時差漏洞的自主人工智慧系統所致。

有兩個明顯的限制。首先是對抗性問題。作者認為，風格感知偵測更難規避，因為攻擊者需要同時協調跨詞法單元、結構和風格模式的變更。但他們並未對此進行實證檢驗。一個有決心的攻擊者可以透過格式化程式運行存在漏洞的程式碼，重命名變量，並重構表達式，來檢驗基於風格的訊號是否仍然存在，這項工作仍有待進行。

第二個限制對於關注2026年軟體編寫方式的人來說更為迫切。風格計量訊號依賴於個體風格的存在。 LLM產生的程式碼往往統一、格式規範，並且缺乏個人習慣。作者承認，風格計量在模板化和自動產生的程式碼中失效。隨著LLM輔助開發在生產程式碼庫中日益普及，開發者風格作為有效訊號的視窗期可能正在縮小。

實際意義

VulStyle目前仍處於研究階段。風格模式蘊含風險訊息，將其與結構和詞彙特徵結合，可以提高對某些類型漏洞的偵測能力。這項工作提醒我們，訊號來源很重要，資料集的選擇更為重要，任何單一基準測試能夠反映生產環境的假設都值得商榷。

資料來源：https://www.helpnetsecurity.com/2026/05/05/research-code-stylometry-vulnerability-detection/