1、.使用靜態分析，減輕團隊壓力作為Parasoft的解決方案架構師，我們接觸過很多在這方面尋求幫助的人，所以有這方面疑惑的不止你一個人！如果你想了解更多信息，可以下載并閱讀我整理的完整指南（https:/alm.parasoft./getting-started-with-static-analysis-whitepaper）。首先我們假定你已經安裝了靜態分析工具并配置了所有初始設置。除此以外，如果剛開始沒有確定項目需要采取的策略，入門會比較困難。這里我所說的“入門”是指深入理解將靜態分析集成到現有項目中的一般方法，以及如何提高靜態分析隨著時間的推移帶來的投資回報。什么是靜態分析.簡單來說，靜態

2、分析是在不執行代碼的情況下檢查源代碼和二進制代碼的過程，通常用于查找bug的前期準備或評估代碼質量。與需要運行程序的動態分析（例如Parasoft Insure +）不同，靜態分析可以直接分析源代碼而不需要執行源代碼。這意味著靜態分析可用于部分完整的代碼，庫和第三方源代碼。開發人員可以將靜態分析應用在編寫或修改代碼的過程中，甚至可以應用到任何代碼庫。支持安全檢測在應用程序安全域中，靜態代碼分析采用了靜態應用程序安全性測試（SAST）技術。靜態分析可以支持安全漏洞檢測，同時支持bug檢測，質量指標和編碼標準一致性檢測。支持功能安全和編碼標準另外，靜態分析工具強制要求（在某些情況下“強烈推薦”）能

3、夠支持安全標準（如ISO 26262或EN 50128）的檢測，因為這些標準能夠檢測難以發現的缺陷并提高軟件的安全性。當然，這又回歸到安全性的問題上，因為靜態分析工具還可以幫助軟件團隊遵守主要用于驗證安全編碼的編碼標準，例如CERT甚至MISRA。為你的項目使用靜態分析靜態分析工具的一個優點是它們可以在項目的任何階段引入和使用，即使項目是不完整的或者只有部分編碼是有效的。引入靜態分析的最大難點在于代碼量大會產生大量的警告。因此，將靜態分析應用到項目中時的重點應該是使團隊能夠盡快高效工作，并最大限度地減少團隊被靜態分析的警告困擾的情況。這并不是說這些警告不重要，但大多數開發人員都不會修復現有或遺

4、留代碼缺陷，至少不是立即處理。最重要的應該是將靜態分析運用到日常流程中，以便最大化靜態分析的使用效果和可用性，然后處理最危險的bug和安全漏洞。一旦團隊變得更加熟練，你就可以專注于優化工具和流程，提高投資回報率。開始前設定目標為了充分利用靜態分析，了解最終目標非常重要。例如，如果目標是安全性，那么重點是決定分析和補救的策略，或者如果目標是遵守MISRA C等編碼標準，那么重點將變成滿足編碼標準，并根據需要向認證機構認證。當第一次采用靜態分析時，很容易陷入一個陷阱越多越好（即分析和警告越多意味著你從工具中獲的價值越大）。這是一個常見的陷阱。與之相反，我們需要專注于最終目標。如果安全性是重點，請你

5、將注意力放在提高安全性和減少其他類型警告上。當然，致命的bug也很重要，但它們不應該分散主要目標。隨著時間的推移，團隊變得更加熟練，你將能夠納入其他次要目標，例如提高整體質量或實施編碼標準。隨著靜態分析成為每個開發人員日常工作的一部分，他們將能夠更快地分析結果并更有效地修復bug。到了這個時候，你將能夠更有效地實現次要目標，而不是一開始的忽視。在產品每個階段使用靜態分析的策略一旦確立了主要目標，下面就需要確定產品的成熟度，因為它會影響靜態分析的采用方式。下面列出了產品的主要開發階段，確定你的項目的所在階段，然后采取合適的方法?，F有項目 開發中最常見的方案是團隊決定使用靜態分析的規則，并將其推廣

6、到當前項目。每個項目都可以選擇在sprint開始時或在主要新功能更新開始時使用靜態分析。實際上，軟件團隊一直在工作 - 即使一個產品“完成”，因為另一個版本或變體進入開發。這種情況的關鍵在于每天都有大量現有代碼和新代碼。推薦被稱為“底線”方法的集成方法，主要的思想是在開發新代碼時將其改進，同時將不太重要的警告作為技術債務推遲。我們后面會詳細談談這個問題。現有項目 - 維護中對成熟的產品采用靜態分析可能與仍在開發中的項目有不同的目標。這是一個處于軟件開發生命周期后期的產品，其中編寫的新代碼很少，只有修復揮之不去的bug和安全漏洞。對這些項目采用靜態分析的主要方法稱為“確認和推遲”。在這種方法中，

7、由于開發的新代碼很少，所有發現的bug和安全漏洞都會被添加到現有的技術債務中。新項目（Greenfield Project）既然軟件團隊通常不會重新開始，那新產品和項目是將新工具和技術集成到開發過程中的理想點。在這些項目中，幾乎沒有特定于項目的現有代碼，但它仍然可能依賴于第三方和開源軟件。開發人員可以從一開始就將靜態分析集成到他們的開發環境中，從而在編寫代碼時確保高質量的標準。這允許采用編碼標準并確保在出現時處理關鍵的靜態分析警告，從而減少技術債務堆中的bug和漏洞。在這種情況下采用的方法恰當地命名為“綠地”。靜態分析采用方法：如何管理早期靜態分析報告一旦將靜態分析工具安裝到項目中，該工具通常

8、會報告相當長的違規和警告報告。這可能是多到無法處理的，特別是在大型代碼庫中，因此如何管理這些報告將會直接影響到工具集成到項目中能否成功。并非所有警告都是至關重要的，因此不需要立即處理所有警告。學習哪些需要立即解決而哪些需要推遲處理是成功的關鍵。如上所述，產品的成熟度和規模對方法有直接影響，下面將更詳細地概述。底線方法顧名思義，在這種方法中，開發人員決定在初步分析之后，他們不會讓任何更嚴重的警告和違規進入代碼庫。換句話說，他們需要分析每個警告來確定其準確性，并及時修復，如果它確實是一個bug。團隊還可以決定在現有代碼中添加已發現的關鍵警告，并將其添加到報告工具中的bug列表中。這些類型的警告可能

9、是嚴重的安全漏洞，如SQL注入，或嚴重的內存錯誤，如緩沖區溢出。在大多數情況下，可以推遲不太嚴重的警告以供以后分析。你可能會想，“這不僅僅會增加我們的技術債務嗎.”如果你這樣想，那你就是對的！但在這個階段，我們對此表示滿意。這些警告中的任何潛在錯誤都已經在技術債務堆中。至少現在，它們被識別出來并且以后更容易修復。確認并推遲處理方法如果產品已經在市場上并且正在維護中，那么識別代碼中的任何bug和安全漏洞仍然是有益的，但讓開發人員分析（更不用說修復）所有這些警告是不可行的。在這種情況下，查看最重要的報告并確定行動方案是有意義的。其余的警告只需要確認，因為軟件團隊認識到它們存在，但它們大多數都被推遲

10、了。（這再次增加了該組織的技術債務，但如上所述，這些漏洞在技術上已經存在作為技術債務。）這種方法不同于底線方法的地方在于確定關鍵警告后，你會推遲其余的警告，而不需要所有的都分析。綠地方法現有代碼很少的項目是靜態分析的理想起點。在這種情況下，軟件團隊可以調查出現的所有警告并修復發現的錯誤。與其他方法不同，你只需要管理很少的警告，因此開發人員可以解決額外的工作。這也是通過這些工具實現和實施編碼標準的理想時間，因為可以在IDE中以及在將任何代碼提交到版本控制之前識別和修復違規（你可以在此處描述的其他方案中執行此操作）。在三個主要階段采用何種靜態分析，可以通過如何處理積壓的警告來區分，如下所示：在三個

11、主要階段采用靜態分析：在綠地項目中，大多數報告的警告都經過調查和修復，幾乎沒有進入技術債務堆。正在開發的項目往往會積壓大量的警告，這些警告大部分都是推遲處理，只處理嚴重警告，維護中的產品往往會推遲大多數警告。配置與過濾開源或輕量級靜態分析工具與商業高級靜態分析工具之間的主要區別之一在于能否配置為分析啟用哪組檢查器，并根據警告類別，文件名，嚴重性等過濾掉報告的結果屬性。這有助于突出目標開發人員可以專注于他們感興趣的警告類型，并減少在任何時間產生的垃圾信息量。配置檢查器和過濾結果之間也存在差異。盡管一開始限制全局配置中的規則數量似乎更好，但通常應使用過濾來限制報告X圍，而不是完全消除檢查程序。如果

12、在配置中關閉后來證明是重要的規則，則警告存儲庫中將沒有歷史記錄，因此你將無法確定錯誤是由最近的更改引入還是在靜態分析之前已經在代碼中。我建議使用配置將規則集限制為可預見對軟件團隊有用的規則。同樣，以最終目標為出發點：如果提高安全性是關鍵目標，那么啟用所有與安全相關的規則，禁用不太重要的規則，啟用CERT C等內置安全編碼標準。如果你正在使用Parasoft C/C+test等高級靜態分析解決方案，你可以利用其內置的管理工具來處理靜態分析報告中生成的數據，并推進未來的重點開發工作?？偨Y靜態分析工具使團隊無需執行代碼，就能夠檢測和跟蹤錯誤安全漏洞。這些工具可應用于現有、傳統和第三方代碼并提供質量審查結果。采用何種靜態