靜態代碼分析,任重道遠

今天翻到一個老問題,題主說代碼分析領域的各種分析方法發展的已經比較成熟了。我看著很無語。這個題主一定是學術界的。如果是實際每天使用代碼掃描工具的工程師,你問問他們成熟嗎?

根據國外某人針對靜態代碼分析產品對比測試的結果報告,HP的Fortify作為市場主流產品之一,漏報率是56%左右,也就是漏了一大半的問題,所以這個能叫做成熟嗎?

http://www.cs.wayne.edu/~mabianto/sb/KVA14_TR.pdfwww.cs.wayne.edu

而實際使用中,對於真正重視安全的公司而言,誤報率才是更大的問題。因為有漏洞的代碼往往比較簡單,但是有修復過的安全代碼往往比較複雜,代碼掃描工具更難理解修復的邏輯,抱著「漏過1個漏洞比誤報1個漏洞是更嚴重的問題」的心理,凡是不確定的,都只好報出來了。

所以代碼掃描工具,會越用越煩,才開始用的時候,程序安全水平低,幾乎都是問題,那當然誤報就少。但是到後面問題修復的差不多了,誤報的比例會越來越高,然後開發人員的大部分時間都浪費在人工審計和標記無效的漏洞上面。

人工審計的工作雖然煩,但是還不敢放鬆警惕,因為裡面說不定還藏著個把有效的,真要是漏了,領導會罵:工具都已經報出來了,你竟然給標記為「誤報」,你將無言以對。所以只好一邊罵一邊耐心的看大量的誤報。

更糟糕的是,複查這些問題的人,本身必須是既懂開發又懂安全的專家,否則很容易被工具搞暈了。但是複合型專業人才很罕見,到哪裡都是公司安全方面的技術核心甚至CSO,所以浪費他們的時間來對付傻傻的工具誤報?

然後就會不停的問一個問題:我們為什麼要花大錢買一個工具來虐待好不容易高薪雇來的工程師?還不如人工做代碼審計來的快呢。

靜態代碼分析技術,還遠未成熟。學術界的技術許多年沒有太大的發展,並不是完善了,而是理論上到了瓶頸期,能解決的問題都解決的差不多了,還沒解決的,基本沒有好的解決方法。真正要實現成熟好用的代碼分析工具,還是任重道遠。


推薦閱讀:

請問c# 有什麼推薦的代碼靜態分析工具?
關於程序分析領域的研究現狀和熱點趨勢?
如何理解萊斯定理對程序靜態分析的限制?
如何學習符號執行(Symbolic Execution)?

TAG:信息安全 | 程序分析 |