一架波音 787 飛機包含大約 650 萬行軟件。令人印象深刻的是，直到您意識到現(xiàn)代汽車平均有 2000 萬行代碼，才能使客機超過三倍。雖然人類生命和安全取決于兩個系統(tǒng)中軟件的正常運行，但汽車行業(yè)在確保功能安全性方面落后于航空航天。

近年來，汽車行業(yè)采用了 ISO 26262 等功能安全標準，但并未同樣重視安全性。根據(jù)BI Intelligence的數(shù)據(jù)，現(xiàn)在該行業(yè)正在迎頭趕上，預計聯(lián)網(wǎng)汽車的數(shù)量將從 2015 年的 3600 萬輛增長到 2020 年的 3.81 億輛，測試繼續(xù)顯示聯(lián)網(wǎng)汽車的安全漏洞。

從客戶（駕駛員）的角度來看，確保安全和安全的責任落在了汽車制造商身上。反過來，這些 OEM 依賴于一級和二級供應商提供一系列電子控制單元 （ECU）、車聯(lián)網(wǎng) （V2X） 通信、高級駕駛輔助系統(tǒng) （ADAS） 和信息娛樂系統(tǒng)?，F(xiàn)在，這些系統(tǒng)中的每一個都連接到一個通用的車輛網(wǎng)絡（圖 1），每個系統(tǒng)都有助于不斷擴大的攻擊面。分離內(nèi)核和管理程序等安全方法可以通過提供運行時分離和隔離在一定程度上緩解該問題，但它們不能提供安全保證——僅僅是一道防線。

最佳實踐表明，安全性（如功能安全性）不能是事后才想到的。它必須是整個軟件開發(fā)生命周期的一部分。

需求是安全軟件開發(fā)生命周期的一部分

安全開發(fā)生命周期始于 OEM 向一級和二級供應商提出的特定安全要求。然后必須將這些要求應用于開發(fā)過程和生產(chǎn)的軟件。必須向 OEM 驗證和證明過程和生成的軟件方面的結(jié)果，以便 OEM 可以驗證整個車輛及其系統(tǒng)是安全的。

只有可以跟蹤和驗證要求才有意義，而實施這些要求依賴于遵守必須不斷檢查和驗證的實踐和標準?？梢詫踩幋a實踐和標準與策略（整體方法）和策略（詳細執(zhí)行）進行比較。不遵守其中任何一個都可能導致危害安全的錯誤。幸運的是，可以使用適當?shù)淖詣踊瘻y試工具和方法來檢測這些錯誤。

計算機應急準備小組 （ CERT ） 網(wǎng)站列出了 12 種安全編碼實踐，可被視為戰(zhàn)略編碼方法或安全要求。它們包括諸如“驗證輸入”和“注意編譯器警告”等建議，同時使用編譯器的最高警告級別。另一條建議是“保持簡單”，這可以通過圈復雜度等指標進行測試。這突出了比預期更復雜的函數(shù)，因此任何超出指定范圍的復雜度值都可以證明是合理的，目的是創(chuàng)建更清晰、更可維護和更可測試的代碼。12 項實踐中的另一個關(guān)鍵建議是采用安全編碼標準。

采用安全編碼標準

編碼標準規(guī)定了使用特定語言（例如 C 或 C++）編寫安全代碼的特定規(guī)則和指南（策略）。其中一個編碼標準是 CERT C，它有 98 條規(guī)則用于開發(fā)安全、可靠和可靠的系統(tǒng)。規(guī)則按部分分組，涵蓋字符串、內(nèi)存和表達式等內(nèi)容。MISRA C 和 MISRA C++ 是另外兩種在汽車行業(yè)廣泛使用的流行編碼標準。這些 MISRA 標準始終針對“關(guān)鍵”代碼，這意味著它們始終適用于安全和安保關(guān)鍵系統(tǒng)。MISRA C:2012 修正案 1 通過引入 14 條專門針對安全的新指南進一步強調(diào)了這一點。

編碼標準處理為安全系統(tǒng)正確使用高級語言的細節(jié)，限制編碼結(jié)構(gòu)以最大限度地減少潛在漏洞。使用標準的一個好處是可以使用靜態(tài)分析工具檢查源代碼是否符合所選標準，最好在整個開發(fā)過程中進行。

結(jié)構(gòu)性覆蓋提供信心

保護聯(lián)網(wǎng)汽車及其廣泛多樣的攻擊面是一項艱巨的任務。例如，可以通過信息娛樂系統(tǒng)、GPS、ODB2 診斷端口或軟件/固件更新過程進行訪問。一旦車載網(wǎng)絡被破壞，安全關(guān)鍵系統(tǒng)（如安全氣囊、制動、轉(zhuǎn)向、傳輸和防撞）中的漏洞可能會被暴露和利用。任何這些系統(tǒng)中的編碼錯誤都可能導致災難，因此開發(fā)人員必須測試安全性，然后衡量該測試的有效性。

在執(zhí)行和測試編譯的代碼時，結(jié)構(gòu)覆蓋分析通過識別和突出顯示哪些代碼已經(jīng)過測試和沒有經(jīng)過測試，有助于衡量測試過程的有效性。顏色編碼格式化的源代碼和流程圖可以很容易地確定還需要做什么（圖 2）。獲得的覆蓋范圍越多，就可以確信不存在包含漏洞的代碼。軟件組件的安全性或安全性越關(guān)鍵，應應用的覆蓋分析級別的要求就越高——從簡單的語句覆蓋到修改的條件/決策覆蓋 （MC/DC）。

【圖2 | 使用動態(tài)分析的結(jié)構(gòu)覆蓋揭示了尚未采用的功能和路徑。］

結(jié)構(gòu)覆蓋率可能來自整個運行系統(tǒng)的執(zhí)行，或在單元測試期間。單元測試利用提供可執(zhí)行機制的測試工具來調(diào)用具有指定輸入的功能或子系統(tǒng)，以便可以驗證輸出并跟蹤需求。這種組合導致對單個軟件組件和整個應用程序的功能的信心。

一套集成的、協(xié)調(diào)的和可配置的工具對于處理這些項目的規(guī)模和復雜性是必不可少的。這些工具自動跟蹤、分析和測試，并維護重要、復雜系統(tǒng)的證明和資格或認證所需的數(shù)據(jù)。它們?yōu)榘踩?、可靠的軟件開發(fā)生命周期提供了基礎(chǔ)，并為所有團隊成員提供了一種溝通和協(xié)調(diào)工作的機制。

此外，一旦汽車上路，只要暴露出新的漏洞或引入額外的安全要求，該工具套件就能做出有效且高效的響應。

審核編輯：郭婷