眾所周知，高級靜態分析工具擅長發現程序中的一般缺陷。借助自定義的屬性檢查器，最終用戶還可以擴展它們，以查找特定應用程序特有的特定于域的錯誤。

先進的靜態分析工具使用復雜的全程序、路徑敏感技術來發現深層語義問題，包括安全缺陷和安全漏洞。這些工具識別的幾個缺陷可以在CWE/SANS前25個最危險的編程錯誤中找到，其中列出了為了降低安全風險而要避免的最重要的錯誤。

具體來說，開箱即用的高級靜態分析工具可以找到通用編程缺陷。來自靜態分析工具的典型通用報告可能會顯示警告，例如未初始化的變量、緩沖區溢出、無法訪問的條件和無法訪問的調用等;但是，并非所有安全漏洞或安全錯誤都是由一般問題引起的。許多缺陷是特定應用所獨有的。

這些工具的一個經常被低估的方面是它們是可擴展的，因此通常也可以對其進行配置或編程以查找違反特定于域的規則的情況。因此，如果開發團隊有自己的內部規則來使用專有API，或者要求程序員使用特定的習慣用語，那么通常可以編寫一個檢查器來表示違反這些規則。因此，程序員通常只需很少的編程工作，就可以顯著增加他們從工具中獲得的價值。

一個常見的用例是當發生錯誤并觸發漫長而痛苦的診斷和調試期時。找到缺陷后，明智的做法是首先在代碼中查找重復錯誤的其他位置，然后采取措施檢測錯誤是否再次發生。對現有代碼和新代碼運行自定義檢查可能是實現此目的的有效、低成本方法。這些工具的工作原理以及如何自定義它們的檢查器是使用 CodeSonar 中的代碼片段描述的，盡管這些原則也可以與其他高級靜態分析工具一起使用。

高級靜態分析的工作原理

要了解擴展的不同編寫方式，首先要了解什么是靜態分析，以及靜態分析工具如何在后臺工作。

靜態分析工具的工作方式與編譯器非常相似。他們將源代碼作為輸入，然后對其進行解析并轉換為中間表示 （IR）。高級靜態分析工具架構的框圖如圖 1 所示。編譯器將使用 IR 生成目標代碼，而靜態分析工具保留 IR，而檢查器通常通過遍歷或查詢 IR 來實現，查找指示缺陷的特定屬性或模式。

圖1：高級靜態分析工具的架構

高級工具從復雜的符號執行技術中獲得強大功能，這些技術通過控制流圖探索路徑。這些算法跟蹤程序的抽象狀態，并知道如何使用該狀態來排除對不可行路徑的考慮。

特定于域的屬性的檢查器可以訪問這些表示形式，并以各種方式利用分析算法。

自定義檢查器

最終用戶如何創作自定義屬性檢查器？這在很大程度上取決于屬性的性質，因此有幾種機制可用：

可以通過向配置文件添加指令來擴展現有檢查器。

用戶可以向其代碼添加注釋，以指示分析查找某些屬性。如果用戶不希望干擾源代碼，則可以以面向方面的方式在側面完成這些注釋。

API 允許用戶訪問所有中間表示形式。通常，使用訪問者模式，允許擴展利用分析已在執行的遍歷。

讓我們仔細看看這些機制。

配置文件

這些先進的靜態分析工具實現了數十個檢查器。通常，用戶需要一個與內置檢查器略有不同的檢查器，并且其中許多檢查器都設計為可擴展的。一類檢查器查找禁止使用的函數。例如，眾所周知，C 庫函數 get 是不安全的。檢查器由一個階段實現，該階段查找對函數名稱的引用，然后將它們與一組正則表達式進行匹配。通過向配置文件添加行來向此集合添加其他正則表達式是一件簡單的事情。

代碼注釋

編寫檢查器的第二種方法是向代碼添加注釋。

例如，假設有一個名為 foo 的內部函數采用單個整數參數，并且當此參數為 -1 時引入了潛在的安全漏洞?？梢酝ㄟ^向foo主體添加一些代碼來實現對這種情況的檢查，如下所示：

void foo(int x)

{

#ifdef __CSURF__

csonar_trigger(x, “==”, -1,

“Dangerous call to foo()”);

#endif __CSURF__

…

}

#ifdef構造可確保常規編譯器看不到此新代碼。但是，當該工具分析此代碼時，會看到對csonar_trigger的調用。因此，此調用從未實際執行，而是由工具解釋為對基礎分析引擎的指令。如果分析得出結論，可能滿足觸發條件，則它將發出帶有給定消息的警告。

大多數程序員不喜歡用這樣的注釋來混淆他們的代碼，所以有一種替代方法來實現這種檢查，允許它寫在單獨的文件中。當 foo 的源代碼不可用時，例如當它位于第三方庫中時，此方法也適用。為此，檢查器的作者將編寫一個替換函數，如下所示：

void csonar_replace_foo(int x)

{

csonar_trigger(x, “==”, -1,

“Dangerous call to foo()”);

foo();

}

當分析看到csonar_replace_foo的定義時，它會將代碼中的所有 foo 調用（csonar_replace_foo 內部的調用除外）視為對 csonar_replace_foo 的調用。

此觸發器習慣用法適用于檢查時態屬性，尤其是函數調用序列。假設有一條規則說，在 foo 執行時，永遠不應該調用 bar?？梢园慈缦路绞綄嵤z查：

static int foo_is_executing = 0;

void csonar_replace_foo(int x) {

foo_is_executing = 1;

foo(x);

foo_is_executing = 0;

}

void csonar_replace_bar(void) {

csonar_trigger(foo_is_executing,

“==”, 1,

“Call to bar from foo”);

bar();

}

請注意，全局狀態變量用于記錄 foo 是否處于活動狀態。在輸入 foo 之前，它被設置為 1，然后在 foo 返回后重置為零。然后在 bar 中的觸發器中檢查此變量，如果設置為 1，將發出警告。

前面的示例演示如何檢查全局屬性。相同的機制可用于編寫對單個對象的屬性的檢查?？梢詫傩愿郊拥綄ο笠愿櫰錉顟B。

這種方法允許用戶幾乎像編寫動態檢查一樣編寫靜態檢查。這種檢查的 API 很小，語言是 C，所以有一個溫和的學習曲線。這種簡單性具有欺騙性：該技術可用于實現相當復雜的檢查。

用于中間表示的 API

實現自定義檢查的最終方法是使用提供對基礎表示形式 （IR） 的訪問權限的 API。一家公司使用此 API 查找用于處理硬件錯誤的自定義習慣用法的沖突。

此 API 也可用于其他程序分析任務。例如，一家醫療設備公司主要使用一種工具，不僅識別其代碼中的潛在任務問題，而且還發出允許他們交互式探索堆棧配置屬性的信息。其他應用程序包括收集代碼的自定義指標和生成程序可視化工具的輸入。

可以使用訪問者模式編寫許多檢查 - 該函數作為給定類型的每個 IR 元素的回調調用?？梢詾榭刂屏鲌D和語法樹中的文件、標識符、子程序和節點定義訪問者。訪問者的接口允許與構造進行模式匹配。

CodeSonar具有一種特殊的訪問者類型，在控制流圖的路徑探索期間調用該訪問者。這允許檢查器作者編寫復雜的檢查，以利用該工具的內置路徑敏感程序分析功能。這種檢查器的一個關鍵方面是它使用分析部分，消除了對不可行路徑的探索，這會自動降低誤報結果的概率。

提高軟件質量

先進的靜態分析工具已成為軟件開發人員必不可少的工具，因為它們能夠發現嚴重的安全和安全缺陷。創作自定義檢查器是提高這些工具有效性的低成本方法。

審核編輯：郭婷