基于深度學習的API誤用缺陷檢測?

汪 昕,陳 馳,趙逸凡,彭 鑫,趙文耘

1(復旦大學 軟件學院,上海 201203)

2(上海市數據科學重點實驗室(復旦大學),上海 201203)

在軟件開發(fā)過程中,開發(fā)人員經常需要使用各種應用程序編程接口(application programming interface,簡稱API)來復用已有的軟件框架、類庫,以節(jié)省軟件開發(fā)時間,提高軟件開發(fā)效率.但由于 API自身的復雜性、文檔資料的缺失或自身的疏漏等原因[1-4],開發(fā)人員經常會誤用API.API的誤用情形多種多樣[5],例如多余的API調用、遺漏的API調用、錯誤的API調用參數、缺少前置條件判斷、忽略異常處理等.這些API誤用在實際項目中常常導致了功能性錯誤、性能問題、安全漏洞等代碼缺陷[5,6].例如在使用文件流API時,如果最后遺漏了對文件流進行關閉的API調用,那么將導致內存泄露問題.

為了自動檢測API誤用缺陷,需要獲得API使用規(guī)約[7],并根據規(guī)約對API使用代碼進行檢測.然而,可用于自動檢測的API規(guī)約難以獲得,而人工編寫并維護的代價又很高.相關研究工作[8-10]關注于利用數據挖掘、統(tǒng)計語言模型等方法自動挖掘或學習API使用規(guī)約并用于缺陷檢測,但存在合成能力不足等問題.

本文將深度學習中的循環(huán)神經網絡模型應用于API使用規(guī)約的學習及API誤用缺陷的檢測.在大量的開源Java代碼基礎上,通過靜態(tài)分析構造 API使用規(guī)約訓練樣本,同時利用這些訓練樣本搭建循環(huán)神經網絡結構學習API使用規(guī)約.在此基礎上,本文針對API使用代碼進行基于上下文的語句預測,并通過預測結果與實際代碼的比較發(fā)現潛在的API誤用缺陷.本文對所提出的方法進行實現,并針對Java加密相關的API及其使用代碼進行了實驗評估,結果表明,該方法能夠在一定程度上實現API誤用缺陷的自動發(fā)現.

本文第1節(jié)對本文使用的深度學習背景知識進行說明.第2節(jié)介紹相關工作.第3節(jié)對本文所提出的方法及其實現進行說明.第4節(jié)介紹本文中設計的兩個實驗——深度學習模型訓練實驗和API誤用缺陷檢測實驗的設計與結果分析.最后,在第5節(jié)對本文進行總結與展望.

1 背景知識

深度學習(deep learning,簡稱 DL)是一類通過連續(xù)多層變換的非線性處理單元對數據進行復雜特征提取,并通過這些組合特征解決問題的機器學習算法[11].

1.1 循環(huán)神經網絡

循環(huán)神經網絡(recurrent neural networks,簡稱RNN)屬于深度學習技術的一個重要分支.通過對數據中的時序信息的利用以及對數據中語義信息的深度表達,RNN在處理和預測序列數據上實現了突破,并在語音識別、語言模型、機器翻譯等方面發(fā)揮出色[12-15].

1.2 長短時記憶網絡

RNN利用狀態(tài)值保存迭代計算時的歷史信息,利用時序信息輔助當前決策.但簡單的 RNN存在長期依賴(long-term dependencies)問題.1997年,Hochreiter和 Schmidhuber提出的長短時記憶網絡(long short term memory,簡稱 LSTM)[16],經過計算[16],能夠進行前向傳播,并對歷史信息進行遺忘,對輸入信息進行狀態(tài)更新,有效解決了長期依賴問題.

1.3 深層循環(huán)神經網絡

深層循環(huán)神經網絡(deep RNN)是RNN的一種變種,通過拓展淺層循環(huán)體,設置多個循環(huán)層,將每層RNN的輸出作為下一層RNN的輸入,進一步處理抽象,增強RNN從輸入中提取高維度抽象信息的能力[12].

1.4 神經網絡模型的優(yōu)化

1.4.1 損失函數

損失函數定義了深度學習神經網絡模型的效果和優(yōu)化目標.本文將神經網絡模型應用于分類問題,用N個神經元的輸出表示N個不同的API調用的評判概率.應用于分類問題的常用損失函數是交叉熵(cross entropy),它表示了兩個概率分布之間的距離,可用于計算正確答案概率分布與預測答案概率分布之間的距離.在訓練過程中,使用Softmax回歸處理層將神經網絡的前向輸出轉換為大小為N的概率分布形式.

1.4.2 優(yōu)化算法

在神經網絡模型中,優(yōu)化過程分為兩個階段:一是前向傳播階段,在這個階段,神經網絡模型前向計算預測值,并通過預測值與目標值計算損失函數;二是反向傳播階段,在這個階段,采用梯度下降法(gradient descent)[17]的思想,通過損失函數對每個可優(yōu)化的參數進行梯度計算,同時利用學習率進行參數更新,從而達到優(yōu)化模型的目的.

在神經網絡模型優(yōu)化過程中,選取適當的初始值、學習率、迭代次數,能進一步調整模型的預測能力.同時,也要注意過擬合問題對模型預測能力的影響——當模型進入過擬合狀態(tài),模型的表達能力將局限在訓練數據中,反而不利于模型的泛化預測能力.

2 相關工作

不少研究工作關注于利用數據挖掘、統(tǒng)計語言模型等方法自動挖掘或學習API使用規(guī)約并用于缺陷檢測,但存在合成能力不足等問題.這方面有代表性的研究工作包括以下這些:

Li等人[8]研究了基于頻繁項集的 API使用規(guī)約挖掘技術,并研發(fā)了一個挖掘和檢測工具 PR-Miner.PRMiner通過將代碼庫中的函數映射為數據子項,并對代碼中頻繁共現的數據子項進行統(tǒng)計和挖掘,根據數據子項的頻繁共現關系推斷API調用之間的關聯關系.最終,PR-Miner可以得到以API調用的關聯關系為基礎的使用規(guī)約.基于該工具,他們在Linux kernel,PostgreSQL等大型軟件系統(tǒng)的代碼中發(fā)現了23個確認的Bug.

Zhong等人[9]研究了基于自然語言處理的 API使用規(guī)約提取技術,并研發(fā)了一個 API使用規(guī)約提取工具Doc2Spec.Doc2Spec通過分析自然語言編寫的 API文檔,提取相關的 API使用規(guī)約.基于該工具,他們分析了J2SE4、J2EE5、JBoss6、iText7以及Oracle JDBC driver8這5個Java庫的Javadocs,提取出API使用規(guī)約,并基于這些API使用規(guī)約在真實代碼中人工發(fā)現了35個確認的Bug.

Wang等人[10]研究了N-gram語言模型,并研發(fā)了一個缺陷檢測工具Bugram.Bugram利用N-gram語言模型,基于API調用token只與在它之前的n個token相關的假設,對軟件項目中出現的API調用token序列進行出現概率的計算,同時將較低概率的token序列的出現與程序中API的異常調用、誤用和特殊用法聯系起來,以此進行缺陷的自動化檢測.基于該工具,他們在16個開源Java項目中發(fā)現了25個確認的Bug以及17個可能存在的代碼重構建議.

然而,這些研究中提出的技術方法存在一定的局限性.頻繁項集挖掘技術關注于挖掘代碼中數據子項的頻繁共現關系,但對API使用的順序信息沒有加以利用;而N-gram語言模型利用到了API使用的順序信息,但是對多樣和變長的代碼上下文存在模型的合成能力不足的問題.

本文將循環(huán)神經網絡模型應用于API使用規(guī)約的學習及API誤用缺陷的檢測.循環(huán)神經網絡模型能有效提取序列數據中的抽象特征,以概率分布的形式進行預測,能有效處理多樣和變長的上下文,具有較強的合成能力.改進后的循環(huán)神經網絡有效地解決了自然語言處理中的長期依賴問題,被廣泛應用于模式識別等領域.因此,我們期望該模型也能有效學習API調用組合、順序及控制結構等方面的使用規(guī)約.

3 方法與實現

3.1 方法概覽

本文所提出的API誤用缺陷檢測方法概覽如圖1所示,其中主要包括3個階段——訓練數據構造、模型訓練與預測、缺陷檢測.

· 在訓練數據構造階段,基于大量開源Java代碼數據集,對源代碼進行靜態(tài)分析,構造抽象語法樹,并進一步構造為API語法圖,用于API調用序列的抽取,最后,將API調用序列構造為深度學習模型需要的訓練數據.

· 在模型訓練與預測階段,訓練深度學習模型,基于該模型和 API使用的上下文對 API調用序列中某處的API調用進行預測,得出該位置的API調用概率列表.

· 在缺陷檢測階段,從待檢測代碼中抽取用于預測的 API調用序列,基于模型訓練與預測階段的模型預測對每個位置進行API調用預測,并獲取每個位置的API調用概率列表,將原代碼中的API調用序列與預測得出的概率列表進行比對,得出最終的API誤用檢測報告.

Fig.1 Overview of our approach圖1 本文方法概覽

3.2 訓練數據構造

在訓練數據構造階段,將數據從源代碼的形式依次構造為抽象語法樹、API語法圖,并基于構造得出的API語法圖提取出與API調用相對應的API調用序列;隨后,將API調用序列構造為可用于模型訓練的訓練數據.如圖1所示,訓練數據構造階段分為4個子階段:靜態(tài)代碼分析、API語法圖構造、API調用序列抽取、數據構造.

3.2.1 靜態(tài)代碼分析

抽象語法樹(abstract syntax tree,簡稱AST)將Java源代碼映射成樹狀結構,是靜態(tài)解析源代碼的有效工具.在靜態(tài)代碼分析階段,本文使用JavaParser[18]對源代碼文件進行解析,并獲取表示源代碼語法結構的AST.

3.2.2 API語法圖構造

在API語法圖構造階段,在AST的基礎上進行進一步解析構造,經過靜態(tài)代碼分析和API語法圖構造,代碼從源代碼形式轉化為API語法圖形式.如圖2所示,展示了本文中一個API語法圖抽取的例子.

Fig.2 Example for API syntax graph extraction圖2 API語法圖抽取例子

圖中的代碼通過Scanner API讀取每行文件內容并打印到輸出控制臺中,最后關閉Scanner,釋放資源.在該代碼中使用到了java.io.File,java.util.Scanner,java.io.PrintStream這些API,經過轉化,抽取出的API語法圖如圖中圖狀結構所示.

在構造API語法圖的過程中涉及到如下定義.

(1) 節(jié)點

節(jié)點分為3種類型.

· 方法節(jié)點,表示API語法圖的來源(文件路徑、類、方法).

· API節(jié)點,表示API對象創(chuàng)建、API方法調用、API類變量訪問.

· 控制節(jié)點,表示控制結構(如IF,ELSE,WHILE,FOR,FOREACH,TRY等).

(2) 邊

節(jié)點之間可以由有向邊連接,方向從父節(jié)點指向子節(jié)點.邊分為兩種類型.

· 順序邊,表示流(控制流)的方向.

· 控制邊,表示控制結構之間的順序關系(如IF→ELSE).

(3) API語法圖

一個根節(jié)點,能構成一個最簡的API語法圖.

邊從父節(jié)點指向子節(jié)點,沒有子節(jié)點的節(jié)點稱為葉子節(jié)點.

向API語法圖中的一個節(jié)點向該圖中另一個節(jié)點加一條邊,圖中不構成環(huán)路,這個圖仍是一個API語法圖.

向API語法圖中加入一個節(jié)點,由圖中任意一個節(jié)點向該節(jié)點加一條邊,圖中不構成環(huán)路,這個圖仍是一個API語法圖.

兩個 API語法圖,從一個 API語法圖的葉子節(jié)點出發(fā),向另一API語法圖的根節(jié)點加邊,稱為移植.移植后,得到組合了兩個API語法圖的API語法圖.

根據定義進行UML建模,設計API語法圖類以及相關類如圖3所示.

Fig.3 Class diagram of API syntax graph圖3 API語法圖相關類圖

其中,

· Node表示API語法圖上的節(jié)點,分為3種節(jié)點類型,包括方法節(jié)點(MethodNode)、API節(jié)點(APINode)以及控制節(jié)點(ControlNode).

· Edge表示父節(jié)點連接子節(jié)點的邊,可以為順序類型邊或者控制結構類型邊.假設從圖上從一個節(jié)點出發(fā),深度遍歷找到所有沒有子節(jié)點與之連接的節(jié)點,這些節(jié)點為這個節(jié)點的葉子節(jié)點(leave).

· Graph表示API語法圖,該圖上的節(jié)點由Node表示,其中,一個特殊的根節(jié)點root表示一個API語法圖的開始.從Grapha的葉子節(jié)點到Graphb的根節(jié)點都加上邊,這個操作稱為移植(transplant).

在API語法圖構造階段,基于AST以及控制流分析,將源代碼抽象表示為API語法圖,流程的具體步驟如下.

(1) 基于JavaParser,靜態(tài)分析代碼為AST.

(2) 基于 JavaParser對每個類中的方法進行抽取,將信息存儲到方法節(jié)點中,并以該節(jié)點為根節(jié)點,構建API語法圖g.

(3) 對每個方法根據以下規(guī)則,迭代地構建API語法圖g′.

a)如果當前處理語句中有嵌套的語句,先構造出嵌套在內層的語句的 API語法圖,移植到g′上,再迭代地根據后續(xù)規(guī)則構造出外層的語句的API語法圖,移植到g′上.

b)如果當前處理語句是API對象創(chuàng)建(API object creation),則構造API節(jié)點,并以“完整類名.New([完整參數類類型])”的形式表示節(jié)點,將以該節(jié)點為根節(jié)點的API語法圖移植到g′上.

c)如果當前處理語句是API方法調用(API method call),則構造API節(jié)點,并以“完整方法名([完整參數類類型])”的形式表示節(jié)點,將以該節(jié)點為根節(jié)點的API語法圖移植到g′上.

d)如果當前處理語句是 API類變量訪問(API field access),則構造 API節(jié)點,并以“完整類名.類變量”的形式表示節(jié)點,將以該節(jié)點為根節(jié)點的API語法圖移植到g′上.

e)如果當前處理語句是控制結構,則根據以下主要規(guī)則,構建相應的API語法圖.

i “if”(判斷結構),構造控制節(jié)點“IF”,并設置為g′的根節(jié)點.根據當前處理語句的子結構,分別構造以控制節(jié)點“CONDITION”、“THEN”、“ELSE”為根節(jié)點的 3個 API語法圖,并用控制邊將這3個API語法圖移植到g′上.

ii “while”(循環(huán)結構),構造控制節(jié)點“WHILE”,并設置為g′的根節(jié)點.根據當前處理語句的子結構,分別構造以控制節(jié)點“CONDITION”、“BODY”為根節(jié)點的兩個 API語法圖,并用控制邊將這兩個API語法圖移植到g′上.

iii “try”(異常處理結構),構造控制節(jié)點“TRY”,并設置為g′的根節(jié)點.根據當前處理語句的子結構,分別構造以控制節(jié)點“TRYBLOCK”、“CATCH”、“FINALLY”為根節(jié)點的 API語法圖,并用控制邊將這些API語法圖移植到g′上.

iv “for”(包含變量初始化、條件判斷、變量更新的循環(huán)結構),構造控制節(jié)點“FOR”,并設置為g′的根節(jié)點.根據當前處理語句的子結構,分別構造以控制節(jié)點“INITIALIZATION”、“COMPARE”、“BODY”、“UPDATE”為根節(jié)點的 API語法圖,并用控制邊將這些 API語法圖移植到g′上.

v “for each”(循環(huán)集合訪問結構),構造控制節(jié)點“FOREACH”,并設置為g′的根節(jié)點.根據當前處理語句的子結構,分別構造以控制節(jié)點“VARIABLE”、“ITERABLE”、“BODY”為根節(jié)點的API語法圖,并用控制邊將這些API語法圖移植到g′上.

(4) 將API語法圖g′移植到API語法圖g中,獲得每個類中方法對應的API語法圖.最終獲取的API語法圖將作為下一階段的基礎.

3.2.3 API調用序列抽取

定義API調用序列(API sequence)如下.

給定API語法圖,從根節(jié)點出發(fā),根據順序邊以及表示順序的控制邊對API語法圖進行深度遍歷得到的節(jié)點標簽序列,稱為這個 API語法圖上的 API調用序列.表示順序的控制邊有以下幾種:IF→CONDITION、WHILE→CONDITIO、TRY→TRYBLOCK、FOR→INITAILIZATION、FOREACH→VARIABLE.

例如在圖2的例子中,經過API語法圖構造以及API調用序列抽取,得到以下兩個API調用序列.

· “java.io.File.new(java.lang.String)→java.util.Scanner.new(java.io.File)→WHILE→CONDITION→java.util.Scanner.hasNextLine()→BODY→java.util.Scanner.nextLine()→java.io.PrintStream.println(java.lang.String)→java.util.Scanner.close()→EOS”.

· “java.io.File.new(java.lang.String)→java.util.Scanner.new(java.io.File)→WHILE→CONDITION→java.util.Scanner.hasNextLine()→java.util.Scanner.close()→EOS”.

在API調用序列抽取階段,基于API語法圖,抽取API語法圖中的API調用序列.主要思想是對API語法圖進行深度遍歷,提取所有存在API調用節(jié)點的API調用序列作為與該API語法圖對應的API調用序列集合.所有提取的API調用序列以EOS控制節(jié)點結束.

3.2.4 訓練數據產生

訓練數據構造階段將 API調用序列轉換為訓練數據,該階段包括了詞匯表的建立以及訓練數據的構造兩個部分.

(1) 構建詞匯表.為了將API調用序列轉化為深度學習模型能夠統(tǒng)一識別的序列輸入,將原始數據集中的代碼片段轉化為API調用序列后,經過統(tǒng)計序列中出現的API調用詞頻,建立API調用與API調用編號一一對應的詞匯表,并持久化到本地的詞匯表文件中.

(2) 構造訓練數據.如圖4中構造訓練數據算法流程圖所示,基于詞匯表將API調用序列轉換為API調用編號序列,其中每個 API調用的編號與詞匯表中該調用的行號對應.對構造好的編號序列進行遍歷,構造〈API調用前文編號序列,API調用編號〉形式的數據,并作為訓練數據持久化至本地訓練數據文件中,方便之后的模型訓練和預測.這里的API調用前文指的是在該序列中API調用之前的所有API調用組成的序列,API調用前文的編號序列形式稱為API調用前文編號序列.

Fig.4 Flowchart of training data build algorithm圖4 構造訓練數據算法流程圖

3.3 模型訓練與預測

在模型訓練與預測階段,基于TensorFlow框架,使用 Python3語言搭建深度學習模型對訓練數據構造中獲得的訓練數據進行學習,得到訓練好的深度學習模型,并利用該模型對特定時間步上的API調用進行預測,得到該位置上的API調用概率列表.該階段主要分為模型訓練和模型預測兩個階段.

3.3.1 模型訓練

本文中采用的深度學習模型為深層循環(huán)網絡結構配合長短時記憶網絡的應用,這里簡稱為深層長短時記憶循環(huán)網絡(deep LSTM).結構示意如圖5所示.示意圖中采用了雙層深層循環(huán)神經網絡的結構,在每個循環(huán)體結構中應用LSTM模型,將每個時間步上的API調用序列的標簽作為一個詞,Deep LSTM的輸入為包含 個時間步的詞向量,表示前t個API調用序列的輸入,輸出取第t個時間步的輸出,表示基于前文內容,下一個API調用序列上的節(jié)點可能情況的概率分布.

Fig.5 Structure of deep LSTM圖5 Deep LSTM結構

模型的搭建選取深度學習框架TensorFlow 1.6.0作為實現框架.

模型的計算流程如下.

(1) 經過詞向量層(word embedding),將輸入的API調用前文編號序列中的每個API調用編號嵌入到一個實數向量中,以此降低輸入的維度,同時增加語義信息.

(2) 經過詞向量層轉化的輸入向量經過dropout層,丟棄部分信息以增強模型的健壯性.

(3) 使用TensorFlow提供的動態(tài)RNN接口實現神經網絡主要結構,其中包含了深層LSTM處理單元.

(4) 循環(huán)神經網絡的輸出需要經過一個全連接層(dense)轉化,與詞表大小保持一致,這個與詞表大小一致的輸出稱為logits;隨后,logits經過Softmax處理以及交叉熵計算,可以分別得到API調用的概率分布以及損失值;TensorFlow將基于給定的優(yōu)化函數,對參數進行優(yōu)化.

(5) 同時,在訓練過程中加入預測正確率(accuracy)作為訓練時的反饋,同時也作為優(yōu)化訓練模型的參考.至此,我們搭建并訓練了一個應用于API調用序列預測的深度學習模型.

3.3.2 模型預測

在模型預測階段,基于模型訓練中的訓練好的深度學習模型,并將用于預測的API調用前文序列作為輸入,預測下一位置上的 API調用的概率分布,將這個概率分布進行排序,得出下一位置上的 API調用概率列表.該API調用概率列表將作為之后缺陷檢測的重要部分.

3.4 缺陷檢測

本階段的基礎是訓練數據構造階段和模型訓練與預測階段.

如圖1所示,缺陷檢測階段經過訓練數據構造階段的靜態(tài)代碼分析、API語法圖構造、API調用序列抽取,得到原代碼中的API調用序列,基于模型訓練與預測階段的模型預測,對API調用序列中除了具有固定語法順序搭配的控制流結構(例如IF→CONDITION中IF后緊跟的CONDITION所在位置,WHILE→CONDITION中WHILE后緊跟的CONDITION所在位置等等)之外的每個位置進行API調用預測并獲取每個位置的API調用概率列表,將原代碼中每個API調用序列上的每個位置的API調用與預測得出的API調用概率列表進行比對,應用定義好的代碼缺陷檢測規(guī)則,報告出候選的代碼缺陷,得出最終的API誤用檢測報告.

缺陷檢測實現部分涉及不同的實現語言——Java和 Python,為了模型之間較方便地協(xié)作調用,在本文的實現中采用如下技術框架進行模塊之間的溝通:基于 Python語言中的 Web端框架 Flask[19]搭建 Web服務端,將API調用概率列表的預測包裝為Web API供客戶端調用.

本文中實現的缺陷檢測算法流程如圖6所示,算法中的具體步驟如下.

(1) 從待檢測的源代碼中抽取API語法圖.

(2) 從API語法圖中抽取API調用序列.

(3) 對每一個API調用序列,從第2個位置開始,進行缺陷檢測.

(4) 基于檢測位置的API調用前文,預測該位置可能出現的API調用概率列表.

(5) 判斷該位置的API調用在API調用概率列表中的排名是否在可接受范圍(該范圍在算法開始前由人工定義)內:如果該API調用的出現在可接受范圍內,則繼續(xù)檢測下一位置;如果該 API調用的出現超出可接受范圍,則作為一個缺陷并進行該位置的缺陷報告,缺陷報告包括了代碼缺陷在源代碼中的位置(起止行數)以及對應的API調用.

(6) 結束檢測后,可根據缺陷報告進行進一步的評估.

Fig.6 Flowchart of bug detection algorithm圖6 缺陷檢測算法流程圖

在實驗過程中,將重點對算法中API調用在API調用概率列表中可接受范圍的設定進行實驗.

4 實驗評估

本文中的實驗評估分為兩部分:首先是深度學習模型訓練,目的在于嘗試優(yōu)化深度學習模型對 API調用序列預測的準確性和可靠性;其次是代碼缺陷檢測實驗,目的在于評估檢測深度學習模型在 API誤用缺陷檢測上的效果和可用性.

4.1 實驗對象

JCE(Java cryptography extension)是JDK提供的一組包,它們提供用于加密、密鑰生成和協(xié)商及消息驗證碼(MAC)算法的框架和實現,JCE提供的Java密碼學APIs(Java cryptography APIs)在javax.crypto包下.研究[20-22]說明:Java Cryptography APIs通過分離開發(fā)人員和API底層實現細節(jié),開發(fā)人員可以輕松地使用加解密技術.這些API提供了多種模式和配置選項,但因此,對開發(fā)人員來說使用和組合這些API組件的任務可能具有挑戰(zhàn)性.

本文中將實驗對象聚焦于Java Cryptography APIs,展示深度學習模型在缺陷檢測上的效果和能力.

4.2 深度學習模型訓練實驗

4.2.1 實驗數據

Git是一個自由開源的分布式版本控制系統(tǒng),它的設計目的是無論小型還是大型的項目,都能通過Git快速高效地管理.GitHub是一個基于Git的大型開源代碼托管平臺以及版本控制系統(tǒng),GitHub上的開源代碼是挖掘API調用規(guī)約的一大數據來源[23,24].

在本文的深度學習模型訓練實驗中,以“javax.crypto”為關鍵詞,從GitHub上收集了14 422個java代碼文件,這些文件的最后修改時間在2018年1月1日之前(穩(wěn)定版本),這些文件組成的訓練原始文件總大小為50MB.從訓練原始文件中抽取38 602條API調用序列,構造388 973條訓練數據,詞表大小為1 564.

4.2.2 實驗設計

深度學習模型的搭建選取深度學習框架 TensorFlow 1.6.0作為實現框架,語言為 Python,開發(fā) IDE為Jupyter-notebook編輯器,搭建模型為深層循環(huán)神經網絡和長短時記憶網絡的結合.

實驗探究隱層大小(HIDDEN_SIZE)、深層循環(huán)網絡層數(NUM_LAYER)、學習率(LR)以及迭代次數(NUM_EPOCH)對模型效果的影響.對模型效果的評判效果以驗證集上的分類準確率(accuracy)為準,分類準確率為模型預測 Top-1為目標詞的準確率.通過調整深度學習模型的部分參數,對模型進行調整訓練,訓練集為總數據集的90%,驗證集為總數據集的10%.

4.2.3 實驗模型分析

本次實驗最終選擇的參數配置為HIDDEN_SIZE=250,NUM_LAYER=2,LR=0.002,NUM_EPOCH=20.如圖7所示,橫軸為訓練迭代次數(epoch),縱軸為損失(loss).該模型在訓練中的損失不斷下降趨于收斂.

Fig.7 Loss of DL model圖7 深度學習模型損失

該配置下,模型效果如圖8所示,橫軸為迭代次數,縱軸為準確率.

Fig.8 Accuracy of DL model (HIDDEN_SIZE=250,NUM_LAYER=2,LR=0.002)圖8 深度學習模型準確率(HIDDEN_SIZE=250,NUM_LAYER=2,LR=0.002)

經過20次迭代后,模型準確率達到80.3%.該參數組合在驗證集上效果最優(yōu),因此最終用于缺陷預測的模型參數為:HIDDEN_SIZE=250,NUM_LAYER=2,LR=0.002,NUM_EPOCH=20.

4.3 代碼缺陷檢測實驗

本節(jié)進行基于深度學習模型的 API誤用相關代碼缺陷檢測實驗.進行該部分實驗前,對實驗中的測試標準進行定義.

· 定義TP為檢測文件API誤用缺陷位置正確的不重復缺陷報告數.

· 定義FP為檢測文件API誤用缺陷位置錯誤的不重復缺陷報告數.

· 定義FN為未進行報告的缺陷報告數.

1.查準率(precision)定義為

2.召回率(recall)定義為

3.查準率和召回率的調和均值(F1)定義為

查準率和召回率往往體現的是實驗結果的一個側面,比如召回率較高的模型在查準率上不一定很高.因此在本文的實驗中,采用二者的調和均值F1進行API誤用缺陷檢測的實驗評價.

4.3.1 實驗數據

本次實驗中,根據相關文獻中Java Cryptography API誤用的真實數據[5],選用了從SourceForge和GitHub上的優(yōu)質項目(大于10星)中整理的關于Java Cryptography APIs的誤用代碼片段8個,其中包含API誤用14個,將這14個API誤用作為計算模型查準率、召回率以及F1值的測試集.實驗所用的測試集整理如表1所示,表格中標明了每個測試用例的代碼來源、API誤用方法來源、誤用引入缺陷的具體 API以及 API誤用的說明,所有測試用例源碼可通過代碼來源在托管平臺上下載.

Table 1 Information of test case表1 測試用例信息

Table 1 Information of test case (Continued)表1 測試用例信息(續(xù))

這些測試用例中包含4種類型的API誤用(不互斥).

a.使用了多余的API調用;

b.使用了錯誤的API調用;

c.遺漏了關鍵的API調用;

d.忽略了對API調用中可能拋出的異常的處理.

其中,測試用例1使用了多余的API調用;測試用例2忽略了對API調用中可能拋出的異常的處理;測試用例3、測試用例5、測試用例7～測試用例9、測試用例11、測試用例13使用了錯誤的API調用;測試用例4、測試用例6、測試用例10、測試用例12、測試用例14遺漏了關鍵的API調用.

4.3.2 實驗設計

人工整理API誤用測試用例,將每個 API誤用標注成標準化的格式“文件路徑,方法,API誤用缺陷位置,誤用API”,用于計算查準率、召回率和F1值.

在進行API誤用缺陷檢測時,DeepLSTM將預測出API調用序列上某個位置上的API調用概率列表,為進行缺陷檢測,定義 API調用在 API調用概率列表中可以接受的排名范圍,在本文中稱為可接受閾值(acceptable threshold).假設實驗中的缺陷檢測模型的可接受水平設置為k,那么當 API調用在API調用概率列表中的排名在Top-1～Top-k之間時(包括Top-k),認為該API調用在本次API誤用缺陷檢測中處于API調用的可接受范圍內;反之,認為該API調用屬于API誤用代碼缺陷.

為驗證模型的有效性,設置以下模型作為實驗的對比模型.

(1) 基準模型(baseline).該模型假設API調用序列上的每個位置都可能是潛在的API誤用,該假設覆蓋到所有的API誤用缺陷,召回率恒定為1,在測試集上的查準率為0.088 6,F1值為0.163.

(2)N-gram檢測模型.Bugram[10]基于N-gram語言模型實現了對存在API誤用的異常序列的檢測.本文關注于對API調用序列上某一位置可能存在的API誤用的檢測,因此,本文實現Bugram應用的N-gram預測模型作為對比實驗,使用與深度學習模型訓練時相同的API調用序列,訓練N-gram模型,基于前N個詞元預測下一個詞元.實驗中取N={3,4,5}分別對應3-gram模型、4-gram模型和5-gram模型,并進行Jelinek-Mercer平滑處理[25].N-gram檢測模型應用N-gram預測模型對API調用序列上某個位置的API調用概率列表進行預測,同樣的,應用可接受閾值(Top-k)進行缺陷檢測.

在本實驗中,比較不同模型的API誤用缺陷檢測效果,并探究可接受閾值的取值對代碼缺陷檢測模型的F1值的影響.

4.3.3 實驗結果分析

經測試,API誤用缺陷檢測的實驗結果如圖9所示,圖中折線表示不同的實驗模型,橫軸表示可接受閾值(top-k)的取值,圖9(a)是各模型的F1值,圖9(b)是各模型的查準率,圖9(c)是各模型的召回率.

從結果中可以看出:

在一定范圍內,DeepLSTM的查準率均高于基準模型且召回率大于等于50%,有一定的缺陷檢測能力.本實驗中4-gram模型較3-gram模型和5-gram模型缺陷檢測效果較好,但在本實驗中,它們均不如基準模型(查準率最高約和基準持平).而相較而言,DeepLSTM模型在本次實驗所采用的模型中有一定的檢測能力且效果最好.

當可接受閾值取到Top-8時,DeepLSTM缺陷檢測效果最好.

Fig.9 Result of API misuse bug detection experiment圖9 API誤用缺陷檢測實驗結果

為了進一步探究API誤用類型與模型能力的關系,實驗中,將DeepLSTM模型對應每個可接受閾值(top-k)的具體API誤用缺陷報告情況整理在表2中,表格中檢測正確的API誤用用“√”表示,未檢出的API誤用用“-”表示.

Table 2 API misuse bug detection reports statistics表2 API誤用缺陷檢測報告情況統(tǒng)計

基于整理后的API誤用缺陷檢測報告情況,按照測試集中API誤用的誤用類型對缺陷檢測報告情況進行進一步的可視化統(tǒng)計分析,如圖10所示.

縱軸表示了不同類型的 API誤用缺陷,橫軸表示檢測出以及未檢出的該類型 API誤用數量在該類型 API誤用總數中的占比,用顏色深藍色、淺綠色分別表示檢測出和未檢出的兩種情況,圖中有10個獨立的子圖來分別表示每個可接受閾值(top-k)對應的API誤用缺陷檢測報告情況.

分析該圖,可以看出:

· 隨著k取值的增大,在某些API誤用的檢測上,模型的效果保持基本不變(錯誤的API調用),一定程度說明了本實驗中采用的缺陷檢測方法對檢測該類API誤用的有效性:當一個API誤用在API調用序列中不應該出現(使用了錯誤的API)時,則應用本實驗中按位置預測并比較檢測API誤用是可行且有效的.

· 但是與之相反的,隨著k取值的增大,在某些API誤用的檢測上,模型效果不斷降低(遺漏API調用),這一定程度上也說明了本實驗中采用的缺陷檢測方法對檢測該類API誤用的局限性:當一個關鍵性API在 API調用序列中遺漏,僅靠當前的 API調用序列作為預測的前文,很難推斷出下一位置是否遺漏了某個 API.例如,某個關鍵性 API可能在當前位置更靠后幾個調用中出現,這種情況對目前采用的僅對一個位置的API誤用缺陷進行檢測的方法就具有很大的挑戰(zhàn)性.

· 隨著k取值的增大,在某些API誤用的檢測上,模型效果有較大的突變(多余的API調用、忽略異常處理),這與本實驗中采用的測試集有一定的關系——多余的 API調用和忽略異常處理的測試用例都僅有1個.但是在k取到一定范圍(top-8)之前,本實驗中采用的缺陷檢測方法對忽略異常處理類型的API誤用缺陷檢測效果還是不錯的.

· 就每個獨立子圖而言,也可以驗證以上幾點結論:本實驗采用的 API誤用缺陷檢測方法,對檢測錯誤的API調用類型的API誤用效果較好,而在發(fā)現遺漏API調用類型的API誤用上,能力稍有欠缺.

Fig.10 Analysis of relationship between acceptable thresholdand type of API misuse圖10 可接受閾值與API誤用類型關系分析

綜上,本實驗應用深度學習模型學習大量代碼中的API使用規(guī)約,并應用在API誤用缺陷檢測上的方法.雖然由于大量開源代碼中可能存在些許誤用的 API代碼,影響到訓練數據的質量,對模型的效果產生著一定的影響,但是本實驗中,模型在以檢測Java加密相關的API誤用代碼缺陷為例的實驗中仍然起到了一定的效果,以可接受閾值為8時效果最佳(F1值、準確率).在本實驗中,模型對檢測錯誤的API調用類型的API誤用效果較好,而在發(fā)現遺漏API調用類型的API誤用上能力稍有欠缺,這與每種API誤用類型內在的規(guī)律特征密不可分.

5 結束語

本文將深度學習中的循環(huán)神經網絡模型應用于API使用規(guī)約的學習及API誤用缺陷的檢測.將API調用組合、順序及控制結構等方面的使用規(guī)約建模為API語法圖和API調用序列.在大量的開源Java代碼基礎上,對代碼進行靜態(tài)分析,并構造大量API使用規(guī)約訓練樣本,對循環(huán)神經網絡進行訓練.在實驗中通過嘗試不同參數組合,選定并訓練出較優(yōu)的循環(huán)神經網絡模型,并用于基于前文的API調用預測,通過預測結果與實際代碼進行比較來發(fā)現潛在的API誤用缺陷.隨后,在以檢測Java加密相關的API誤用代碼缺陷為例的實驗中證明了該方法的有效性.實驗表明,本方法檢測錯誤的API調用類型的API誤用時最為穩(wěn)定有效.

本文提出的方法在一定程度上能自動檢測API誤用缺陷,并在某類API誤用的檢測中較為有效,但是還存在一些不足和可改進之處——在發(fā)現遺漏API調用類型的API誤用上,能力稍有欠缺.在未來研究中,可考慮對多個位置的API調用進行預測比對,減少模型由于單個位置的預測帶來的API是否漏用的不確定性.