代碼安全審計産品、代碼缺陷分析産品、代碼安全分析等基于源代碼靜态分析技術的産品市場上越來越多，但是品質卻層次不齊，誤報率非常高，漏報率也不低，究其原因是為什麼呢？因為一款靜态分析類産品研發不是輕松的事，往往要經曆幾年時間，産品才會逐漸成熟，支援的開發語言和安全漏洞類型才能達到企業級應用水準，一般中小企業是很難投入如此長的時間進行研發的，而且靜态分析類産品底層技術是采用的與編譯器非常類似的技術，也就是說大學課堂中編譯原理課程上講得哪些分析技術（例如：抽象文法樹、切片、資料流分析、符号執行、指向分析、區間計算、到達定值分析、守衛值和非守衛值等等讓人了解起來頭疼的技術）大多都要用上，我記得當時學這些原理時就似懂非懂的，再把這些技術應用到産品中，難度可想而知，是以說市場上國内外的主流靜态分析工具必然采用這些技術，把程式代碼轉化為抽象文法樹是必須的一步，在抽象文法樹上基礎上，形成控制流圖、函數調用圖等之後再次進行切片分析，各種守衛值計算等等，零星的技術分析在網絡上大多都能找到，但是缺乏系統化的技術分析，用這些技術、算法編碼實作，在工程實踐中會遇到各種各樣的問題，産品市場化更是具有非常高的門檻，市場很多産品并非采用這樣的主流技術，大多隻是通過檔案周遊掃描過程中，使用規則表達式、關鍵字搜尋等技術比對的特征字元串，是以這樣的分析工具必然誤報率非常高，這種搜尋方法也隻能查出一些特定的缺陷或安全漏洞函數，寫死等特定缺陷，對于很多跨越檔案的缺陷和安全漏洞是根本發現不了的。對于檢測出大量誤報的審計報告，測評人員和開發人員要花大量時間去分析，消耗大量時間，長此以往，這種工具必然被淘汰。
那如何來辨識一款靜态缺陷分析類工具的品質優劣呢？我以國際上通用的一個Java檢測的Benchmark中代碼作為案例分析一下。介紹在可以OWASP官方網站（https://www.owasp.org/index.php/Benchmark）找到，在GitHub（https://github.com/OWASP/benchmark）上可以下載下傳到最新代碼，現在最新版本是Benchmark 1.2beta，目前包括2740個真假漏洞，通過一個檢測工具報出的TP-真實漏洞、FN-漏報漏洞、TN-無誤報漏洞、FP-誤報漏洞通過約登指數（Youden Index）計算公式（真實漏洞檢出率-假漏洞檢出率）計算出得分，滿分是1.0分。也就是評價一個檢測工具最好的情況是真實漏洞全部報出，而假漏洞沒有報出。在2740個案例中，有1415個真實漏洞，1325個假漏洞，對于一款非主流工具來說，可能把絕大多數假漏洞也作為漏洞報出，則約登指數得分很低。是以評價一款靜态缺陷檢測工具的話，最好通過國際上認可的标準案例集進行驗證。當然除了Java語言之外，C/C++語言、PHP、Python等語言都有對應的案例集，詳情可浏覽https://samate.nist.gov/SRD/testsuite.php#sardsuites
我從SQL注入漏洞中選擇兩個案例，BenchmarkTest00043是真實漏洞，BenchmarkTest00052是假漏洞。這個表在下載下傳Benchmark 1.2beta根目錄中。
首先打開BenchmarkTest00043.java檔案，檢視裡面代碼
大家可以看到一般檢測工具會直接定位到54行，因為這裡出現一個特征方法executeUpdate，執行sql語句。但是如果沒有上下文分析，則并不能确定是否為一個真實漏洞。主流檢測工具會通過代碼切片後，在抽象文法樹上進行向後周遊，分析sql參數是否進行注入處理，則找到第50行，第50行是sql字元串的拼接，又引入了param變量。還需要在文法樹上回溯param變量的取值，則找到第46行和47行，第47行無侵入可能，在46行，param變量值是通過scr對象的getTheParameter方法傳遞”vector”字元串獲得，再向上找到src對象，src對象來自于其它類的定義，把post封包的請求參數request傳遞給SeparateClassRequest方法。
打開SeparateClassRequest.java檔案
在構造函數中，傳入了request參數，src調用getTheParameter方法時，把“vector”傳給形參p，方法傳回了p對應的參數值，并沒有對post傳入的參數進行任何處理。經過一系列的回溯和上下文分析，最後确認是存在着SQL注入漏洞。一般單檔案漏洞掃描是無法跨檔案去回溯和上下文分析确認是否為真實漏洞，但是通過簡單的函數名稱判斷也會報出這個漏洞。但是對于OWASP Benchmark 作為一個專業的評價基準項目，也考慮了工具對于漏洞的分析能力，是否對于假漏洞，是否能識别出來呢？
打開BenchmarkTest00052.java這個檔案，如下：
請上面代碼截圖中标注，對于分析也是與上面例子一樣，通過在第55行發現可能的污點後，回溯到第46行。再看對應的另一個檔案中的有關getTheValue方法。
大家是否看到getTheValue方法傳回的是固定字元串“bar”，對于具有上下文和跨檔案分析能力的工具來說，分析到這裡，并不會報出漏洞。因為這不存在SQL注入的可能。而對于一般掃描工具，無法做到上下文分析，沒有生成抽象文法樹，更難于做到跨檔案分析，自然會報出這個漏洞，但是這是一個假漏洞。對于真假漏洞基本持平的Benchmark 2740 全部漏洞，存在得0.10分左右的可能，畢竟真實漏洞比假漏洞多了90個。
好了，如果讀者認真讀到了這裡，我相信您也具有了一雙慧眼，掌握了如何對一款代碼安全審計工具或代碼缺陷檢測工具做出評價和選擇。
關注安全 關注作者
-----------------------------------------------------------------------------------------------------------------