安全編程代碼靜態分析

❶ 做靜態代碼分析都是用那個軟體的

本文首先介紹了靜態代碼分析的基本概念及主要技術，隨後分別介紹了現有 4 種主流 java 靜態代碼分析工具 (Checkstyle，FindBugs，PMD，Jtest)，最後從功能、特性等方面對它們進行分析和比較，希望能夠幫助 Java 軟體開發人員了解靜態代碼分析工具，並選擇合適的工具應用到軟體開發中。

引言

在 Java 軟體開發過程中，開發團隊往往要花費大量的時間和精力發現並修改代碼缺陷。Java 靜態代碼分析（static code analysis）工具能夠在代碼構建過程中幫助開發人員快速、有效的定位代碼缺陷並及時糾正這些問題，從而極大地提高軟體可靠性並節省軟體開發和測試成 本。目前市場上的 Java 靜態代碼分析工具種類繁多且各有千秋，因此本文將分別介紹現有 4 種主流 Java 靜態代碼分析工具 (Checkstyle，FindBugs，PMD，Jtest)，並從功能、特性等方面對它們進行分析和比較，希望能夠幫助 Java 軟體開發人員了解靜態代碼分析工具，並選擇合適的工具應用到軟體開發中。

靜態代碼分析工具簡介

什麼是靜態代碼分析

靜態代碼分析是指無需運行被測代碼，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性，找出代碼隱藏的錯誤和缺陷，如參數不匹配，有歧義的嵌套語句，錯誤的遞歸，非法計算，可能出現的空指針引用等等。

在軟體開發過程中，靜態代碼分析往往先於動態測試之前進行，同時也可以作為制定動態測試用例的參考。統計證明，在整個軟體開發生命周期中，30% 至 70% 的代碼邏輯設計和編碼缺陷是可以通過靜態代碼分析來發現和修復的。

但是，由於靜態代碼分析往往要求大量的時間消耗和相關知識的積累，因此對於軟體開發團隊來說，使用靜態代碼分析工具自動化執行代碼檢查和分析，能夠極大地提高軟體可靠性並節省軟體開發和測試成本。

靜態代碼分析工具的優勢

1. 幫助程序開發人員自動執行靜態代碼分析，快速定位代碼隱藏錯誤和缺陷。

2. 幫助代碼設計人員更專注於分析和解決代碼設計缺陷。

3. 顯著減少在代碼逐行檢查上花費的時間，提高軟體可靠性並節省軟體開發和測試成本。

Java 靜態代碼分析理論基礎和主要技術

• 缺陷模式匹配：缺陷模式匹配事先從代碼分析經驗中收集足夠多的共性缺陷模式，將待分析代碼與已有的共性缺陷模式進行模式匹配，從而完成軟體的安全分析。這種方式的優點是簡單方便，但是要求內置足夠多缺陷模式，且容易產生誤報。

• 類型推斷：類型推斷技術是指通過對代碼中運算對象類型進行推理，從而保證代碼中每條語句都針對正確的類型執行。這種技術首先將預定義一套類型機制，包括類 型等價、類型包含等推理規則，而後基於這一規則進行推理計算。類型推斷可以檢查代碼中的類型錯誤，簡單，高效，適合代碼缺陷的快速檢測。

• 模型檢查：模型檢驗建立於有限狀態自動機的概念基礎之上，這一理論將被分析代碼抽象為一個自動機系統，並且假設該系統是有限狀態的、或者是可以通過抽象歸 結為有限狀態。模型檢驗過程中，首先將被分析代碼中的每條語句產生的影響抽象為一個有限狀態自動機的一個狀態，而後通過分析有限狀態機從而達到代碼分析的 目的。模型檢驗主要適合檢驗程序並發等時序特性，但是對於數據值域數據類型等方面作用較弱。

• 數據流分析：數據流分析也是一種軟體驗證技術，這種技術通過收集代碼中引用到的變數信息，從而分析變數在程序中的賦值、引用以及傳遞等情況。對數據流進行 分析可以確定變數的定義以及在代碼中被引用的情況，同時還能夠檢查代碼數據流異常，如引用在前賦值在後、只賦值無引用等。數據流分析主要適合檢驗程序中的 數據域特性。

現有主流 Java 靜態分析工具

Checkstyle

Checkstyle 是 SourceForge 的開源項目，通過檢查對代碼編碼格式，命名約定，Javadoc，類設計等方面進行代碼規范和風格的檢查，從而有效約束開發人員更好地遵循代碼編寫規范。

Checkstyle 提供了支持大多數常見 IDE 的插件，文本主要使用 Eclipse 中的 Checkstyle 插件。如下圖 1 所示，Checkstyle 對代碼進行編碼風格檢查，並將檢查結果顯示在 Problems 視圖中。圖中，代碼編輯器中每個放大鏡圖標表示一個 Checkstyle 找到的代碼缺陷。開發人員可通過在 Problems 視圖中查看錯誤或警告詳細信息。



• 圖 1. 使用 Checkstyle 進行編碼風格檢查




此外，Checkstyle 支持用戶根據需求自定義代碼檢查規范，在下圖 2 中的配置面板中，用戶可以在已有檢查規范如命名約定，Javadoc，塊，類設計等方面的基礎上添加或刪除自定義檢查規范。



• 圖 2. 使用 Checkstyle 添加自定義代碼檢查規范




FindBugs

FindBugs 是由馬里蘭大學提供的一款開源 Java 靜態代碼分析工具。FindBugs 通過檢查類文件或 JAR 文件，將位元組碼與一組缺陷模式進行對比從而發現代碼缺陷，完成靜態代碼分析。FindBugs 既提供可視化 UI 界面，同時也可以作為 Eclipse 插件使用。文本將主要使用將 FindBugs 作為 Eclipse 插件。在安裝成功後會在 eclipse 中增加 FindBugs perspective，用戶可以對指定 Java 類或 JAR 文件運行 FindBugs，此時 FindBugs 會遍歷指定文件，進行靜態代碼分析，並將代碼分析結果顯示在 FindBugs perspective 的 bugs explorer 中，如下圖 3 所示：



• 圖 3. 使用 FindBugs 進行靜態代碼分析




圖中 Bug Explorer 中的灰色圖標處為 Bug 類型，每種分類下紅色圖標表示 bug 較為嚴重，黃色的圖標表示 bug 為警告程度。Propreties 列出了 bug 的描述信息及修改方案。

此外，FindBugs 還為用戶提供定製 Bug Pattern 的功能。用戶可以根據需求自定義 FindBugs 的代碼檢查條件，如下圖 4 所示：



• 圖 4. 使用 FindBugs 添加自定義代碼檢查規范




PMD

PMD 是由 DARPA 在 SourceForge 上發布的開源 Java 代碼靜態分析工具。PMD 通過其內置的編碼規則對 Java 代碼進行靜態檢查，主要包括對潛在的 bug，未使用的代碼，重復的代碼，循環體創建新對象等問題的檢驗。PMD 提供了和多種 Java IDE 的集成，例如 Eclipse，IDEA，NetBean 等。本文主要使用 PMD 以插件方式與 Eclipse 集成。如下圖 5 所示：在 Violations Overview 視圖中，按照代碼缺陷嚴重性集中顯示了 PMD 靜態代碼分析的結果。



• 圖 5. 使用 PMD 進行靜態代碼分析




PMD 同樣也支持開發人員對代碼檢查規范進行自定義配置。開發人員可以在下圖 6 中的面板中添加、刪除、導入、導出代碼檢查規范。



• 圖 6. 使用 PMD 添加自定義代碼檢查規范




Jtest

Jtest 是 Parasoft 公司推出的一款針對 Java 語言的自動化代碼優化和測試工具，Jtest 的靜態代碼分析功能能夠按照其內置的超過 800 條的 Java 編碼規范自動檢查並糾正這些隱蔽且難以修復的編碼錯誤。同時，還支持用戶自定義編碼規則，幫助用戶預防一些特殊用法的錯誤。Jtest 提供了基於 Eclipse 的插件安裝。Jtest 支持開發人員對 Java 代碼進行編碼規范檢查，並在 Jtask 窗口中集中顯示檢查結果，如下圖 7 所示：



• 圖 7. 使用 Jtest 進行靜態代碼分析




同時，Jtest 還提供了對用戶定製代碼檢查配置甚至自定義編碼規則的支持，這一功能使得開發人員可以基於不同場景定製所需要的編碼規范，如圖 8 所示：



• 圖 8. 使用 Jtest 添加自定義代碼檢查規范



Java 靜態分析工具對比

本章節將從以下幾個方面對上述 Java 靜態分析工具進行比較：

應用技術及分析對象

下表 1 列出了不同工具的分析對象及應用技術對比：



• 表 1. 不同工具的分析對象及應用技術對比



Java 靜態分析工具

分析對象

應用技術

Checkstyle Java 源文件 缺陷模式匹配

FindBugs 位元組碼 缺陷模式匹配；數據流分析

PMD Java 源代碼 缺陷模式匹配

Jtest Java 源代碼 缺陷模式匹配；數據流分析




內置編程規范

Checkstyle：

• Javadoc 注釋：檢查類及方法的 Javadoc 注釋

• 命名約定：檢查命名是否符合命名規范

• 標題：檢查文件是否以某些行開頭

• Import 語句：檢查 Import 語句是否符合定義規范

• 代碼塊大小，即檢查類、方法等代碼塊的行數

• 空白：檢查空白符，如 tab，回車符等

• 修飾符：修飾符號的檢查，如修飾符的定義順序

• 塊：檢查是否有空塊或無效塊

• 代碼問題：檢查重復代碼，條件判斷，魔數等問題

• 類設計：檢查類的定義是否符合規范，如構造函數的定義等問題

FindBugs：

• Bad practice 壞的實踐：常見代碼錯誤，用於靜態代碼檢查時進行缺陷模式匹配

• Correctness 可能導致錯誤的代碼，如空指針引用等

• 國際化相關問題：如錯誤的字元串轉換

• 可能受到的惡意攻擊，如訪問許可權修飾符的定義等

• 多線程的正確性：如多線程編程時常見的同步，線程調度問題。

• 運行時性能問題：如由變數定義，方法調用導致的代碼低效問題。

PMD：

• 可能的 Bugs：檢查潛在代碼錯誤，如空 try/catch/finally/switch 語句

• 未使用代碼（Dead code）：檢查未使用的變數，參數，方法

• 復雜的表達式：檢查不必要的 if 語句，可被 while 替代的 for 循環

• 重復的代碼：檢查重復的代碼

• 循環體創建新對象：檢查在循環體內實例化新對象

• 資源關閉：檢查 Connect，Result，Statement 等資源使用之後是否被關閉掉

Jtest

• 可能的錯誤：如內存破壞、內存泄露、指針錯誤、庫錯誤、邏輯錯誤和演算法錯誤等

• 未使用代碼：檢查未使用的變數，參數，方法

• 初始化錯誤：內存分配錯誤、變數初始化錯誤、變數定義沖突

• 命名約定：檢查命名是否符合命名規范

• Javadoc 注釋：檢查類及方法的 Javadoc 注釋

• 線程和同步：檢驗多線程編程時常見的同步，線程調度問題

• 國際化問題：

• 垃圾回收：檢查變數及 JDBC 資源是否存在內存泄露隱患

錯誤檢查能力

為比較上述 Java 靜態分析工具的代碼缺陷檢測能力，本文將使用一段示例代碼進行試驗，示例代碼中將涵蓋我們開發中的幾類常見錯誤，如引用操作、對象操作、表達式復雜化、數 組使用、未使用變數或代碼段、資源回收、方法調用及代碼設計幾個方面。最後本文將分別記錄在默認檢查規范設置下，不同工具對該示例代碼的分析結果。以下為 示例代碼 Test.java。其中，代碼的注釋部分列舉了代碼中可能存在的缺陷。



• 清單 1. Test.java 示例代碼
• package Test;import java.io.*;public class Test {/** * Write the bytes from input stream to output stream. * The input stream and output stream are not closed. * @param is * @param os * @throws IOException */public boolean (InputStream is, OutputStream os)throws IOException {intcount = 0;//缺少空指針判斷byte[] buffer =new byte[1024];while((count = is.read(buffer)) >= 0) {os.write(buffer,0, count);}//未關閉I/O流returntrue;}/** * * @param a * @param b * @param ending * @return the elements from a to b, and stop when meet element ending */publicvoid (String[] a, String[] b, String ending){intindex;String temp =null;//空指針錯誤System.out.println(temp.length());//未使用變數intlength=a.length;for(index=0; index&a.length; index++){//多餘的if語句if(true){//對象比較 應使用equalsif(temp==ending){break;}//缺少 數組下標越界檢查b[index]=temp;}}}/** * * @param file * @return file contents as striwww.fltbj.cn#ll if file does not exist */public void readFile(File file) {InputStream is =null;OutputStream os =null;try{is =new BufferedInputStream(newFileInputStream(file));os =new ByteArrayOutputStream();//未使用方法返回值(is,os);is.close();os.close();}catch (IOException e) {//可能造成I/O流未關閉e.printStackTrace();}finally{//空的try/catch/finally塊}}}







• 通過以上測試代碼，我們對已有 Java 靜態代碼分析工具的檢驗結果做了如下比較，如下表 2 所示。




表 2. Java 靜態代碼分析工具對比

代碼缺陷分類

示例

Checkstyle

FindBugs

PMD

Jtest

引用操作 空指針引用 √ √ √ √

對象操作 對象比較（使用 == 而不是 equals） √ √ √

表達式復雜化 多餘的 if 語句 √

數組使用 數組下標越界 √

未使用變數或代碼段 未使用變數 √ √ √

資源回收 I/O 未關閉 √ √

方法調用 未使用方法返回值 √

代碼設計 空的 try/catch/finally 塊 √




由表中可以看出幾種工具對於代碼檢查各有側重。其中，Checkstyle 更偏重於代碼編寫格式，及是否符合編碼規范的檢驗，對代碼 bug 的發現功能較弱；而 FindBugs，PMD，Jtest 著重於發現代碼缺陷。在對代碼缺陷檢查中，這三種工具在針對的代碼缺陷類別也各有不同，且類別之間有重疊。

總結

本文分別從功能、特性和內置編程規范等方面詳細介紹了包括 Checkstyle，FindBugs，PMD，Jtest 在內的四種主流 Java 靜態代碼分析工具，並通過一段 Java 代碼示例對這四種工具的代碼分析能力進行比較。由於這四種工具內置編程規范各有不同，因此它們對不同種類的代碼問題的發現能力也有所不同。其中 Checkstyle 更加偏重於代碼編寫格式檢查，而 FindBugs，PMD，Jtest 著重於發現代碼缺陷。最後，希望本文能夠幫助 Java 軟體開發和測試人員進一步了解以上四種主流 Java 靜態分析工具，並幫助他們根據需求選擇合適的工具。

❷ 軟體破解中靜態分析與動態分析有什麼區別

軟體破解中靜態分析與動態分析區別為：對象不同、代碼覆蓋率不同、檢測不同。

一、對象不同

1、靜態分析：靜態分析是對程序文件（非運行狀態）行跟蹤。

2、動態分析：動態分析是對運行著的程序進行跟蹤。

二、代碼覆蓋率不同

1、靜態分析：靜態分析有完整的代碼覆蓋率。無論一個代碼塊或另一個代碼塊在執行時獲得控制的頻率，靜態分析都會檢查整個代碼庫。

2、動態分析：動態分析不能保證完整的代碼覆蓋率。需要向程序中饋入足夠的數據以獲得更好的結果並獲得盡可能多的代碼覆蓋率。

三、檢測不同

1、靜態分析：靜態分析不利於檢測內存泄漏和與並發相關的錯誤。

2、動態分析：動態分析可以檢測復雜的內存處理錯誤，例如超出數組范圍的索引編制和內存泄漏。

(2)安全編程代碼靜態分析擴展閱讀

程序靜態分析是與程序動態分析相對應的代碼分析技術，它通過對代碼的自動掃描發現隱含的程序問題，主要具有以下特點：

（1）不實際執行程序。動態分析是通過在真實或模擬環境中執行程序進行分析的方法，多用於性能測試、功能測試、內存泄漏測試等方面。與之相反，靜態分析不運行代碼只是通過對代碼的靜態掃描對程序進行分析。

（2）執行速度快、效率高。目前成熟的代碼靜態分析工具每秒可掃描上萬行代碼，相對於動態分析，具有檢測速度快、效率高的特點。

（3）誤報率較高。代碼靜態分析是通過對程序掃描找到匹配某種規則模式的代碼從而發現代碼中存在的問題，例如可以定位strcpy（）這樣可能存在漏洞的函數，這樣有時會造成將一些正確代碼定位為缺陷的問題，因此靜態分析有時存在誤報率較高的缺陷，可結合動態分析方法進行修正。

❸ 程序靜態分析的著名的靜態分析工具

Meta-Compilation（Coverity）
由Stanford大學的Dawson Engler副教授等研究開發，該靜態分析工具允許用戶使用一種稱作metal的狀態機語言編寫自定義的時序規則，從而實現了靜態分析工具的可擴展性。MC的實際效果非常優秀，號稱在Linux內核中找出來數百個安全漏洞。MC目前已經商業化，屬於Coverity Inc.2014年被Synopsys收購。目前學術領域比較認可的靜態分析工具，其技術處於領先地位。
mygcc 由一個法國人N. Volanschi開發，其思想來源於MC，試圖將自定義的錯誤檢測集成到編譯時。
Klocwork
國內用的最為廣泛的靜態分析工具，由加拿大北電於1996年研發，是中國最早的能夠檢測語義缺陷的靜態分析工具。截止到2015年其版本號為V10,也就是大家常說的K10
LDRA Testbed
英國的編碼規則類檢測工具，前身為Liverpool大學開發，能夠支持C/C++數千種條目的規則檢測，包括MISRA C/C++, GJB5369等，是最早進入中國市場的靜態分析工具，在軍隊、軍工廣泛使用，但其技術僅支持風格類檢測，無法進行語義缺陷分析，導致一些常用的運行時缺陷無法發現或者較高誤漏報，由此市場佔有率逐步下降。截止到2015年其版本號為9.5
HP Fortify
美國HP公司的支持安全漏洞類的檢測工具，能夠檢測C/C++/Java/PHP/ASP/JavaScript等多種語言，數千種檢測項，是國內使用最為廣泛的靜態分析工具。但該工具整體的誤報漏報率較高，雖然支持很多種安全漏洞，但需要用戶做很多的二次開發工作。
Cobot(庫博)
北京大學軟體工程中心研發的靜態分析工具，能夠支持編碼規則，語義缺陷的程序分析，能夠支持C/C++數千條規則和缺陷的檢測，是我國唯一可以稱的上是靜態分析產品的商業化工具。由於其自主知識產權，對國內的操作系統，編碼標准支持的較好，檢測精度也基本與上述工具持平，所以也得到了很多用戶的認可。
Parasoft C++Test
美國Parasoft公司研發的支持C、C++靜態分析的工具，該工具除了可以檢測編碼規則外，還能檢測少量的語義缺陷，此外能夠進行測試用例生成。

❹ 什麼是靜態測試靜態測試主要採用哪些測試方法

靜態測試是指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性。靜態測試主要採用白盒測試方法。

對需求規格說明書、軟體設計說明書、源程序做結構分析、流程圖分析、符號執行來找錯。靜態方法通過程序靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變數、空指針的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，並為測試用例選取提供指導。

(4)安全編程代碼靜態分析擴展閱讀

靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，充分發揮人的邏輯思維優勢，也可以藉助軟體工具自動進行。代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面。

可以發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變數檢查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。

在實際使用中，代碼檢查比動態測試更有效率，能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷；代碼檢查看到的是問題本身而非徵兆。

但是代碼檢查非常耗費時間，而且代碼檢查需要知識和經驗的積累。代碼檢查應在編譯和動態測試之前進行，在檢查前，應准備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標准和代碼缺陷檢查表等。

靜態測試具有的發現缺陷早、降低返工成本、覆蓋重點和發現缺陷的概率高的優點以及耗時長、不能測試依賴和技術能力要求高的缺點。

❺ 什麼叫靜態安全分析及動態安全分析

安全分析是對運行中的網路或某一研究態下的網路,按N-1原則,研究一個個運行元件因故障退出運行後,網路的安全情況及安全裕度。靜態安全分析是研究元件有無過負荷及母線電壓有無越限。動態安全分析是研究線路功率是否超穩定極限

❻ 靜態代碼分析 和 代碼審計的區別

靜態代碼分析是代碼審計的方式之一，即代碼審計也可以通過其他方式來審查源碼的安全。比如，運行該源碼，執行針對性的操作等。
靜態代碼分析就是在不運行軟體源碼的情況下，從數據流、語義、結構、控制流、配置流等方面對源代碼進行的分析。
代碼審計（Code
audit）是一種以發現程序錯誤，安全漏洞和違反程序規范為目標的源代碼分析。

❼ 靜態分析是指

經濟領域概念
靜態分析是一種分析經濟現象的均衡狀態以及有關的經濟變數達到均衡狀態所需要條件的分析方法。[1]而不考慮經濟現象達到均衡狀態的過程，它完全抽象掉了時間因素和具體的變化過程，是一種靜止地、孤立地考察某種經濟事物的方法。
網路


靜態分析
經濟領域概念
靜態分析是一種分析經濟現象的均衡狀態以及有關的經濟變數達到均衡狀態所需要條件的分析方法。[1]而不考慮經濟現象達到均衡狀態的過程，它完全抽象掉了時間因素和具體的變化過程，是一種靜止地、孤立地考察某種經濟事物的方法。

中文名
靜態分析
外文名
static analysis
指標
總量指標、相對指標、平均指標、標志變異指標等
應用
靜態計算機科學、經濟學、工程、力學、機械
釋義
根據既定的外生變數值求得內生變數的分析方法
內涵
靜態分析法是根據既定的外生變數值求得內生變數的分析方法，是對已發生的經濟活動成果，進行綜合性的對比分析的一種分析方法。

如研究均衡價格時，舍掉時間、地點等因素，並假定影響均衡價格的其他因素，如消費者偏好、收入及相關商品的價格等靜止不變，單純分析該商品的供求達於均衡狀態的產量和價格的決定。簡單地說就是抽象了時間因素和具體變動的過程，靜止地孤立地考察某些經濟現象。它一般用於分析經濟現象的均衡狀態以及有關經濟變數達到均衡狀態所需要的條件。

常用的靜態分析法有：相對數分析法、平均數分析法、比較分析法、結構分析法、因素替換分析法、綜合計算分析法、價值系數分析法等。

指標

❽ 靜態代碼分析應該怎麼操作呢

靜態代碼分析是代碼審計的方式之一，即代碼審計也可以通過其他方式來審查源碼的安全。比如，運行該源碼，執行針對性的操作等。

靜態代碼分析就是在不運行軟體源碼的情況下，從數據流、語義、結構、控制流、配置流等方面對源代碼進行的分析。
代碼中的bug往往是由於開發者忽略一些代碼缺陷而造成的，這些代碼缺陷可能是極其微小的錯誤，以至於在程序的編譯期並未給出很好的錯誤，從而導致這些代碼缺陷在程序的運行期以某種非正常形式呈現出來。

那麼對於開發這開說，這些微小的代碼缺陷，往往是很難跟蹤調試的，因此也為修復代碼帶來了很大困難。Xcode靜態代碼分析的作用即發現項目源代碼中的某些代碼缺陷，並分類進行提示，以方便開發者及時關注並加以修改，從而把代碼缺陷（潛在的bug）及時清除。

❾ 靜態代碼中能檢測到的錯誤有哪些

在傳統意義上認為，錯誤檢測應該是動態的系統測試的范圍。但在bug的成本上分析，有以下公認的結論。

bug發現的越晚，修正的成本就越高，測試階段修正bug的成本是編碼階段的約4倍的關系。為了減少成本，bug被發現的越早越好。在編程階段，靜態的分析代碼就能找到代碼的bug，是很多人的夢想。這個夢想在21世紀初變成了現實。以PolySpace、Klocwork、Coverity為代表的靜態分析軟體，實現了只要靜態分析代碼，就可以發現代碼的bug，例如數組越界、除數為0、緩沖區溢出等，雖然還不是特別完美。微軟在其最新的開發工具VisualStudio2005的teamsystemediton中集成了安全工具PREFix。PREFix原來就是著名的靜態分析工具，後被微軟收購過來。從微軟的傾向看發展走勢，類似的靜態工具未來會成為市場的主流。PolySpace詳細的信息可以參考我的另外一篇文章《嵌入式軟體動態運行時錯誤的檢測》。

❿ 代碼靜態檢查實現原理

靜態代碼分析原理分為兩種：分析源代碼編譯後的中間文件（如Java的位元組碼）；分析源文件。主要分析技術如下：

缺陷模式匹配
事先從代碼分析經驗中收集足夠多的共性缺陷模式，將待分析代碼與已有的共性缺陷模式進行匹配，從而完成軟體安全分析。優點：簡單方便；缺點：需要內置足夠多的缺陷模式，容易產生誤報。

類型推斷/類型推斷
類型推斷技術是指通過對代碼中運算對象類型進行推理，從而保證代碼中每條語句都針對正確的類型執行。

模型檢查
建立於有限狀態自動機的概念基礎上。將每條語句產生的影響抽象為有限狀態自動機的一個狀態，再通過分析有限狀態機達到分析代碼目的。
校驗程序並發等時序特性。

數據流分析
從程序代碼中收集程序語義信息，抽象成控制流圖，可以通過控制流圖，不必真實的運行程序，可以分析發現程序運行時的行為。