汽車嵌入式應用程序傳統上是隔離的、靜態的、固定功能的、特定于設備的實現，實踐和流程依賴于這種狀態。將汽車連接到外部世界會極大地改變事情，因為它使遠程訪問成為可能，同時無需對汽車系統進行物理修改?，F在，汽車開發商有明確的義務確保不安全的應用軟件不會損害安全性，不僅在整個生產生命周期內，而且只要產品在現場使用。

盡管著名的 ISO 26262:2012“道路車輛 — 功能安全”標準通過提供正式的軟件開發流程有所幫助，但它并未明確討論軟件安全性。也就是說，在安全漏洞可能威脅安全的地方，ISO 26262 確實要求安全目標和要求來處理它們。使用 ISO 26262 的汽車安全完整性等級 (ASIL) 風險分類方案，為處理每個威脅安全的安全問題而采取的行動需要與風險成正比。

盡管如此，為了確保安全性，嵌入式系統的開發人員必須考慮到應用程序代碼只是一個重要的組件，并且在開發該代碼時，可以部署安全關鍵代碼開發人員熟悉的許多技術，并具有更強的安全性。

然而，除了開發之外，連接性還為每個新發現的漏洞賦予系統維護新的意義，因為軟件需求和安全漏洞在開發之后以及只要產品在現場使用時就有可能發生變化。對于汽車，這可能長達 10 年或更長時間。

保護應用程序代碼安全的嵌入式系統不僅僅是確保應用程序代碼的安全。安全強化操作系統、虛擬機管理程序、分離內核和引導映像完整性驗證等技術都發揮著至關重要的作用。這些技術不僅提供了針對侵略者的多層次防御，而且還可以以相互支持的方式使用。

例如，當使用分離內核或管理程序以多域架構部署汽車系統時。域分離方法將高度關鍵的應用程序與系統中更普通的部分分開，為安全系統提供了有吸引力的基礎。但是該底層架構將存在優點和缺點。

風險分析的使用有助于系統地揭示弱點，這些弱點可能存在于以下領域：

不同域之間的接口

從網絡外部訪問文件的接口

向后兼容的接口

舊協議，有時是舊代碼和庫，以及難以維護和難以測試的多個版本

自定義應用程序編程接口 (API)

安全碼

加密、身份驗證和授權會話管理

采用這種專注的方法有助于確保即使在現有代碼部署的地方，如果解決高風險區域以支持安全架構，那么整個系統可以變得足夠安全，而無需訴諸于重寫每個組件部分的不切實際的極端.

安全可靠的應用程序代碼開發確保軟件開發安全的傳統方法往往是被動的：開發軟件，然后使用滲透、模糊測試和功能測試來暴露任何弱點。有用的是，孤立地遵守諸如 ISO 26262 之類的功能安全標準是不夠的。該標準隱含地要求從一開始就考慮具有安全含義的安全因素，因為安全關鍵系統不可能是安全的如果它不安全。

常見的 V 模型在這方面很有用。該模型交叉引用了 ISO 26262 標準和可能在當今高度復雜和復雜的汽車軟件開發的每個階段部署的工具（圖 1）。出于本文的目的，此模型有助于作為參考，了解引入安全視角如何影響每個階段。請注意，其他流程模型（例如敏捷和瀑布）同樣可以得到很好的支持。

圖 1：交叉引用 ISO 26262 和標準開發工具的軟件開發 V 模型。

系統設計階段的產品 （左上）包括細化并分配給硬件和軟件的技術安全要求。在連接的系統中，這些將包括許多安全要求，因為為處理每個威脅安全的安全問題而采取的行動需要與風險成比例。在這些需求和后續階段的產品之間保持可追溯性通常會導致項目管理頭痛。

軟件安全需求的規范 涉及它們從系統設計中的推導，隔離軟件特定的元素，并詳細說明較低級別的軟件相關需求的演變過程，包括那些具有安全相關元素的需求。

接下來是軟件架構設計 階段，可能使用 UML 圖形表示。靜態分析工具通過提供代碼組件之間關系的圖形表示來幫助與預期設計進行比較（圖 2）。

圖 2：靜態分析工具提供代碼組件之間關系的圖形表示，以便與預期設計進行比較——在本例中，是控制和數據流之間的關系。

顯示了來自 ISO 26262-6:2011 的與軟件單元設計和實施有關的表格的典型示例（圖 3）。它顯示了在實施過程中要強制執行的編碼和建模指南，并附有指示可以在自動化工具的幫助下確認合規性的地方。

圖 3：ISO 26262 編碼和建模指南。

“語言子集的使用”（表中的主題 1b）舉例說明了安全考慮對流程的影響。語言子集傳統上被視為對安全的幫助，但對 MISRA C:2012 標準和安全特定標準（如通用弱點枚舉 (CWE)）的安全增強反映了人們對它們在解決安全問題中必須發揮的作用越來越感興趣. 這些也可以通過靜態分析進行檢查（圖 4）。

圖 4：編碼標準違反 MISRA C:2012 標準和安全特定標準（如通用弱點枚舉 (CWE)）的安全增強可以通過靜態分析進行檢查。

動態分析技術（涉及部分或全部代碼的執行）適用于項目集成和測試。項目測試旨在孤立地關注特定的軟件過程或功能，而集成測試確保當單元根據軟件架構設計協同工作時滿足安全、保障和功能要求（圖 5）。

圖 5：項目測試界面顯示軟件界面如何在功能范圍內公開，允許用戶輸入輸入和預期輸出以形成測試工具的基礎。

在一個好的測試工具套件中，軟件接口在功能范圍內公開，允許用戶輸入輸入和預期輸出以形成測試工具的基礎。然后在目標硬件上編譯和執行該線束，并比較實際輸出和預期輸出。這種技術不僅可以根據功能、安全和安全要求顯示功能正確性，而且還可以顯示對邊界條件、空指針和默認切換情況等問題的彈性——所有重要的安全考慮因素。

除了顯示軟件功能正確之外，動態分析還用于生成結構覆蓋率度量。安全標準 CWE 要求使用代碼覆蓋分析來確保不存在旨在增加應用程序攻擊面和暴露弱點的隱藏功能。

管理無限的開發生命周期雙向可追溯性原則貫穿整個 ISO26262 V 模型，每個開發階段都需要準確反映之前的開發階段。理論上，如果遵循標準的確切順序，那么需求永遠不會改變，測試也永遠不會拋出問題。但生活不是這樣的。

例如，很容易想象這些過程與“綠地”項目相關。但是，如果需要集成許多不同的子系統怎么辦？如果其中一些是預先存在的，并且要求以不同的格式定義怎么辦？如果其中一些系統是在沒有考慮安全性的情況下編寫的，假設是一個孤立的系統怎么辦？如果不同的子系統處于不同的開發階段怎么辦？

然后是需求變化的問題。如果客戶改變主意了怎么辦？一個好主意？律師建議現有方法可能存在問題？

如果需要更改，則需要重新靜態分析修改后的代碼，并且需要重新運行所有受影響的單元和集成測試（回歸測試）。盡管這可能會導致當時的項目管理噩夢，但在一個孤立的應用程序中，它的持續時間比產品正在開發的時間長一點。

連通性改變了這一切。每當發現一個新的漏洞時，就會導致滿足它的需求變化，再加上額外的壓力，即如果產品在現場不受到損害，那么快速響應可能至關重要。

自動化的雙向可追溯性將來自許多不同來源的需求鏈接到設計、編碼和測試。任何需求更改的影響——或者實際上是失敗的測試用例的影響——都可以通過影響分析來評估并相應地解決。工件可以自動重新生成，以提供持續符合 ISO 26262 的證據（圖 6）。

在開發傳統的、孤立的系統時，這顯然是足夠有用的。但是連通性需要對漏洞做出響應的能力，因為每個新發現的漏洞都意味著一個變化的或新的需求，并且需要立即響應——即使開發工程師可能已經有很長一段時間沒有觸及系統本身了。在這種情況下，能夠隔離所需內容并僅自動測試已實現的功能變得更加重要。

圖 6：自動化的雙向可追溯性鏈接來自大量不同來源的需求，直至設計、編碼和測試。

結論嵌入式汽車系統依賴于安全強化操作系統、虛擬機管理程序、分離內核和引導映像完整性驗證等技術。這些技術不僅提供了針對侵略者的多層次防御，而且還可以以相互支持的方式使用，以提供與所涉及風險相稱的防御水平。

在這樣的開發過程中可以使用現有的工具和技術，有時會進行調整以適應安全編碼規則的情況，以補充那些強調安全的現有工具和技術。一些技術，例如覆蓋率分析，使用了一種完全相似的方法，但目的略有不同——在這種情況下，包括確保沒有任何額外的“后門”代碼。

需求、設計、代碼和測試之間的雙向可追溯性是 ISO 26262 的基本要求，其自動化可以大大節省項目管理開銷。當安全漏洞的影響可能在產品發布后很長時間內對項目產生新的要求時，這種自動化可追溯性的重要性就更加突出。在這種情況下，對需求變化的快速響應具有挽救生命和提高聲譽的潛力。

審核編輯 黃昊宇