如果您最初沒有花些時間來確保已經確定了為項目采取的正確策略，那么開始入門的話可能會非常棘手。

假設您的靜態分析工具已經安裝，并且已經設置好了初始配置。在那之后，如果您一開始沒有花些時間確保已經確定好了為項目采取的正確策略，那么入門就可能會非常麻煩。在這里，我所說的“入門”是指更好地理解將靜態分析集成到現有項目中的一般方法，以及如何提高靜態分析隨時間的投資回報。

什么是靜態分析？

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

這意味著靜態分析可用于部分完整的代碼，庫和第三方源代碼。開發人員可以訪問靜態分析，用于編寫或修改代碼，或者應用于任意代碼庫。

支持安全的靜態分析

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

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

靜態分析工具也被強制性安全標準（如ISO 26262或EN 50128）強制要求（或在某些情況下可理解為“強烈推薦”），因為它們能夠檢測難以發現的缺陷并提高軟件的安全性。當然，靜態分析工具還可以幫助軟件團隊遵守主要用于驗證安全編碼的編碼標準，例如CERT甚至MISRA。

將靜態分析引入您的項目

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

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

從確定最終目標開始

為了充分利用靜態分析，了解最終目標非常重要。例如，如果目標是更好的安全性，那將決定分析和補救的重點，或者如果目標是遵守MISRA C等編碼標準，那么重點將變得滿足編碼標準，并根據需要向認證實體證明。

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

如果以安全為重點，請將重點放在提高安全性和減少其他類型警告的注意力上。當然，關鍵錯誤很重要，但它們不應該分散您對于主要目標的注意力。隨著時間的推移，隨著團隊變得更加熟練，您將能夠納入其他次要目標，例如提高整體質量或實施編碼標準。隨著靜態分析成為每個開發人員日常工作的一部分，他們將能夠更快地分析結果并更有效地修復錯誤。在這個時候，將更有效地實現次要目標。

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

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

現有項目 - 當前發展

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

每個項目都可以選擇在sprint開始時或在主要新功能更新開始時采用這些工具。實際上，軟件團隊總是在工作 - 即使一個產品“完成”，另一個版本或變體正在進行中。這種采用方案的關鍵方面是每天都有大量現有代碼和新代碼。推薦的集成方法被稱為“一條界限”方法，這意味著在開發新代碼時將其改進，同時將不太重要的警告作為技術債務推遲。我們馬上談談這個問題。

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

對成熟產品采用靜態分析可能與仍在開發中的項目有不同的目標。這是一個處于軟件開發生命周期的長年中的產品，其中編寫的新代碼很少，只能修復揮之不去的錯誤和安全漏洞。對這些項目采用靜態分析的主要方法稱為“確認和推遲”。在這種方法中，由于開發的新代碼很少，所有發現的錯誤和安全漏洞都會被添加到現有的技術債務中。

綠地項目（未開發的新項目）

雖然軟件團隊通常不會重新開始，但新產品和項目是將新工具和技術集成到開發過程中的理想點。

在這些項目中，幾乎沒有特定于項目的現有代碼，但它仍然可能依賴于第三方和開源軟件。開發人員可以從一開始就將靜態分析集成到他們的開發環境中，從而在編寫代碼時確保高質量的標準。這允許采用編碼標準并確保在出現時處理關鍵的靜態分析警告，從而減少技術債務堆中的錯誤和漏洞。在這種情況下采用的方法恰當地命名為“綠地”。

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

一旦將靜態分析工具安裝到項目中，該工具通常會報告相當長的違規和警告報告。特別是在大型代碼庫中，因此如何直接管理這些初始報告會影響將工具集成到項目中的成功。

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

界限法

顧名思義，在這種方法中，開發人員決定在初步分析之后，他們不會讓任何更嚴重的警告和違規進入代碼庫。換句話說，他們承諾分析每個關鍵警告以確定其準確性，如果它確實是一個錯誤，就及時修復。

團隊還可能決定在現有代碼中添加已發現的關鍵警告，以將其添加到其報告工具中的錯誤列表中。這些類型的警告的示例可能是嚴重的安全漏洞，如SQL注入，或嚴重的內存錯誤，如緩沖區溢出。在大多數情況下，可以推遲不太嚴重的警告以供之后分析。你可能會想，“這不是會增加我們的技術債務嗎？”，說得沒錯！這些警告中的任何潛在錯誤都已經在技術債務堆中了。至少在現在，它們被識別出來并且以后更容易修復。

確認和推遲處理方法

如果產品已經處在市場上并且正在維護中，那么識別代碼中的錯誤和安全漏洞仍然是需要的，但開發人員對所有這些警告都分析（更不用說修復）是不可行的。

在這種情況下，查看最重要的報告并確定行動方案才是最有意義的。其余的警告都得到了確認，因為軟件團隊認識到它們存在，但它們大多數都會被推遲處理。（這再次增加了該組織的技術債務，但如上所述，這些漏洞在技術上已經存在作為技術債務。）這種方法不同于界限方法，因為在確定關鍵警告后，您只需推遲其余的，沒有任何分析。

綠地方法

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

在成熟的三個主要階段采用靜態分析，可以通過如何處理積壓的警告來區分，如下圖所示：

在成熟的三個主要階段采用靜態分析：在綠地項目中，大多數報告的警告都經過調查和修復，幾乎沒有進入技術債務堆。正在開發的項目往往會積壓大量的警告，這些警告大部分都是推遲處理，只處理嚴重警告，維護中的產品往往會推遲大多數警告。

配置與過濾

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

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

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

總結

靜態分析工具使軟件組織能夠檢測和跟蹤錯誤安全漏洞，而無需執行代碼。這些工具可應用于現有，傳統和第三方代碼并提供質量保障。

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

在我的下一篇文章中《Parasoft教您如何將靜態分析集成到日常工作流程中》，我將討論將靜態分析集成到您的日常工作流程中，推薦閱讀。

想要了解Parasoft、Parasoft SOAtest、Parasoft Virtualize更多信息或資源的朋友，請