雖然連接的系統(tǒng)帶來了更容易的監(jiān)控、升級(jí)和增強(qiáng)，但它們也呈現(xiàn)出更易受攻擊的表面。防御此類攻擊可能很困難。

應(yīng)用多個(gè)安全級(jí)別——例如，正確加載圖像的安全啟動(dòng)、域分離和減少攻擊面——確保如果一個(gè)級(jí)別失敗，其他級(jí)別仍然存在。雖然單獨(dú)的安全應(yīng)用程序代碼無法在不安全的環(huán)境中提供足夠的保護(hù)，但它確實(shí)在設(shè)計(jì)時(shí)考慮到安全性的系統(tǒng)中發(fā)揮了關(guān)鍵作用。

無論首選的開發(fā)生命周期如何，這都是正確的。因此，嵌入式開發(fā)團(tuán)隊(duì)越來越多地接受 DevOps 原則，而其他人則更喜歡傳統(tǒng)上與功能安全標(biāo)準(zhǔn)相關(guān)的 V 模型，例如航空航天的 DO-178C、汽車的 ISO 26262 和醫(yī)療設(shè)備的 IEC 62304。

從 DevOps 到 DevSecOps 深度防御

DevOps 方法整合了開發(fā)和運(yùn)營團(tuán)隊(duì)，專為應(yīng)對不斷變化的環(huán)境而設(shè)計(jì)。DevOps 為許多嵌入式應(yīng)用程序帶來了明顯的好處。例如，通過更集成的產(chǎn)品開發(fā)可以更快地滿足新的市場需求，也許最重要的是，應(yīng)用程序補(bǔ)丁和更新（例如汽車軟件的無線 (OTA) 安全性）可以比其他方法更快地應(yīng)用。

DevSecOps（代表開發(fā)安全操作）以“左移”原則擴(kuò)展了 DevOps 原則，在每次軟件迭代中盡早并持續(xù)地設(shè)計(jì)和測試安全性。

縱深防御和過程模型

傳統(tǒng)上，安全嵌入式代碼驗(yàn)證的實(shí)踐在很大程度上是被動(dòng)的。代碼是按照相對寬松的準(zhǔn)則開發(fā)的，然后進(jìn)行性能、滲透、負(fù)載和功能測試以識(shí)別漏洞。

更主動(dòng)的方法可確保代碼在設(shè)計(jì)上是安全的。這意味著一個(gè)系統(tǒng)的開發(fā)過程，其中代碼是根據(jù)安全編碼標(biāo)準(zhǔn)編寫的，可以追溯到安全要求，并經(jīng)過測試以證明隨著開發(fā)的進(jìn)展符合這些要求。

這種主動(dòng)方法的一種解釋是將與安全相關(guān)的最佳實(shí)踐集成到功能安全領(lǐng)域的開發(fā)人員熟悉的 V 模型軟件開發(fā)生命周期中。由此產(chǎn)生的安全軟件開發(fā)生命周期 (SSDLC) 代表了以安全為中心的應(yīng)用程序開發(fā)人員的左移，確保漏洞是在系統(tǒng)之外設(shè)計(jì)的（圖 1）。

圖1 V模型中安全測試工具和技術(shù)的使用基于安全軟件開發(fā)生命周期（SSLDLC）框架。資料來源：LDRA

盡管 DevSecOps 和 SSDLC 的上下文不同，但向左移動(dòng)對兩者來說意味著相同的事情——早期和持續(xù)的安全考慮（圖 2）。

圖 2 DevSecOps 流程模型利用安全測試工具和技術(shù)。資料來源：LDRA

左移：這意味著什么

任何開發(fā)安全關(guān)鍵型應(yīng)用程序的人都應(yīng)該熟悉“左移”原則背后的概念，因?yàn)槎嗄陙?，功能安全?biāo)準(zhǔn)要求采用類似的方法。因此，在功能安全領(lǐng)域證明的以下最佳實(shí)踐也適用于安全關(guān)鍵型應(yīng)用程序：

從一開始就確定要求

未記錄的需求會(huì)導(dǎo)致各方溝通不暢，并造成返工、更改、錯(cuò)誤修復(fù)和安全漏洞。為確保項(xiàng)目順利開發(fā)，所有團(tuán)隊(duì)成員必須以相同的方式了解產(chǎn)品的所有部分及其開發(fā)過程。明確定義的功能和安全要求有助于確保他們這樣做。

這樣的要求可能會(huì)為 V 模型開發(fā)人員定義一個(gè)完整的系統(tǒng)，而對于那些應(yīng)用 DevSecOps 的人來說，這只是一個(gè)迭代。但是，原理保持不變。這并不是說軟件永遠(yuǎn)不能用作“智力模型粘土”來創(chuàng)建概念驗(yàn)證，而是這種實(shí)驗(yàn)的最終結(jié)果應(yīng)該是明確定義的需求——并適當(dāng)?shù)亻_發(fā)生產(chǎn)代碼來滿足這些需求。

提供雙向追溯

雙向可追溯性意味著追溯路徑既向前又向后維護(hù)，而自動(dòng)化使在不斷變化的項(xiàng)目環(huán)境中維護(hù)變得更加容易（圖 3）。

圖 3 自動(dòng)化使雙向可追溯性更易于維護(hù)。資料來源：LDRA

前向可追溯性表明所有需求都反映在開發(fā)過程的每個(gè)階段，包括實(shí)施和測試。可以通過應(yīng)用影響分析來評估更改的需求或失敗的測試用例的后果。然后可以重新測試修訂后的實(shí)施，以提供繼續(xù)遵守雙向可追溯性原則的證據(jù)。

向后追溯，它突出顯示不滿足任何指定要求的代碼，同樣重要。否則，疏忽、錯(cuò)誤邏輯、功能蔓延和惡意后門方法的插入可能會(huì)引入安全漏洞或錯(cuò)誤。

安全嵌入式應(yīng)用程序的任何妥協(xié)都需要更改或新的要求，并且需要立即響應(yīng)——通常是源代碼開發(fā)工程師很長時(shí)間沒有觸及的內(nèi)容。在這種情況下，自動(dòng)可追溯性可以隔離所需內(nèi)容并僅對受影響的功能進(jìn)行自動(dòng)測試。

使用安全語言子集

對于 C 或 C++ 開發(fā)，研究表明大約 80% 的軟件缺陷源于大約 20% 的語言的不正確使用。為了解決這個(gè)問題，開發(fā)人員可以使用通過禁止有問題的結(jié)構(gòu)來提高安全性和安全性的語言子集。

兩個(gè)常見的子集是 MISRA C 和卡內(nèi)基梅隆軟件工程學(xué)院 (SEI) CERT C，它們都可以幫助開發(fā)人員生成安全代碼。這兩個(gè)標(biāo)準(zhǔn)具有相似的目標(biāo)，但實(shí)施方式不同。

一般來說，使用 MISRA C 開發(fā)新代碼會(huì)導(dǎo)致更少的編碼錯(cuò)誤，因?yàn)樗哂谢诘谝辉瓌t定義的更嚴(yán)格、更可判定的規(guī)則。參照 MISRA C 編碼標(biāo)準(zhǔn)快速輕松地分析軟件的能力可以提高代碼質(zhì)量和一致性，并縮短部署時(shí)間。相比之下，當(dāng)開發(fā)人員需要追溯應(yīng)用規(guī)則來編碼時(shí)，CERT C 可能是一個(gè)務(wù)實(shí)的選擇。針對 CERT C 分析代碼可識(shí)別大多數(shù)軟件安全攻擊背后的常見編程錯(cuò)誤。

應(yīng)用 MISRA C 或 CERT C 會(huì)產(chǎn)生更安全的代碼。在任何顯著大小的代碼庫上手動(dòng)執(zhí)行此類標(biāo)準(zhǔn)是不切實(shí)際的，因此需要靜態(tài)分析工具。

遵守以安全為中心的流程標(biāo)準(zhǔn)

在安全關(guān)鍵領(lǐng)域，適當(dāng)?shù)臉?biāo)準(zhǔn)經(jīng)常補(bǔ)充那些關(guān)注功能安全的標(biāo)準(zhǔn)。例如，J3061“網(wǎng)絡(luò)物理車輛系統(tǒng)的網(wǎng)絡(luò)安全指南”——即將被 ISO/SAE 21434“道路車輛——網(wǎng)絡(luò)安全工程”取代——補(bǔ)充了汽車 ISO 26262 功能安全標(biāo)準(zhǔn)。如果需要，自動(dòng)化開發(fā)工具可以集成到安全關(guān)鍵系統(tǒng)的開發(fā)人員工作流程中，并且可以同時(shí)滿足功能安全需求。

自動(dòng)化 SAST（靜態(tài)）和 DAST（動(dòng)態(tài)）測試過程

靜態(tài)分析是涉及自動(dòng)檢查源代碼的測試制度的統(tǒng)稱。相比之下，動(dòng)態(tài)分析涉及部分或全部源代碼的執(zhí)行。此類技術(shù)對安全問題的關(guān)注分別導(dǎo)致靜態(tài)應(yīng)用程序安全測試 (SAST) 和動(dòng)態(tài)分析安全測試 (DAST)。

在這些分組中存在很大差異。例如，滲透、功能和模糊測試都是黑盒 DAST 測試，不需要訪問源代碼即可實(shí)現(xiàn)其功能。黑盒 DAST 測試是對白盒 DAST 測試的補(bǔ)充，白盒測試包括單元測試、集成測試和系統(tǒng)測試，以通過動(dòng)態(tài)分析揭示應(yīng)用程序源代碼中的漏洞。

盡早并經(jīng)常測試

所描述的所有與安全相關(guān)的工具、測試和技術(shù)在每個(gè)生命周期模型中都有一席之地。在 V 模型中，它們在很大程度上類似于和補(bǔ)充通常與功能安全應(yīng)用程序開發(fā)相關(guān)的過程。

在 V 模型的情況下，需求可追溯性在整個(gè)開發(fā)過程中得到維護(hù)，在 DevSecOps 模型的情況下，需求可追溯性在每個(gè)開發(fā)迭代中得到維護(hù)。

一些 SAST 工具用于確認(rèn)遵守編碼標(biāo)準(zhǔn)，確保將復(fù)雜性保持在最低限度，并檢查代碼是否可維護(hù)。其他用于檢查安全漏洞，但僅限于在沒有執(zhí)行環(huán)境上下文的情況下對源代碼進(jìn)行此類檢查的范圍內(nèi)。

白盒 DAST 使編譯和執(zhí)行的代碼能夠在開發(fā)環(huán)境中進(jìn)行測試，或者更好的是，在目標(biāo)硬件上進(jìn)行測試。代碼覆蓋有助于確認(rèn)代碼滿足所有安全和其他要求，并且所有代碼都滿足一個(gè)或多個(gè)要求。如果系統(tǒng)的關(guān)鍵性需要，這些檢查甚至可以達(dá)到目標(biāo)代碼級(jí)別。

可以在單元測試環(huán)境中使用健壯性測試來幫助證明特定功能是有彈性的，無論是孤立的還是在其調(diào)用樹的上下文中。傳統(tǒng)的模糊和滲透黑盒 DAST 測試技術(shù)仍然很有價(jià)值，但在這種情況下，用于確認(rèn)和展示在安全基礎(chǔ)上設(shè)計(jì)和開發(fā)的系統(tǒng)的穩(wěn)健性。

使用自動(dòng)化工具為安全鋪平道路

在開始軟件開發(fā)過程之前，開發(fā)人員應(yīng)該能夠使用自動(dòng)化工具，例如加快開發(fā)、認(rèn)證和批準(zhǔn)過程的測試軟件。使用這些工具在整個(gè)生命周期內(nèi)支持他們的工作，同時(shí)遵循與“左移，早期測試”方法相關(guān)的最佳實(shí)踐，有助于提高互聯(lián)嵌入式系統(tǒng)的安全性，從而繼續(xù)為行業(yè)帶來如此重大的變化。

審核編輯 黃昊宇