一、背景
源代碼靜態(tài)分析工具(SAST)作為軟件安全的重要保障工具，已經(jīng)在各個(gè)領(lǐng)域被廣泛使用。隨著開源SAST工具的廣泛使用，工具種類的增加，使用者很難判斷工具的優(yōu)劣及適不適合企業(yè)的應(yīng)用場景，本文從金融、互聯(lián)網(wǎng)企業(yè)最常用的Java語言代碼分析的角度，對(duì)靜態(tài)分析進(jìn)行一次簡要的測評(píng)，為大家選擇靜態(tài)分析工具提供依據(jù)，此外，本文分析了目前靜態(tài)代碼分析工具存在的技術(shù)問題及工具評(píng)估的基本準(zhǔn)則。
二、概述
一般來說，誤報(bào)和漏報(bào)率是SAST最重要的技術(shù)評(píng)價(jià)指標(biāo)，但由于沒有通用意義上的測試集能夠全面反應(yīng)靜態(tài)分析工具在檢測精度能力方面高低暨分析的敏感度。由此，為了簡化測試難度，本次測評(píng)我們選擇了一個(gè)Java語言且偏安全的國際通用測試集OWASP benchmark，以反應(yīng)代碼分析工具在Java安全檢測能力上的強(qiáng)弱。
OWASP基準(zhǔn)測試是一個(gè)示例應(yīng)用程序，其中包含來自11個(gè)類別的數(shù)千個(gè)漏洞?；鶞?zhǔn)測試中包括很難通過靜態(tài)分析處理的代碼片段，例如：間接調(diào)用、不可達(dá)分支、映射、依賴于配置文件的值。
用例下載地址：https://github.com/OWASP/Benchmark/releases，可以在一定程度上反應(yīng)代碼分析工具的檢測能力。
1. 測試依據(jù)
下表為某款工具的OWASP檢測結(jié)果，如圖所示，左側(cè)一列表示所有類別，P/N為正/負(fù)樣本數(shù)(badcase/goodcase)，TP/FP為真/假陽性的數(shù)量(badcase報(bào)出數(shù)/誤報(bào)數(shù))，TN/FN是真/假陰性的數(shù)量（good case報(bào)出數(shù)/漏報(bào)數(shù)），TPR和FPR是正確率和誤報(bào)率，Y是約登指數(shù)，約登指數(shù)( Youden’s indx，YI)即正確指數(shù)，此指數(shù)值的范圍只從0~1，約登指數(shù)越大， 其真實(shí)性亦越好。其中TPR、FPR、Y的計(jì)算公式如下：
TPR=TP/P
FPR=FP/N
? ?Y=[TP/(TP+FN)+TN/(FP+TN)]-1
2. 測試結(jié)果
選取市場上主流的SAST工具進(jìn)行測試，本次選取的測試工具涵蓋較廣，包含國外商業(yè)工具、開源工具以及國內(nèi)自研工具。如SonarQube[1]代碼自動(dòng)審查工具，該工具是開源工具中使用最多的工具，因?yàn)殚_源免費(fèi)尤其受很多金融企業(yè)喜愛；以色列的Checkmarx CxSAST[2]，Micro Focus?Fortify[3]，目前在電力、金融等行業(yè)推廣較多，是中國市場Java應(yīng)用最多的工具之一；還有在互聯(lián)網(wǎng)領(lǐng)域應(yīng)用的比較廣泛的新思科技的Coverity[4]、IBM Appscan[5]。軍工領(lǐng)域應(yīng)用比較廣泛的Parasoft的JTest[6]、VeraCode[7]等。下圖是10款靜態(tài)分析工具的OWASP基準(zhǔn)測試結(jié)果。商業(yè)SAST工具01-06包括：Checkmarx CxSAST、Micro Focus?Fortify、IBM AppScan Source、Coverity Code Advisor、Parasoft Jtest、SourceMeter[9]和Veracode工具。
從上圖可知，覆蓋率指數(shù)最大為1（即100%覆蓋，不存在漏報(bào)）；而誤報(bào)率最低的指數(shù)為0.12，最高為0.58,尚無。
三、技術(shù)分析
靜態(tài)代碼分析基本原理：首先將源代碼解析為抽象語法樹；采用控制流分析、多態(tài)分析、指向分析、函數(shù)調(diào)用分析等多種分析算法對(duì)基本分析模型；考慮路徑敏感等多種情況，建立符號(hào)執(zhí)行、抽象解釋、圖可達(dá)性等程序模型；根據(jù)缺陷模式在程序模型的基礎(chǔ)上生成一階邏輯表達(dá)式并采用SMT進(jìn)行可滿足性約束求解，生成最終結(jié)果。目前很多工具只做基本分析層面，尤其是開源工具，針對(duì)全模式的敏感分析很多工具并不支持，或支持的不好，因此可能產(chǎn)生大量的誤漏報(bào)，下面分析了幾種典型的問題：
基于以上要點(diǎn)，分析誤報(bào)原因，了解工具的局限性。通過分析，誤報(bào)基本由以下幾種情況導(dǎo)致。
1. 集合覆蓋問題
在集合中，部分集合數(shù)據(jù)存在污染數(shù)據(jù)，當(dāng)檢索集合中未污染部分時(shí)，導(dǎo)致整個(gè)集合覆蓋污染，誤報(bào)產(chǎn)生。如：以下代碼中，map中填充帶有一個(gè)污點(diǎn)（param）和一個(gè)未污點(diǎn)的值（a_value），并且從映射中檢索參數(shù)賦值給bar。如果一個(gè)集合的一部分被污染了，假設(shè)整個(gè)collection都被污染，那么在本例中，當(dāng)我們檢索集合的未污染部分時(shí)，導(dǎo)致誤報(bào)。
2. 集合過度污染問題
在一個(gè)集合中，部分集合數(shù)據(jù)存在污染數(shù)據(jù)，當(dāng)對(duì)集成做一些操作后，工具無法識(shí)別出受污染的數(shù)據(jù)，導(dǎo)致其他正常數(shù)據(jù)收到影響，產(chǎn)生誤報(bào)。如：在以下代碼中，存在一個(gè)未受污染的值（safe），一個(gè)受污染的值(param) 和另一個(gè)未受污染的值(moresafe) 被添加到列表中。 當(dāng)?shù)谝粋€(gè)值“safe”被刪除后，從列表的開頭，檢索索引為 1 的列表元素，即讀取未受污染的值“moresafe”。同樣導(dǎo)致誤報(bào)。
3. 分支問題
在條件分支中，由于條件設(shè)置問題，導(dǎo)致某些分支可能永遠(yuǎn)無法執(zhí)行，若工具無法判定某些無法執(zhí)行的分支，可能導(dǎo)致誤報(bào)的產(chǎn)生。如：在以下代碼中，因?yàn)閚um為常量106，（7*18）+num的值永遠(yuǎn)大于200，導(dǎo)致bar的值始終都為常量字符串，“This_should_always_happen”。另外一個(gè)包含污染數(shù)據(jù)的分支“param”永遠(yuǎn)無法執(zhí)行。導(dǎo)致工具產(chǎn)生誤報(bào)。
四、結(jié)論
全面、高效地靜態(tài)識(shí)別漏洞，減少工具的誤報(bào)是靜態(tài)分析中至關(guān)重要的技術(shù)，目前在該領(lǐng)域中，仍然有很大的進(jìn)步空間。針對(duì)本次OWASP的基準(zhǔn)測試，在選取的工具中，目前結(jié)果最好的工具覆蓋率可以達(dá)到100%，且同時(shí)誤報(bào)率為12%，也說明了工具正不斷趨于成熟，但該結(jié)果僅針對(duì)OWASP測試用例。在后續(xù)的靜態(tài)代碼分析技術(shù)中，需要不斷對(duì)靜態(tài)數(shù)據(jù)流跟蹤器進(jìn)行持續(xù)優(yōu)化，以此提高檢測精度。
為了更好地對(duì)代碼分析工具進(jìn)行評(píng)價(jià)，筆者提出了幾個(gè)評(píng)價(jià)維度，并給出評(píng)價(jià)等級(jí)：
最后
