這篇文章是我撰寫的關于靜態分析入門的第一篇文章，旨在幫助新用戶在其開發過程中采用靜態分析工具。如果您起初沒有花時間來確保已確定適合項目的正確策略，那么上手入門可能會很棘手。

作為Parasoft的解決方案架構師，我們吸引了很多人在這一領域尋求幫助，所以知道您并不孤單！如果您想了解更多信息，可以下載并閱讀我幫助編寫的完整指南。

我假設您已安裝了靜態分析工具，并且已設置任何初始配置。此后，如果您起初沒有花時間來確保已確定適合項目的正確策略，那么上手可能會很棘手。在這里，“入門”的意思是更好地理解將靜態分析集成到現有項目中的一般方法，以及如何隨著時間的推移增加靜態分析的投資回報率。

什么是靜態分析？

簡單來說，靜態分析是檢查源代碼和二進制代碼而無需執行的過程，通常是為了查找錯誤或評估質量。與需要運行程序才能運行的動態分析（例如Parasoft Insure++）不同，靜態分析可以在源代碼上運行，而無需可執行文件。

這意味著可以對部分完整的代碼、庫和第三方源代碼使用靜態分析。開發人員可以使用靜態分析，也可以在編寫或修改代碼時使用靜態分析，也可以在任何任意代碼基礎上應用靜態分析。

支持安全性的靜態分析

在應用程序安全域中，靜態代碼分析用術語“靜態應用程序安全性測試（SAST）”進行。靜態分析可以支持安全漏洞檢測以及錯誤檢測、質量指標和編碼標準一致性。

支持功能安全和編碼標準的靜態分析

諸如ISO 26262或EN 50128之類的功能安全標準還要求（或者在某些情況下，“強烈推薦”）靜態分析工具，因為它們能夠檢測出難以發現的缺陷并提高軟件的安全性。當然，這還涉及到安全性，因為靜態分析工具還可以幫助軟件團隊符合主要用于驗證安全編碼的編碼標準，例如CERT甚至是MISRA。

將靜態分析引入您的項目

靜態分析工具的一大優點是，可以在項目的任何階段引入和使用它們，即使項目不完整且未部分編碼，該工具仍然有效。引入靜態分析的最大挑戰是大量代碼會產生大量警告。因此，將靜態分析集成到項目中時，重點應放在使團隊盡快變得高效上，并最大程度地減少團隊被所有靜態分析警告淹沒的機會。這并不是要降低這些警告的重要性，但是大多數開發人員沒有（至少不是立即）修復現有或遺留代碼的奢侈手段。

重點應該是將工具集成到日常流程中，以便最大程度地訪問和使用，然后處理最關鍵的錯誤和安全漏洞。一旦團隊變得更加熟練，您就可以專注于優化工具和流程以提高投資回報率。

以終為始

為了充分利用靜態分析，了解最終目標非常重要。例如，如果目標是更高的安全性，這將影響分析和補救的重點，或者目標是符合諸如MISRA C之類的編碼標準，那么重點將成為滿足編碼標準并根據需要向認證實體證明。

初次采用靜態分析時，很容易陷入陷阱，那就是越好越好（即，更多的分析和更多的警告意味著您將從工具中獲得最大的價值）。這是一個常見的陷阱。相反，要專注于最終目標。

如果以安全為重點，則應將重點放在提高安全性上，并減少對其他類型警告的干擾。當然，關鍵的bug總是很重要，要找到它們，但是它們不應該偏離主要目標。隨著時間的推移，隨著團隊的精通，您將能夠納入其他次要目標，例如提高整體質量或執行編碼標準。隨著靜態分析成為每個開發人員日常工作的一部分，他們將能夠更快地分析結果并更有效地修復錯誤。此時，次要目標將更有效地實現，而不是簡單地被壓倒。

在產品成熟度的每個階段引入靜態分析的策略

一旦了解了要關注的主要目標，就需要確定開發中產品的成熟度，因為它會影響采用靜態分析的方式。考慮下面的主要開發階段，并確定項目適合的位置，以便您了解哪種采用方法最適合您。

現有項目——當前開發中

最常見的情況是決定使用靜態分析并將其推廣到其當前項目的軟件組織。

每個項目都可以選擇在沖刺開始時或在重大新功能更新開始時采用這些工具。實際上，軟件團隊一直在工作——即使一個產品“完成”，另一個版本或變體也在開發中。這種采用方案的關鍵方面是每天都有大量的現有代碼和新代碼正在開發。推薦的集成方法被稱為“行之有效”的方法，這意味著在開發新代碼時會對其進行改進，同時將不太重要的警告延遲為技術債務。我們稍后再討論。

現有項目——維護市場上的產品

對成熟的產品采用靜態分析可能會與仍在開發的項目有不同的目標。這是一種產品，處于軟件開發生命周期的較早階段，僅編寫很少的新代碼即可解決遺留的錯誤和安全漏洞。對這些項目采用靜態分析的主要方法稱為“確認并推遲”。用這種方法，由于很少開發新代碼，因此將所有發現的錯誤和安全漏洞添加到現有技術債務中。

未開發項目

盡管軟件團隊通常不會有一個嶄新的起點，但是新產品和項目是將新工具和技術集成到開發過程中的理想點。

在這些項目中，幾乎沒有特定于該項目的現有代碼，但它仍可能依賴于第三方和開源軟件。開發人員可以從一開始就將靜態分析集成到他們的開發環境中，以確保在編寫代碼時獲得高質量的標準。這允許采用編碼標準，并確保在出現嚴重的靜態分析警告時對其進行處理，從而為技術債務增加了更少的錯誤和漏洞。在這種情況下，采用的方法恰當地稱為“未開發的地區”。

靜態分析采用方法：如何管理早期的靜態分析報告

在將靜態分析工具安裝到項目中之后，通常會有相當長的關于該工具報告的違規和警告的報告。這可能是不堪重負的，尤其是在大型代碼庫中，因此，如何管理這些初始報告直接影響將工具集成到項目中的成功。

 并非所有警告都至關重要，因此不需要立即處理所有問題。學習立即解決什么和推遲解決什么是成功的關鍵。如上所述，產品的成熟度和尺寸對方法有直接影響，下文將對此進行詳細概述。

排沙法

顧名思義，通過這種方法，開發人員決定在進行初步分析后，他們不會再將任何嚴重的警告和違規行為輸入代碼庫。換句話說，他們承諾分析每個嚴重警告，以決定其準確性，并在錯誤確實存在時及時實施修復。

團隊還可以決定添加在現有代碼中已經發現的嚴重警告，以將其添加到其報告工具中的錯誤列表中。這些類型的警告的示例可能是嚴重的安全漏洞（例如SQL注入）或嚴重的內存錯誤（例如緩沖區溢出）。在大多數情況下，不太嚴重的警告可以推遲到以后進行分析。您可能會想，“這不只是增加了我們的技術債務嗎？”如果是，那是對的！但是在這個階段，我們可以接受。這些警告中的任何潛在錯誤已在技術債務堆中。至少現在，它們已被識別，以后更容易修復。

確認和延遲法

如果產品已經投放市場并且正在維護中，則識別代碼中任何遺留的錯誤和安全漏洞仍然是有益的，但是對于開發人員來說，分析（更不用說修復）所有這些警告是不可行的。

在這種情況下，查看最重要的報告并決定采取的措施是有意義的。其余警告被確認，因為軟件團隊認識到它們的存在，但是大多數情況下將它們推遲到以后。 （這再次增加了組織的技術負擔，但是如上所述，這些錯誤在技術上已經以技術負擔的形式存在。）此方法與“一線原則”方法的不同之處在于，在確定關鍵警告之后，您只需推遲其余的，無需任何分析。

新建項目法

現有代碼很少的項目是進行靜態分析的理想起點。在這種情況下，軟件團隊可以調查所有出現的警告并修復發現的錯誤。與其他方法不同，只有很少的警告需要管理，因此開發人員可以處理額外的工作量。這也是通過工具實施和實施編碼標準的理想時機，因為可以在IDE中以及在將任何代碼提交給版本控制之前（在這里描述的其他情況下也可以這樣做）識別和修復違規情況。 。

靜態分析在成熟度的三個主要階段中的采用方式通過處理警告積壓的方式有所不同，如下所示：

在三個主要的成熟階段采用靜態分析：在一個新建項目中，大多數報告的警告都得到了調查和修復，而很少涉及技術債務。正在開發的項目往往積壓了大部分待處理的警告，而只處理關鍵警告，而維護中的產品往往會推遲大多數警告。

配置與過濾

開源或輕量級靜態分析工具與商業高級靜態分析工具之間的主要區別之一是能夠配置啟用了哪些檢查程序集進行分析，以及根據警告類別、文件名、嚴重性和其他屬性過濾出報告的結果。這有助于實現不被淹沒的目標——開發人員可以僅關注他們感興趣的警告類型，并減少在任何給定時間提供的信息量。

在配置檢查器和過濾結果之間也需要注意一個差異。盡管最初似乎最好限制全局配置中的規則數量，但是應該經常使用過濾來限制報告的范圍，而不是完全消除檢查程序。如果在配置中關閉了后來證明很重要的規則，則警告存儲庫中將沒有歷史記錄，因此您將無法找出錯誤是由于最近的更改引起的還是代碼中已經存在的在采用靜態分析之前。

我建議使用配置將規則集僅限制為可預見的對軟件團隊有用的規則。同樣，從最終目標開始：如果提高安全性是關鍵目標，那么啟用所有與安全性相關的規則，禁用次要的規則并啟用諸如CERT C之類的內置安全編碼標準是有意義的。然后，如果您使用的是諸如Parasoft C/C++test之類的高級靜態分析解決方案，則可以利用其內置的管理工具來處理從靜態分析報告生成的數據，并推動未來的發展重點。

總結

靜態分析工具使軟件組織無需執行代碼即可檢測和跟蹤錯誤的安全漏洞。這些工具可以應用于現有的、遺留的和第三方代碼并提供質量。

靜態分析的采用在一定程度上根據項目的成熟度而有所不同。大量的代碼確實會導致大量警告。這是完全可管理的，能否成功采用取決于團隊決定如何處理結果。針對項目的每個主要成熟度級別引入了各種技術，以及如何將這些工具集成到開發人員、團隊負責人和經理的日常工作流程中。

在我的下一篇文章中，我將討論將靜態分析集成到您的日常工作流程中，請繼續關注！