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

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

什么是靜態(tài)分析？

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

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

支持安全的靜態(tài)分析

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

靜態(tài)分析，支持功能安全和編碼標準

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

將靜態(tài)分析引入您的項目

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

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

從確定最終目標開始

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

當?shù)谝淮尾捎渺o態(tài)分析時，很容易陷入更大的陷阱（即更多分析和更多警告意味著您從工具中獲得最大價值）。這是一個常見的陷阱。相反，請始終專注于最終目標。

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

在產(chǎn)品成熟度的每個階段引入靜態(tài)分析的策略

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

現(xiàn)有項目 - 當前發(fā)展

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

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

現(xiàn)有項目 - 維護市場上的產(chǎn)品

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

綠地項目（未開發(fā)的新項目）

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

在這些項目中，幾乎沒有特定于項目的現(xiàn)有代碼，但它仍然可能依賴于第三方和開源軟件。開發(fā)人員可以從一開始就將靜態(tài)分析集成到他們的開發(fā)環(huán)境中，從而在編寫代碼時確保高質(zhì)量的標準。這允許采用編碼標準并確保在出現(xiàn)時處理關鍵的靜態(tài)分析警告，從而減少技術債務堆中的錯誤和漏洞。在這種情況下采用的方法恰當?shù)孛麨椤熬G地”。

靜態(tài)分析采用方法：如何管理早期靜態(tài)分析報告

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

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

界限法

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

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

確認和推遲處理方法

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

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

綠地方法

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

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

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

配置與過濾

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

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

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

總結

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

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

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

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