Parasoft作為軟件測(cè)試工具，小編接觸過很多在這方面尋求幫助的人，所以有這方面疑惑的不止你一個(gè)人哦！

我們假定你已經(jīng)安裝了靜態(tài)分析工具并配置了所有初始設(shè)置。除此以外，如果剛開始沒有確定項(xiàng)目需要采取的策略，入門會(huì)比較困難。小編所說的“入門”是指深入理解將靜態(tài)分析集成到現(xiàn)有項(xiàng)目中的一般方法，以及如何提高靜態(tài)分析隨著時(shí)間的推移帶來的投資回報(bào)。

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

簡單來說，靜態(tài)分析是在不執(zhí)行代碼的情況下檢查源代碼和二進(jìn)制代碼的過程，通常用于查找bug的前期準(zhǔn)備或評(píng)估代碼質(zhì)量。與需要運(yùn)行程序的動(dòng)態(tài)分析（例如Parasoft Insure ++）不同，靜態(tài)分析可以直接分析源代碼而不需要執(zhí)行源代碼。

這意味著靜態(tài)分析可用于部分完整的代碼，庫和第三方源代碼。開發(fā)人員可以將靜態(tài)分析應(yīng)用在編寫或修改代碼的過程中，甚至可以應(yīng)用到任何代碼庫。

支持功能安全和編碼標(biāo)準(zhǔn)

在應(yīng)用程序安全域中，靜態(tài)代碼分析采用了靜態(tài)應(yīng)用程序安全性測(cè)試（SAST）技術(shù)。靜態(tài)分析可以支持安全漏洞檢測(cè)，同時(shí)支持bug檢測(cè)，質(zhì)量指標(biāo)和編碼標(biāo)準(zhǔn)一致性檢測(cè)。

另外，靜態(tài)分析工具強(qiáng)制要求（在某些情況下“強(qiáng)烈推薦”）能夠支持安全標(biāo)準(zhǔn)（如ISO 26262或EN 50128）的檢測(cè)，因?yàn)檫@些標(biāo)準(zhǔn)能夠檢測(cè)難以發(fā)現(xiàn)的缺陷并提高軟件的安全性。當(dāng)然，這又回歸到安全性的問題上，因?yàn)殪o態(tài)分析工具還可以幫助軟件團(tuán)隊(duì)遵守主要用于驗(yàn)證安全編碼的編碼標(biāo)準(zhǔn)，例如CERT甚至MISRA。

靜態(tài)分析工具優(yōu)點(diǎn)及難點(diǎn)

靜態(tài)分析工具的一個(gè)優(yōu)點(diǎn)是它們可以在項(xiàng)目的任何階段引入和使用，即使項(xiàng)目是不完整的或者只有部分編碼是有效的。引入靜態(tài)分析的最大難點(diǎn)在于代碼量大會(huì)產(chǎn)生大量的警告。因此，將靜態(tài)分析應(yīng)用到項(xiàng)目中時(shí)的重點(diǎn)應(yīng)該是使團(tuán)隊(duì)能夠盡快高效工作，并最大限度地減少團(tuán)隊(duì)被靜態(tài)分析的警告困擾的情況。這并不是說這些警告不重要，但大多數(shù)開發(fā)人員都不會(huì)修復(fù)現(xiàn)有或遺留代碼缺陷，至少不是立即處理。

最重要的應(yīng)該是將靜態(tài)分析運(yùn)用到日常流程中，以便最大化靜態(tài)分析的使用效果和可用性，然后處理最危險(xiǎn)的bug和安全漏洞。一旦團(tuán)隊(duì)變得更加熟練，你就可以專注于優(yōu)化工具和流程，提高投資回報(bào)率。

如何管理早期靜態(tài)分析報(bào)告

一旦將靜態(tài)分析工具安裝到項(xiàng)目中，該工具通常會(huì)報(bào)告相當(dāng)長的違規(guī)和警告報(bào)告。這可能是多到無法處理的，特別是在大型代碼庫中，因此如何管理這些報(bào)告將會(huì)直接影響到工具集成到項(xiàng)目中能否成功。

并非所有警告都是至關(guān)重要的，因此不需要立即處理所有警告。學(xué)習(xí)哪些需要立即解決而哪些需要推遲處理是成功的關(guān)鍵。如上所述，產(chǎn)品的成熟度和規(guī)模對(duì)方法有直接影響，下面將更詳細(xì)地概述。

底線方法

顧名思義，在這種方法中，開發(fā)人員決定在初步分析之后，他們不會(huì)讓任何更嚴(yán)重的警告和違規(guī)進(jìn)入代碼庫。換句話說，他們需要分析每個(gè)警告來確定其準(zhǔn)確性，并及時(shí)修復(fù)，如果它確實(shí)是一個(gè)bug。

團(tuán)隊(duì)還可以決定在現(xiàn)有代碼中添加已發(fā)現(xiàn)的關(guān)鍵警告，并將其添加到報(bào)告工具中的bug列表中。這些類型的警告可能是嚴(yán)重的安全漏洞，如SQL注入，或嚴(yán)重的內(nèi)存錯(cuò)誤，如緩沖區(qū)溢出。在大多數(shù)情況下，可以推遲不太嚴(yán)重的警告以供以后分析。你可能會(huì)想，“這不僅僅會(huì)增加我們的技術(shù)債務(wù)嗎？”如果你這樣想，那你就是對(duì)的！但在這個(gè)階段，我們對(duì)此表示滿意。這些警告中的任何潛在錯(cuò)誤都已經(jīng)在技術(shù)債務(wù)堆中。至少現(xiàn)在，它們被識(shí)別出來并且以后更容易修復(fù)。

確認(rèn)并推遲處理方法

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

在這種情況下，查看最重要的報(bào)告并確定行動(dòng)方案是有意義的。其余的警告只需要確認(rèn)，因?yàn)檐浖F(tuán)隊(duì)認(rèn)識(shí)到它們存在，但它們大多數(shù)都被推遲了。（這再次增加了該組織的技術(shù)債務(wù)，但如上所述，這些漏洞在技術(shù)上已經(jīng)存在作為技術(shù)債務(wù)。）這種方法不同于底線方法的地方在于確定關(guān)鍵警告后，你會(huì)推遲其余的警告，而不需要所有的都分析。

綠地方法

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

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

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

配置與過濾

開源或輕量級(jí)靜態(tài)分析工具與商業(yè)高級(jí)靜態(tài)分析工具之間的主要區(qū)別之一在于能否配置為分析啟用哪組檢查器，并根據(jù)警告類別，文件名，嚴(yán)重性等過濾掉報(bào)告的結(jié)果屬性。這有助于突出目標(biāo)——開發(fā)人員可以專注于他們感興趣的警告類型，并減少在任何時(shí)間產(chǎn)生的垃圾信息量。

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

我建議使用配置將規(guī)則集限制為可預(yù)見對(duì)軟件團(tuán)隊(duì)有用的規(guī)則。同樣，以最終目標(biāo)為出發(fā)點(diǎn)：如果提高安全性是關(guān)鍵目標(biāo)，那么啟用所有與安全相關(guān)的規(guī)則，禁用不太重要的規(guī)則，啟用CERT C等內(nèi)置安全編碼標(biāo)準(zhǔn)。如果你正在使用Parasoft C/C++test等高級(jí)靜態(tài)分析解決方案，你可以利用其內(nèi)置的管理工具來處理靜態(tài)分析報(bào)告中生成的數(shù)據(jù)，并推進(jìn)未來的重點(diǎn)開發(fā)工作。

總結(jié)

靜態(tài)分析工具使團(tuán)隊(duì)無需執(zhí)行代碼，就能夠檢測(cè)和跟蹤錯(cuò)誤安全漏洞。這些工具可應(yīng)用于現(xiàn)有、傳統(tǒng)和第三方代碼并提供質(zhì)量審查結(jié)果。

采用何種靜態(tài)分析方法在一定程度上取決于項(xiàng)目的成熟度。大量代碼確實(shí)會(huì)產(chǎn)生大量警告。但這完全是可管理的，能否成功取決于團(tuán)隊(duì)如何決定處理結(jié)果。好好考慮為項(xiàng)目的每個(gè)成熟度階段引入不同的技術(shù)，以及如何將這些工具集成到開發(fā)人員，團(tuán)隊(duì)負(fù)責(zé)人和經(jīng)理的日常工作流程中。

審核編輯 ：李倩