利用醫(yī)療設(shè)備軟件的靜態(tài)代碼分析

醫(yī)療設(shè)備使用的軟件代碼比以往任何時候都多。然而，雖然軟件為醫(yī)療設(shè)備提供了更多的功能和靈活性，但它也帶來了額外的復(fù)雜性，從而增加了故障風(fēng)險。今天大約 20% 的醫(yī)療設(shè)備召回是由軟件缺陷引起的，而且這個數(shù)字還在上升。

聯(lián)邦藥物管理局 （FDA） 監(jiān)督在美國銷售的醫(yī)療器械的質(zhì)量，希望發(fā)布醫(yī)療器械的公司必須獲得 FDA 510（k） 許可。在調(diào)查上市后失敗的同時，F(xiàn)DA 更加注重預(yù)防，并建議將靜態(tài)代碼分析作為方法的一部分。

復(fù)雜缺陷檢測的價值

現(xiàn)代靜態(tài)代碼分析工具使用復(fù)雜的技術(shù)來分析源代碼以檢測潛在的軟件缺陷。工具嘗試分析代碼中的所有邏輯路徑，提供比傳統(tǒng)測試形式更多的路徑和代碼覆蓋率。靜態(tài)分析工具不需要任何測試用例，甚至可以對代碼片段進行操作，發(fā)現(xiàn)潛在的程序崩潰、緩沖區(qū)溢出、內(nèi)存泄漏、數(shù)據(jù)損壞等。靜態(tài)分析通常運行迅速，并且可以在相對較短的時間內(nèi)報告一系列潛在的錯誤（參見圖 1）。

圖 1：靜態(tài)分析可以在軟件開發(fā)生命周期的早期發(fā)現(xiàn)潛在問題。

由于各種原因，靜態(tài)分析工具確實會產(chǎn)生一些錯誤的結(jié)果，通常稱為誤報和誤報。當(dāng)靜態(tài)分析工具認(rèn)為有錯誤而沒有錯誤時，就會發(fā)生誤報。誤報是應(yīng)該報告錯誤但沒有報告。

大多數(shù)現(xiàn)代靜態(tài)分析工具必須在可接受的精度水平和可接受的運行時間之間找到盡可能多的好結(jié)果之間進行微妙的權(quán)衡。換句話說，在大量誤報中發(fā)現(xiàn)每個問題的嘈雜工具的價值可能有限，就像只發(fā)現(xiàn)一小部分問題的高度準(zhǔn)確的工具一樣（參見圖 2）。

圖 2：靜態(tài)分析工具不會發(fā)現(xiàn)所有錯誤（誤報），并且會報告一些并非真正的錯誤（誤報）。使遺漏的錯誤和錯誤報告最小化的是良好的分析算法和適當(dāng)?shù)姆治稣{(diào)整。

現(xiàn)代靜態(tài)分析工具已經(jīng)改進了分析技術(shù)，可以以足夠的準(zhǔn)確度生成有用的結(jié)果。大多數(shù)組織認(rèn)識到靜態(tài)分析工具雖然不完善，但在大多數(shù)軟件開發(fā)過程中都提供了重要的價值。

充分利用靜態(tài)分析工具

現(xiàn)代靜態(tài)分析工具對大多數(shù)醫(yī)療設(shè)備制造商來說都是相對較新的。對于許多首次在其流程中實施靜態(tài)分析的組織而言，了解最佳實踐有助于在最短的時間內(nèi)以最少的返工量充分利用工具。

調(diào)音

靜態(tài)分析工具提供了適用于所有類型代碼庫的通用設(shè)置，雖然它們可以立即發(fā)現(xiàn)好的錯誤，但只需針對代碼調(diào)整工具就可以大大改善結(jié)果（參見圖 3）。這有助于找到更多相關(guān)的錯誤并減少通過誤報進行的搜索，這會浪費時間并導(dǎo)致開發(fā)人員疲勞。

圖 3：幾乎每個靜態(tài)分析部署都應(yīng)該從一個可靠的調(diào)優(yōu)項目開始。調(diào)整會帶來更多更好的錯誤和更少的誤報。

許多靜態(tài)分析工具都有自己的源代碼解析器，它們可能無法理解或無法訪問所有代碼。將系統(tǒng)配置為分析所有代碼或調(diào)整系統(tǒng)以識別分析時無法訪問的接口——例如單獨驗證的第三方庫——確保結(jié)果是最佳和可重復(fù)的。實現(xiàn) 100% 的代碼覆蓋率對于堵住可能增加風(fēng)險的漏洞非常重要。

調(diào)優(yōu)有助于發(fā)現(xiàn)真正的問題。例如，告訴靜態(tài)分析工具內(nèi)存分配機制是如何工作的，或者程序何時退出，這樣工具就不會繼續(xù)沿著特定路徑跟蹤問題，這有助于發(fā)現(xiàn)新問題并剔除錯誤問題。這可能是一個繁瑣的過程，需要特定的專業(yè)知識，但從長遠(yuǎn)來看會有所回報。

調(diào)優(yōu)通常是一個持續(xù)的過程，應(yīng)定期審查，以確保一致地使用配置并跟上代碼和環(huán)境的變化。如果不進行持續(xù)調(diào)整，開發(fā)人員可能會錯過一些重要的錯誤，并且團隊將浪費時間檢查誤報。

配置檢查器

許多靜態(tài)分析工具附帶數(shù)百個檢查，涵蓋從并發(fā)性到安全性到 C 和 C++ 陷阱的一系列問題。許多人不一定適用于給定的應(yīng)用程序。例如，為什么在分析 C 代碼時打開 C++ 特定檢查？確定正確的檢查器集需要一些試驗和錯誤以及專業(yè)知識，以了解什么是最劃算的。需要考慮的一些領(lǐng)域是：哪些類型的檢查器會導(dǎo)致真正的問題，哪些檢查器容易產(chǎn)生噪音，哪些檢查器可以配置為有用。一旦一個好的集合最終確定，將其鎖定，以便記錄并始終如一地運行。

在一個說明檢查器價值的真實示例中，客戶希望確保他們的靜態(tài)分析系統(tǒng)始終如一地運行，并要求在系統(tǒng)出現(xiàn)差異時立即收到警報。開發(fā)人員創(chuàng)建了一個測試套件，其中包含每個檢查器的測試用例。每當(dāng)他們更改系統(tǒng)時，他們都會運行測試套件以確保每個檢查器確實按預(yù)期運行。如果結(jié)果失敗，他們知道他們有需要解決的配置問題。如果測試通過，開發(fā)人員會將結(jié)果放入他們的設(shè)計歷史文件中，以證明系統(tǒng)按照他們記錄的方式工作。該測試套件不僅為客戶提供了責(zé)任和保證，而且還降低了他們的維護和管理成本。

過程

一旦實現(xiàn)了全面覆蓋、調(diào)整了系統(tǒng)并定義了分析的廣度，開發(fā)人員就可以開始更有效地使用靜態(tài)分析。對于醫(yī)療設(shè)備，一個典型的目標(biāo)是檢查報告的每一個問題。每個問題都可以通過多種不同的方式進行分類：

一個必須解決的問題。它將有一個適當(dāng)?shù)膬?yōu)先級來描述它的重要性以及在軟件開發(fā)過程中必須如何解決它。

正確標(biāo)記的問題，但不太可能表現(xiàn)為現(xiàn)實世界的錯誤，通常是因為該工具做出了不正確的環(huán)境假設(shè)。這些類型的分類標(biāo)志著潛在的調(diào)整機會。

被錯誤地標(biāo)記為錯誤的問題，無論是誤報還是分析工具中的徹底錯誤。這些問題也預(yù)示著調(diào)整機會。

這些案例中的每一個都必須仔細(xì)審查。尤其應(yīng)檢查誤報的正確性。每個問題都需要自由文檔，并且需要一個強大的數(shù)據(jù)保留政策來實現(xiàn)全面問責(zé)。如果在流程后期發(fā)現(xiàn)重大錯誤，這些分類缺陷報告可能會在審計過程中或在回顧中重新審查。組織通常會回到靜態(tài)分析缺陷以查看主要錯誤是如何通過該過程的。它可能標(biāo)志著一個中斷的過程或一個調(diào)整分析以找到更好的錯誤的機會。

使用模式

靜態(tài)分析通常在開發(fā)人員沙箱構(gòu)建中和/或通過中央構(gòu)建運行（參見圖 4）。至少，在發(fā)布之前分析和評估結(jié)果是有意義的。但是，軟件開發(fā)組織不應(yīng)該等到最后一刻才解決可能存在的大量錯誤，特別是當(dāng)這些錯誤本可以作為規(guī)范流程的一部分更早地解決時。否則，團隊可能會錯過最后期限并在最壞的時間更改代碼。

圖 4：靜態(tài)分析可以根據(jù)業(yè)務(wù)需求、環(huán)境和使用的工具以多種不同方式部署。

組織通常將靜態(tài)分析自動化作為夜間構(gòu)建或持續(xù)集成構(gòu)建的一部分。通過這種方式，可以經(jīng)常審查結(jié)果并在結(jié)果出現(xiàn)時加以處理。其他人則通過使開發(fā)人員能夠在沙盒環(huán)境中分析他們正在處理的代碼來更早地執(zhí)行錯誤發(fā)現(xiàn)過程。開發(fā)人員可以立即獲得有關(guān)其代碼更改質(zhì)量的反饋，然后在簽入前修復(fù)和驗證缺陷。循環(huán)時間越快，代碼庫中的代碼就越干凈。

無論在哪里運行，技術(shù)環(huán)境都需要保持一致，以確保結(jié)果相同。中央和開發(fā)人員構(gòu)建需要保持一致。對分析設(shè)置的輕微更改可能會導(dǎo)致報告更多結(jié)果，并且組織不需要審查更多可能主要是誤報的問題的額外負(fù)擔(dān)。為開發(fā)人員創(chuàng)建一個高度自動化的系統(tǒng)將有助于確保一致性。

許多醫(yī)療設(shè)備公司不僅將源代碼檢查到其存儲庫中，還檢查其實際環(huán)境。這樣，可追溯性是可用的。靜態(tài)分析可執(zhí)行文件和所有相關(guān)配置、狀態(tài)和其他相關(guān)項目也應(yīng)定期檢查，以確保一致性和問責(zé)制。

處理積壓

大多數(shù)組織在開發(fā)大量代碼后開始使用靜態(tài)分析。通常，代碼越多，報告的錯誤就越多。因此，在推出靜態(tài)分析時，管理層必須預(yù)先分配時間來處理最初積壓的錯誤。

最好在開發(fā)周期中盡早進行靜態(tài)分析，以盡量減少積壓，然后創(chuàng)建一個流程來處理積壓，與由于日常代碼更改導(dǎo)致的日常流入錯誤流分開處理。審查缺陷需要時間，應(yīng)該在開發(fā)人員之間適當(dāng)分配，或者外包給一個單獨的團隊來挑選需要工作的缺陷。

文化

所有開發(fā)團隊在技術(shù)技能水平以及團隊中每個人如何定義質(zhì)量方面都存在差異。在培訓(xùn)和指導(dǎo)課程中，最常見的論點是：

“是的，這絕對是一個錯誤，但代碼一直在工作，所以我們不想更改它?！?/p>

“我們不應(yīng)該讓這樣的代碼出現(xiàn)在我們的產(chǎn)品中?！?/p>

“這種情況在現(xiàn)實生活中永遠(yuǎn)不會發(fā)生?！?/p>

“如果我們將來將產(chǎn)品移植到另一個平臺，這將成為一個錯誤?！?/p>

“如果你在這上面多花幾分鐘，你就會發(fā)現(xiàn)這顯然是一個錯誤?！?/p>

靜態(tài)分析將提供各種類型的錯誤，從必須解決的關(guān)鍵問題到警告。一些組織希望投機取巧，只為可證明的錯誤更改代碼。其他人則主動清理代碼并提高質(zhì)量，甚至“修復(fù)”警告。團隊?wèi)?yīng)該在處理靜態(tài)分析結(jié)果的方式上保持一致。審查結(jié)果、培訓(xùn)/指導(dǎo)和頻繁的溝通是成功的關(guān)鍵。

如果使用得當(dāng)，靜態(tài)分析已被證明在提高安全關(guān)鍵代碼的軟件質(zhì)量方面非常有效。盡管不嚴(yán)格要求批準(zhǔn)，但 FDA 承認(rèn)其有效性。通過適當(dāng)?shù)囊?guī)劃、專業(yè)知識和現(xiàn)實的投資，靜態(tài)分析應(yīng)該會產(chǎn)生可觀的投資回報，并有助于向市場提供安全的代碼。

審核編輯：郭婷