前言

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

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

　　汽車軟件故障示例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　及早發(fā)現(xiàn)缺陷：嚴(yá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)象,。一些安全標(biāo)準(zhǔn)認(rèn)為，任何沒有按照特定標(biāo)準(zhǔn)開發(fā)的軟件都是血統(tǒng)不明的軟件（SOUP）--是需要仔細(xì)檢查后才能納入系統(tǒng)的,。針對這類情況,，軟件組成分析工具SCA可以提供幫助,，如GrammaTech CodeSentry，可以分析第三方二進(jìn)制文件以發(fā)現(xiàn)缺陷和安全漏洞,，并生成軟件材料清單（SBOM）,。

　　總結(jié)

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

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