前言

　　《Better Embedded System Software》一書的作者在其博客上發(fā)布了可致命汽車軟件缺陷列表，該列表主要來源于NHTSA（美國高速公路安全管理局）官網(wǎng)上的召回通告。作者在博客中表示,，整理出列表的目的不是要針對任何特定的公司或軟件缺陷，現(xiàn)實是關(guān)鍵的安全性軟件缺陷在整個汽車行業(yè)中都是普遍且持久存在的,。

　　本文將首先從清單中挑選出一些典型例子，然后討論SAST能對這些狀況提供的幫助。

　　汽車軟件故障示例

　　原博客中列出的那些問題能被作為車輛召回的原因，也表明了那些問題確實是足夠嚴重的安全隱患,，以下是部分召回信息：

　　1、由于診斷檢查問題,，ABS 和 DSC 被禁用（捷豹）/ 2021 年 3 月

2,、無線電軟件安全漏洞（克萊斯勒）/ 2015

3,、ESC故障（梅賽德斯）/ 2021 年 2 月

4,、制動性能降低（現(xiàn)代）/ 2020 年 12 月

　　5,、由于偏航傳感器軟件的缺陷，特別是診斷程序缺陷,，導(dǎo)致錯誤干預(yù)電子穩(wěn)定程序（ESP）,。在這種情況下，傳感器漂移會增加撞車的風險,。

　　6,、由于軟件代碼缺失以及與新引入的硬件不兼容，自動緊急制動可能無法啟動,。

　　以上只是一些有代表性的問題,，還有非常多類似的召回案例，其中涉及到的軟件和硬件缺陷,，可能影響車輛穩(wěn)定性,、制動和發(fā)動機控制等關(guān)鍵方面。

　　SAST在安全關(guān)鍵軟件開發(fā)中的作用

　　汽車軟件的安全保障顯然是一個系統(tǒng)性問題,，需要企業(yè)文化,、管理流程和研發(fā)技術(shù)變革共同推進。行業(yè)自認證也存在問題,，ISO 26262等標準并沒有被普遍采用,，由于這個主題太大，以下將僅關(guān)注可以通過SAST （static application security testing,，靜態(tài)應(yīng)用程序安全測試） 和SCA （軟件組成分析） 改進的流程和過程,。

　　SAST的強大之處在于不依賴于測試用例來發(fā)現(xiàn)問題，也不需要重現(xiàn)錯誤或失敗,。類似GrammaTech CodeSonar這樣的SAST工具可以在不實際運行程序的情況下推斷出程序的運行時行為,。此外，當它識別出一個問題時,，還能在代碼中定位到導(dǎo)致失敗的位置,。這使得調(diào)試工作變得簡單。

　　靜態(tài)分析并不能完全替代測試,，而是對測試的有效補充?，F(xiàn)實情況是，在大型的復(fù)雜軟件系統(tǒng)中,，可能的狀態(tài)非常之多,，可能的執(zhí)行路徑數(shù)量更是驚人，所以對它們進行詳盡的測試是不現(xiàn)實的,。靜態(tài)代碼分析可以從總體上探索這些路徑和狀態(tài),，以發(fā)現(xiàn)測試中遺漏的問題。

　　通過編碼標準進行預(yù)防：編碼標準是安全關(guān)鍵軟件開發(fā)的重要組成部分,，因為它們定義了一組更安全的編程語言子集,。汽車軟件中最常用的標準是 MISRA C 和 MISRA C++（還有相關(guān)的AUTOSARC++標準）,。執(zhí)行更嚴格的安全編碼標準，可以提前消除許多軟件缺陷,，重點是避免使用已知的危險語法和每種語言中潛在未定義行為的部分,。

　　代碼覆蓋率不代表一切：許多安全標準需要高水平的代碼覆蓋率（以證明測試執(zhí)行了大部分語句和條件）。雖然這是非常詳盡的,，但做起來成本很高,，而且必須在開發(fā)的每個主要階段重復(fù)進行（單元、集成和系統(tǒng)測試）,。其實軟件的關(guān)鍵性決定了覆蓋率的水平,，一些不太關(guān)鍵的軟件不需要正式的測試覆蓋率。雖然測試代碼覆蓋率是評估軟件質(zhì)量的一個指標,，但在有些情況下,，它并不是絕對的。

　　被基于覆蓋率測試所遺漏的漏洞和錯誤：基于覆蓋率指標的軟件測試本質(zhì)上是基于單元的測試（盡管覆蓋率也會在系統(tǒng)層面進行評估）,。而并發(fā)性錯誤和安全漏洞是兩個在嚴格測試中也可能被遺漏的隱患,。并發(fā)產(chǎn)生的錯誤（如競爭條件）只有在運行過程中出現(xiàn)一些不可預(yù)見的情況時才會被發(fā)現(xiàn)。安全漏洞是存在于代碼中的錯誤 – 造成錯誤的原因通常是由于在測試期間沒有考慮輸入的類型,。SAST可以及早發(fā)現(xiàn)這些錯誤,，并防止它們在開發(fā)周期的后期成為絆腳石。

　　及早發(fā)現(xiàn)缺陷：嚴格的測試可以發(fā)現(xiàn)軟件中的大多數(shù)缺陷,，但成本高昂且極其耗時,。在編寫代碼時就發(fā)現(xiàn)和修復(fù)這些錯誤比在開發(fā)周期后期便宜得多（隨著時間的推移，發(fā)現(xiàn)缺陷的成本呈指數(shù)級增長）,。靜態(tài)分析可以在代碼編寫時檢測錯誤——如果能作為開發(fā)人員開發(fā)環(huán)境的一部分,，這將大大降低缺陷出現(xiàn)在下游時的成本。

　　分析開源和第三方代碼：在嵌入式軟件開發(fā)中,，使用第三方代碼和開源軟件是一個常見現(xiàn)象,。一些安全標準認為，任何沒有按照特定標準開發(fā)的軟件都是血統(tǒng)不明的軟件（SOUP）--是需要仔細檢查后才能納入系統(tǒng)的,。針對這類情況,，軟件組成分析工具SCA可以提供幫助，如GrammaTech CodeSentry,，可以分析第三方二進制文件以發(fā)現(xiàn)缺陷和安全漏洞,，并生成軟件材料清單（SBOM）。

　　總結(jié)

　　NHTSA對存在軟件相關(guān)缺陷車輛的召回正在增加,，這表明汽車軟件開發(fā)需要加快改進步伐,。然而，為汽車系統(tǒng)開發(fā)嵌入式軟件，需要遵守嚴格的方法和承諾,，以增加安全和保障,，改進需要自上而下地進行文化和流程的改變。與此同時,，還需要自下而上的改變，采用最佳實踐,，包括流程和編碼標準以及其他經(jīng)過驗證的方法來提高代碼質(zhì)量,。

　　引入高級靜態(tài)分析工具將有助于自動執(zhí)行編碼標準，更重要的是它們能在查找被其他驗證測試活動遺漏的缺陷方面發(fā)揮重要作用,，并且有助于開發(fā)人員理解和糾正代碼問題,。對軟件成分分析以及審查開源和第三方軟件的已知漏洞，并創(chuàng)建軟件物料清單 （SBOM） 會對降低軟件供應(yīng)鏈風險起到關(guān)鍵作用,。