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

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

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

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

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

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

只有可以跟蹤和驗證要求才有意義，而實施這些要求依賴于遵守必須不斷檢查和驗證的實踐和標準。可以將安全編碼實踐和標準與策略（整體方法）和策略（詳細執行）進行比較。不遵守其中任何一個都可能導致危害安全的錯誤。幸運的是，可以使用適當的自動化測試工具和方法來檢測這些錯誤。

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

采用安全編碼標準

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

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

結構性覆蓋提供信心

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

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

【圖2 | 使用動態分析的結構覆蓋揭示了尚未采用的功能和路徑。］

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

一套集成的、協調的和可配置的工具對于處理這些項目的規模和復雜性是必不可少的。這些工具自動跟蹤、分析和測試，并維護重要、復雜系統的證明和資格或認證所需的數據。它們為安全、可靠的軟件開發生命周期提供了基礎，并為所有團隊成員提供了一種溝通和協調工作的機制。

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

審核編輯：郭婷