汽車安全需要無(wú)限的軟件開(kāi)發(fā)生命周期

汽車嵌入式應(yīng)用程序傳統(tǒng)上是隔離的、靜態(tài)的、固定功能的、特定于設(shè)備的實(shí)現(xiàn)，實(shí)踐和流程依賴于這種狀態(tài)。將汽車連接到外部世界會(huì)極大地改變事情，因?yàn)樗惯h(yuǎn)程訪問(wèn)成為可能，同時(shí)無(wú)需對(duì)汽車系統(tǒng)進(jìn)行物理修改?，F(xiàn)在，汽車開(kāi)發(fā)商有明確的義務(wù)確保不安全的應(yīng)用軟件不會(huì)損害安全性，不僅在整個(gè)生產(chǎn)生命周期內(nèi)，而且只要產(chǎn)品在現(xiàn)場(chǎng)使用。

盡管著名的 ISO 26262:2012“道路車輛 — 功能安全”標(biāo)準(zhǔn)通過(guò)提供正式的軟件開(kāi)發(fā)流程有所幫助，但它并未明確討論軟件安全性。也就是說(shuō)，在安全漏洞可能威脅安全的地方，ISO 26262 確實(shí)要求安全目標(biāo)和要求來(lái)處理它們。使用 ISO 26262 的汽車安全完整性等級(jí) (ASIL) 風(fēng)險(xiǎn)分類方案，為處理每個(gè)威脅安全的安全問(wèn)題而采取的行動(dòng)需要與風(fēng)險(xiǎn)成正比。

盡管如此，為了確保安全性，嵌入式系統(tǒng)的開(kāi)發(fā)人員必須考慮到應(yīng)用程序代碼只是一個(gè)重要的組件，并且在開(kāi)發(fā)該代碼時(shí)，可以部署安全關(guān)鍵代碼開(kāi)發(fā)人員熟悉的許多技術(shù)，并具有更強(qiáng)的安全性。

然而，除了開(kāi)發(fā)之外，連接性還為每個(gè)新發(fā)現(xiàn)的漏洞賦予系統(tǒng)維護(hù)新的意義，因?yàn)檐浖枨蠛桶踩┒丛陂_(kāi)發(fā)之后以及只要產(chǎn)品在現(xiàn)場(chǎng)使用時(shí)就有可能發(fā)生變化。對(duì)于汽車，這可能長(zhǎng)達(dá) 10 年或更長(zhǎng)時(shí)間。

保護(hù)應(yīng)用程序代碼安全的嵌入式系統(tǒng)不僅僅是確保應(yīng)用程序代碼的安全。安全強(qiáng)化操作系統(tǒng)、虛擬機(jī)管理程序、分離內(nèi)核和引導(dǎo)映像完整性驗(yàn)證等技術(shù)都發(fā)揮著至關(guān)重要的作用。這些技術(shù)不僅提供了針對(duì)侵略者的多層次防御，而且還可以以相互支持的方式使用。

例如，當(dāng)使用分離內(nèi)核或管理程序以多域架構(gòu)部署汽車系統(tǒng)時(shí)。域分離方法將高度關(guān)鍵的應(yīng)用程序與系統(tǒng)中更普通的部分分開(kāi)，為安全系統(tǒng)提供了有吸引力的基礎(chǔ)。但是該底層架構(gòu)將存在優(yōu)點(diǎn)和缺點(diǎn)。

風(fēng)險(xiǎn)分析的使用有助于系統(tǒng)地揭示弱點(diǎn)，這些弱點(diǎn)可能存在于以下領(lǐng)域：

不同域之間的接口

從網(wǎng)絡(luò)外部訪問(wèn)文件的接口

向后兼容的接口

舊協(xié)議，有時(shí)是舊代碼和庫(kù)，以及難以維護(hù)和難以測(cè)試的多個(gè)版本

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

安全碼

加密、身份驗(yàn)證和授權(quán)會(huì)話管理

采用這種專注的方法有助于確保即使在現(xiàn)有代碼部署的地方，如果解決高風(fēng)險(xiǎn)區(qū)域以支持安全架構(gòu)，那么整個(gè)系統(tǒng)可以變得足夠安全，而無(wú)需訴諸于重寫(xiě)每個(gè)組件部分的不切實(shí)際的極端.

安全可靠的應(yīng)用程序代碼開(kāi)發(fā)確保軟件開(kāi)發(fā)安全的傳統(tǒng)方法往往是被動(dòng)的：開(kāi)發(fā)軟件，然后使用滲透、模糊測(cè)試和功能測(cè)試來(lái)暴露任何弱點(diǎn)。有用的是，孤立地遵守諸如 ISO 26262 之類的功能安全標(biāo)準(zhǔn)是不夠的。該標(biāo)準(zhǔn)隱含地要求從一開(kāi)始就考慮具有安全含義的安全因素，因?yàn)榘踩P(guān)鍵系統(tǒng)不可能是安全的如果它不安全。

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

圖 1：交叉引用 ISO 26262 和標(biāo)準(zhǔn)開(kāi)發(fā)工具的軟件開(kāi)發(fā) V 模型。

系統(tǒng)設(shè)計(jì)階段的產(chǎn)品 （左上）包括細(xì)化并分配給硬件和軟件的技術(shù)安全要求。在連接的系統(tǒng)中，這些將包括許多安全要求，因?yàn)闉樘幚砻總€(gè)威脅安全的安全問(wèn)題而采取的行動(dòng)需要與風(fēng)險(xiǎn)成比例。在這些需求和后續(xù)階段的產(chǎn)品之間保持可追溯性通常會(huì)導(dǎo)致項(xiàng)目管理頭痛。

軟件安全需求的規(guī)范 涉及它們從系統(tǒng)設(shè)計(jì)中的推導(dǎo)，隔離軟件特定的元素，并詳細(xì)說(shuō)明較低級(jí)別的軟件相關(guān)需求的演變過(guò)程，包括那些具有安全相關(guān)元素的需求。

接下來(lái)是軟件架構(gòu)設(shè)計(jì) 階段，可能使用 UML 圖形表示。靜態(tài)分析工具通過(guò)提供代碼組件之間關(guān)系的圖形表示來(lái)幫助與預(yù)期設(shè)計(jì)進(jìn)行比較（圖 2）。

圖 2：靜態(tài)分析工具提供代碼組件之間關(guān)系的圖形表示，以便與預(yù)期設(shè)計(jì)進(jìn)行比較——在本例中，是控制和數(shù)據(jù)流之間的關(guān)系。

顯示了來(lái)自 ISO 26262-6:2011 的與軟件單元設(shè)計(jì)和實(shí)施有關(guān)的表格的典型示例（圖 3）。它顯示了在實(shí)施過(guò)程中要強(qiáng)制執(zhí)行的編碼和建模指南，并附有指示可以在自動(dòng)化工具的幫助下確認(rèn)合規(guī)性的地方。

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

“語(yǔ)言子集的使用”（表中的主題 1b）舉例說(shuō)明了安全考慮對(duì)流程的影響。語(yǔ)言子集傳統(tǒng)上被視為對(duì)安全的幫助，但對(duì) MISRA C:2012 標(biāo)準(zhǔn)和安全特定標(biāo)準(zhǔn)（如通用弱點(diǎn)枚舉 (CWE)）的安全增強(qiáng)反映了人們對(duì)它們?cè)诮鉀Q安全問(wèn)題中必須發(fā)揮的作用越來(lái)越感興趣. 這些也可以通過(guò)靜態(tài)分析進(jìn)行檢查（圖 4）。

圖 4：編碼標(biāo)準(zhǔn)違反 MISRA C:2012 標(biāo)準(zhǔn)和安全特定標(biāo)準(zhǔn)（如通用弱點(diǎn)枚舉 (CWE)）的安全增強(qiáng)可以通過(guò)靜態(tài)分析進(jìn)行檢查。

動(dòng)態(tài)分析技術(shù)（涉及部分或全部代碼的執(zhí)行）適用于項(xiàng)目集成和測(cè)試。項(xiàng)目測(cè)試旨在孤立地關(guān)注特定的軟件過(guò)程或功能，而集成測(cè)試確保當(dāng)單元根據(jù)軟件架構(gòu)設(shè)計(jì)協(xié)同工作時(shí)滿足安全、保障和功能要求（圖 5）。

圖 5：項(xiàng)目測(cè)試界面顯示軟件界面如何在功能范圍內(nèi)公開(kāi)，允許用戶輸入輸入和預(yù)期輸出以形成測(cè)試工具的基礎(chǔ)。

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

除了顯示軟件功能正確之外，動(dòng)態(tài)分析還用于生成結(jié)構(gòu)覆蓋率度量。安全標(biāo)準(zhǔn) CWE 要求使用代碼覆蓋分析來(lái)確保不存在旨在增加應(yīng)用程序攻擊面和暴露弱點(diǎn)的隱藏功能。

管理無(wú)限的開(kāi)發(fā)生命周期雙向可追溯性原則貫穿整個(gè) ISO26262 V 模型，每個(gè)開(kāi)發(fā)階段都需要準(zhǔn)確反映之前的開(kāi)發(fā)階段。理論上，如果遵循標(biāo)準(zhǔn)的確切順序，那么需求永遠(yuǎn)不會(huì)改變，測(cè)試也永遠(yuǎn)不會(huì)拋出問(wèn)題。但生活不是這樣的。

例如，很容易想象這些過(guò)程與“綠地”項(xiàng)目相關(guān)。但是，如果需要集成許多不同的子系統(tǒng)怎么辦？如果其中一些是預(yù)先存在的，并且要求以不同的格式定義怎么辦？如果其中一些系統(tǒng)是在沒(méi)有考慮安全性的情況下編寫(xiě)的，假設(shè)是一個(gè)孤立的系統(tǒng)怎么辦？如果不同的子系統(tǒng)處于不同的開(kāi)發(fā)階段怎么辦？

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

如果需要更改，則需要重新靜態(tài)分析修改后的代碼，并且需要重新運(yùn)行所有受影響的單元和集成測(cè)試（回歸測(cè)試）。盡管這可能會(huì)導(dǎo)致當(dāng)時(shí)的項(xiàng)目管理噩夢(mèng)，但在一個(gè)孤立的應(yīng)用程序中，它的持續(xù)時(shí)間比產(chǎn)品正在開(kāi)發(fā)的時(shí)間長(zhǎng)一點(diǎn)。

連通性改變了這一切。每當(dāng)發(fā)現(xiàn)一個(gè)新的漏洞時(shí)，就會(huì)導(dǎo)致滿足它的需求變化，再加上額外的壓力，即如果產(chǎn)品在現(xiàn)場(chǎng)不受到損害，那么快速響應(yīng)可能至關(guān)重要。

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

在開(kāi)發(fā)傳統(tǒng)的、孤立的系統(tǒng)時(shí)，這顯然是足夠有用的。但是連通性需要對(duì)漏洞做出響應(yīng)的能力，因?yàn)槊總€(gè)新發(fā)現(xiàn)的漏洞都意味著一個(gè)變化的或新的需求，并且需要立即響應(yīng)——即使開(kāi)發(fā)工程師可能已經(jīng)有很長(zhǎng)一段時(shí)間沒(méi)有觸及系統(tǒng)本身了。在這種情況下，能夠隔離所需內(nèi)容并僅自動(dòng)測(cè)試已實(shí)現(xiàn)的功能變得更加重要。

圖 6：自動(dòng)化的雙向可追溯性鏈接來(lái)自大量不同來(lái)源的需求，直至設(shè)計(jì)、編碼和測(cè)試。

結(jié)論嵌入式汽車系統(tǒng)依賴于安全強(qiáng)化操作系統(tǒng)、虛擬機(jī)管理程序、分離內(nèi)核和引導(dǎo)映像完整性驗(yàn)證等技術(shù)。這些技術(shù)不僅提供了針對(duì)侵略者的多層次防御，而且還可以以相互支持的方式使用，以提供與所涉及風(fēng)險(xiǎn)相稱的防御水平。

在這樣的開(kāi)發(fā)過(guò)程中可以使用現(xiàn)有的工具和技術(shù)，有時(shí)會(huì)進(jìn)行調(diào)整以適應(yīng)安全編碼規(guī)則的情況，以補(bǔ)充那些強(qiáng)調(diào)安全的現(xiàn)有工具和技術(shù)。一些技術(shù)，例如覆蓋率分析，使用了一種完全相似的方法，但目的略有不同——在這種情況下，包括確保沒(méi)有任何額外的“后門”代碼。

需求、設(shè)計(jì)、代碼和測(cè)試之間的雙向可追溯性是 ISO 26262 的基本要求，其自動(dòng)化可以大大節(jié)省項(xiàng)目管理開(kāi)銷。當(dāng)安全漏洞的影響可能在產(chǎn)品發(fā)布后很長(zhǎng)時(shí)間內(nèi)對(duì)項(xiàng)目產(chǎn)生新的要求時(shí)，這種自動(dòng)化可追溯性的重要性就更加突出。在這種情況下，對(duì)需求變化的快速響應(yīng)具有挽救生命和提高聲譽(yù)的潛力。

審核編輯 黃昊宇