專業軟件測試工程師告訴你：如何選擇現代的靜態分析工具

---

從50000英尺的高度看，所有靜態分析工具看起來都一樣。他們分析代碼，不執行代碼并發現缺陷、漏洞和其他問題。

所有工具都會生成警告和報告。它們通常集成到IDE和CI/CD/build系統中。如果您想成功地將任何編碼工具集成到您的日常開發中并獲得最大的投資回報，則必須全面評估您的選擇。

超越靜態分析工具

 當試圖確定哪種靜態分析工具最有效時，許多評估人員會采用一種通用的方法來為其團隊或組織選擇工具。他們使用相同的代碼運行每個工具，比較結果，然后立即選擇報告最多違規情況的工具。

這并不是真正的產品評估。這是一場烘烤。贏家不一定是在團隊或組織內建立可持續、可擴展的靜態分析過程的最佳工具。

實際上，在成功進行這些靜態分析時，通常會忽略許多關鍵因素，這些因素是成功采用靜態分析與另一失敗嘗試之間的區別。

評估您的靜態代碼分析需求和當前狀況

在開始尋找工具之前，請對您的組織進行殘酷誠實的調查。評估以下內容：

您的組織需要什么。要成功進行靜態分析，重要的是要了解要解決的問題。

• 靜態分析正在解決哪些具體的痛點？
• 組織是否有合規要求？
• 應用程序安全性值得關注嗎？
• 已經做什么了？
• 誰需要查看分析報告并采取行動？

您的組織所在的位置。了解新工具的目的以及它們是否適合您的組織也很重要。

• 您當前的開發過程是否穩定，可重復且精簡，足以為靜態分析奠定堅實的基礎？
• 先前評估或實施靜態分析工具的結果是什么？

工具選擇過程中的標準

在開發過程中選擇靜態分析工具進行采用和最終集成需要付出努力和計劃。這不僅僅是技術審查。該過程需要檢查該工具與您的組織的適合程度。評估銷售和支持工具的供應商也很重要。

工具評估標準

以下是對候選工具進行技術評估時要考慮的標準：

• 必要準則的涵蓋范圍
• 內置檢查器的質量，以獲取必要的準則
• 覆蓋行業和企業標準
• 分析的深度和廣度
• 減少噪音的實用方法（違反可忽略的檢查程序）
• 誤報的合理數量和方法
• 可接受的假陰性數
• 輕松調整內置檢查器以適合您組織的政策
• 輕松添加新的自定義檢查器以檢查唯一需求
• 新的自定義檢查器支持的復雜程度

供應商注意事項

選擇正確的供應商與選擇正確的工具一樣重要。當組織獲得工具時，他們即承諾與所選供應商建立關系。

在大多數成功的工具部署背后，有一家供應商致力于幫助組織實現業務目標，應對表面挑戰并推動采用。

在整個評估過程中，必須考慮幾層供應商資格和評估。此時，請考慮以下事項：

• 供應商對規模、增長和愿景的能力支持是否符合您的要求和目標？
• 供應商是否有一致的策略來在整個組織中進行部署，以及如何隨著組織需求的變化而發展
• 供應商推薦使用其工具的“最佳做法”是什么？

了解供應商在市場中的聲譽也很重要。回答這些問題：

• 哪些組織正在使用該工具？
• 案例研究揭示了其部署、使用和收益的哪些方面？
• 行業專家在評論、文章和獎項中怎么說？

質量與數量：關于覆蓋范圍

潛在客戶的一個常見問題是：您的產品有幾個檢查器？

這個問題暗示著工具的質量取決于它所涵蓋的不同錯誤的數量。對于任何工具（尤其是靜態分析工具）而言，這都是很差的措施。

靜態分析工具的用戶應該真正關心每個工具覆蓋不同錯誤類型，編碼標準和分析深度的程度。一個常見的例子是每個供應商聲稱他們的工具聲稱CWE Top 25或OWASP Top 10或MISRA C/C++覆蓋率。

看到供應商聲稱100％覆蓋了流行的編碼標準并不少見。通常會引起誤解的說法。真正的問題應該是，而不是擔心檢查程序或規則的數量：工具覆蓋您所關注的編碼問題的程度如何？

示例：MISRA C，C++和CERT C覆蓋范圍

盡管像MISRA這樣的編碼標準已經扎根于汽車領域，但它們的采用正遍及其他對安全至關重要的領域。與市場需要的SEI CERT C一起使用，或用于降低軟件開發的風險。無論用例如何，這些標準都不可避免地用于評估靜態分析工具。

但是，由于每個標準的覆蓋范圍聲明并未準確定義工具對覆蓋范圍的聲明方式，因此可以解釋。深入研究可能對您的用例重要的特定功能具有價值。例如，如果您的項目需要MISRA C，則應詳細查看每種工具的功能。

考慮以下對各種開源和商業解決方案的評估，以評估它們對MISRA和CERT C標準的覆蓋范圍：

開源解決方案的覆蓋率很差，這并不奇怪，因為它們的意圖從未遵循這樣的標準。但是，通常聲稱支持這些標準的各種商業工具并沒有真正交付。在這里重要的真正評估標準是標準的覆蓋范圍，而不是支持該標準所需的檢查人員數量。

但是，在使用測試套件衡量標準的覆蓋率時，您還需要考慮測試套件本身的覆蓋率。下圖的Juliet CWE Top 25（2011）覆蓋范圍圖像列出了通用弱點枚舉（CWE）ID以及Juliet C/C++和Java測試套件中的任何測試是否涵蓋了它們。您可以清楚地看到測試套件沒有完全覆蓋重要的CWE（前25名），這在許多測試套件中都是常見的。

開源解決方案

關于將靜態分析解決方案使用開源工具的問題顯而易見。FOSS需要牢記一些關鍵問題。評估需要包括缺少的重要功能，服務和支持的成本。

通常，這里提供有關FOSS成本和收益的詳細信息，包括支持、項目活動和壽命以及可伸縮性等問題。如果行業標準很重要，并且外部審核是您業務的一部分，則FOSS解決方案可能不是一個選擇。

需要回答的問題

在評估每個試點項目的結果時，評估和最終決策應歸結為回答以下關鍵問題：

團隊會真正采用并使用它嗎？如果無法部署，開發人員不使用它，或者對項目進度造成太大干擾，那么世界上最好的工具將無法提供任何價值。要確定采用某項工具的程度，不僅需要對工具、檢查器和集成進行全面評估，還需要對供應商，其支持、服務和培訓進行全面評估。

它會解決組織和團隊正在嘗試解決的問題嗎？部署新技術需要專注于要解決的問題，而不僅僅是期望靜態分析將解決您的問題。

此外，對解決該問題的新技術的期望應該是現實的。量化成功和投資回報很重要。務必提前確定如何衡量成功：損失的時間，錯過的發布或現場支持案例。

這是一個長期的解決方案嗎？評估很耗時，需要團隊投入。全面部署需要更多的時間和精力。選擇一種“目前已經足夠好”的工具可能會在短期內節省金錢，但從長期來看卻非常昂貴。

總結

靜態分析工具的評估通常最終會失敗，在此過程中，每個工具都在同一段代碼上進行測試并根據結果進行評估。盡管這是有用的并且技術評估很重要，但是評估人員還需要超越這些結果，以更大的眼光看待更長的時間。

評估人員需要考慮工具如何有效地管理結果，包括易于使用的可視化和報告。 團隊應該清楚地了解每種工具如何支持在編碼標準等領域提出的主張。