靜態代碼分析工具(搞懂靜態代碼分析，看這文就夠了)

作者 | 賴建新

來源 | 鑒釋

封圖 | 東方IC

什么是靜態代碼分析？

靜態代碼分析是指在不實際執行程序的情況下，對代碼語義和行為進行分析，由此找出程序中由于錯誤的編碼導致異常的程序語義或未定義的行為。通俗的說，靜態代碼分析就是在代碼編寫的同時就能找出代碼的編碼錯誤。你不需要等待所有代碼編寫完畢，也不需要構建運行環境，編寫測試用例。它能在軟件開發流程早期就發現代碼中的各種問題，從而提高開發效率和軟件質量。

靜態代碼分析現在面臨最大的難題是什么？

現代軟件系統規模越來越大，代碼行數從數萬或數十萬行規模增長到數千萬行；系統復雜度也越來越高，從傳統的單機系統變為分布式系統，同構系統變為異構系統；而且軟件開發的編程語言也從使用單一的語言發展為多種語言協同開發。這些變化都對SAST工具帶來了巨大挑戰。

SAST工具首先必須要有能同時檢測多種語言代碼及其互操作的能力，例如要檢測Android應用程序的漏洞，SAST除了要能支持檢測C/C++和Java語言外，還必須支持JNI，才能有效的檢測Byte Code和Native Code互操作導致的各類問題。

此外對靜態程序分析工具還有這些維度的評價指標：

一是漏報率和誤報率；漏報率或誤報率過高會導致SAST工具的實用性和有效性顯著降低，無法有效提高軟件開發效率和軟件質量。

二是檢測規則是否容易擴展及按用戶特定需求定制；除了支持常見的工業安全編碼標準外，SAST工具應該還能支持用戶自定義的編碼規范和業務邏輯規則。

三是分析所需的時間和資源占用；如果SAST工具一次掃描所需的時間太長或者占用內存資源太大，將難以和程序員日常的開發工作和流程整合，進而無法起到提高開發效率和軟件質量的目的。

在編譯器技術領域，什么是抽象語法樹 （AST）？

抽象語法樹是程序源代碼結構的樹狀表示。程序源代碼經過詞法分析器（Lexer）得到各種不同種類的單詞（Token），再由語法分析器（Parser）分析和語法檢查后得到抽象語法樹(AST)。抽象語法樹的根節點表示整個程序，內部節點是抽象語法結構或者單詞。AST的核心在于它能與輸入源代碼中的各個語法元素一一對應。對于 附圖1 的C語言源代碼，它對應的AST如 附圖2 所示。

附圖1：while循環的C代碼

附圖2：while循環的AST

什么是中間表示（IR）？

IR是編譯系統或程序靜態分析系統的核心，它是源程序在編譯器或者靜態分析器的內部表示，所有的代碼分析，優化和轉換工作都是基于中間表示進行的。IR一般由AST經過類型檢查和規范化后轉換而來。對編譯器來說，它在中間表示上做完分析和優化工作后，將中間表示轉換為其他語言源代碼或者匯編/目標語言。

而靜態分析工具則會在中間表示上進行語義或未定義的行為分析，然后結合各種預定義規則或者用戶自定義規則檢測源代碼的各種漏洞或缺陷。

在現代編譯器和靜態分析工具中，通常會使用控制流圖（Control Flow Graph，CFG）來表示程序的控制流，使用靜態單賦值（Static Single Assignment，SSA）來表示程序中數據的使用-定義鏈（Use-Def Chain），這兩個關鍵數據結構都是AST中沒有的。對于附圖1 的C語言源代碼，它對應的IR如 附圖3 所示。

附圖3：while循環的IR

查找源代碼缺陷時，為什么在IR級別上進行靜態代碼分析比在AST級別上準確性更高？

根據前面的描述，對AST進行類型檢查和規范化，即可轉換為IR。AST上適合做一些代碼規范的檢查，例如標識符命名規范檢查或常見的編碼慣用法檢查，AST上的檢查一般使用圖模式匹配的方法。

而IR上能進行更深層次的流敏感分析，過程間分析，上下文敏感分析和對象敏感分析等等，從而實現各種更高難度的程序漏洞檢查。相比IR，AST有這些明顯的劣勢：AST不能很好的表示控制流和數據流，AST做為輸入源代碼的樹狀表示，它本身就缺乏表示控制流和控制流的方式。AST是非規范化的，相同語義的結構如果寫法不同，它們在AST上的表示也會不同。例如C語言中使用for、while和if/goto表達的循環結構，它們的AST是不一樣的；而轉換為IR后產生的控制流圖是一樣的。規范化使得對程序語義的分析更容易，使得檢測精確度更高。

IR級別上的代碼分析還能提供哪些其它好處？

一個最明顯的好處是通常AST都是輸入語言相關的，比如C程序有對應的C AST，Java程序有對應的Java AST；而IR一般來說是輸入語言無關的，不管是C源代碼、Java源代碼或者其他語言的源代碼，它們都能被轉換到一個語言無關的IR上。

我們將各種分析和檢測引擎放置在IR上，那么相同的分析引擎和檢測引擎，搭配不同語言的檢測規則，就可以實現對不同語言編碼缺陷的檢測。使用IR的另一個好處是相對AST，IR會更穩定。

例如現在C++規范每3年就會出一個新標準，引入新的語法結構，意味著AST每3年就會出現新的節點需要處理。如果將分析引擎建立在AST基礎上，那么分析引擎也需要每3年更新一次處理這些新節點；而如果將分析引擎建立在IR基礎上，則僅需將新的AST節點轉換為已有的IR結構或操作，從而保持分析引擎基本不受影響。

愛科識（Xcalscan）

綜合來看，Xcalscan的優勢主要來自以下三方面：

一是，創新的可擴展的流敏感（Flow Sensitive）、對象敏感（Object Sensitive）、上下文敏感（Context Sensitive）的分析引擎。流敏感是指分析引擎會區分程序變量在不同執行路徑下的定義和使用情況，并僅對會導致錯誤的執行路徑報告警告；對象敏感是指分析引擎能區分不同的對象實例或同一個對象不同的成員，僅對會導致錯誤的對象或對象成員報告警告；上下文敏感是指分析引擎能區分相同函數在不同調用點的上下文，僅對會導致錯誤的調用點報告錯誤。Xcalscan通過綜合使用靜態單賦值（SSA），虛擬變量（Virtual Symbol），基于SSA的別名分析（Alias Analysis）和過程間分析（Inter-Procedure Analysis）來實現了分析引擎的流敏感、對象敏感和上下文敏感。

基于這個分析引擎，Xcalscan能有效的報告出每個問題產生的源頭在哪里，數據經過了什么樣的路徑和函數調用點到達了最終問題會顯現的地方。Xcalscan圖形化的用戶界面會以流圖（Flow Graph）的方式，展示問題是如何從源頭引入，一步步推進，并最終會在什么位置觸發。

二是，綜合了資源建模、數據流分析、符號執行和形式化驗證等多種方式的漏洞檢測引擎。在應用規則檢測程序漏洞時，Xcalscan會綜合使用數據流分析，符號執行和形式化驗證的方式檢測程序中是否存在違反該規則的代碼。

三是，可擴展的用戶自定義規則引擎。Xcalscan定義并開放了分析和規則檢查API用于開發用戶自定義規則。用戶可以通過調用相關API指定用戶代碼或第三方庫函數的屬性及副作用，前置或后置條件，檢查規則等。Xcalscan規則引擎會自動讀取用戶規則并附加于代碼的中間表示上，在完成程序靜態分析后，規則引擎會判斷用戶規則中的前置或后置條件、檢查規則等是否滿足并給出警告。

綜上所述，Xcalscan作為新一代的SAST工具，它從設計之初就能支持多種語言及不同語言間的互操作，目前已經支持C/C++，Java和JNI。后續版本將支持Javascript和Python等更多的程序設計語言。Xcalscan掃描結果的漏報率和誤報率都較低，掃描所需的處理器和內存資源少，且支持用戶自定義規則。

本文作者是鑒釋靜態代碼分析工具愛科識（Xcalscan）的研發主管，當前的工作是帶領鑒釋核心開發團隊開發下一代的程序靜態分析工具（SAST），這個分析引擎是鑒釋靜態分析工具工具產品的核心組件。分析引擎將用戶輸入的源代碼轉換為編譯器中間表示；基于中間表示進行流敏感分析，過程間分析，上下文敏感分析和對象敏感分析；在各種分析的基礎上結合符號執行和形式化驗證等手段，檢測用戶輸入程序是否存在各類缺陷或者安全漏洞，是否存在違反各類源代碼安全編碼規范或用戶自定義規則的代碼。

作者簡介：賴建新有著豐富的編譯器優化和高級程序靜態分析的經驗。在2006年獲得清華大學計算機科學碩士學位之后，他加入了惠普的編譯器團隊，先后擔任編譯器開發工程師，編譯器后端架構師和項目經理等職位，參與了開源編譯器Open64，HP-UX產品編譯器aCC和HP Non-Stop編譯器項目，并于2018年加入鑒釋。

?訊飛智能語音先鋒者：等到人機交互與人類交流一樣自然時，真正的智能時代就來了！

?蘋果官網下架iPhone 8全系；阿里推出“阿里云會議”；深度操作系統20BETA發布|極客頭條

?新iPhone SE賣3299元起，香不香？

?深挖谷歌DeepMind和它背后的技術

?從Spring Cloud到Service Mesh，微服務架構治理體系如何演進？

?面試造飛機系列：看架構師如何設計微服務接口