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

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

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

從 DevOps 到 DevSecOps 深度防御

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

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

縱深防御和過程模型

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

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

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

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

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

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

左移：這意味著什么

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

從一開始就確定要求

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

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

提供雙向追溯

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

圖 3 自動化使雙向可追溯性更易于維護。資料來源：LDRA

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

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

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

使用安全語言子集

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

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

一般來說，使用 MISRA C 開發(fā)新代碼會導(dǎo)致更少的編碼錯誤，因為它具有基于第一原則定義的更嚴格、更可判定的規(guī)則。參照 MISRA C 編碼標準快速輕松地分析軟件的能力可以提高代碼質(zhì)量和一致性，并縮短部署時間。相比之下，當開發(fā)人員需要追溯應(yīng)用規(guī)則來編碼時，CERT C 可能是一個務(wù)實的選擇。針對 CERT C 分析代碼可識別大多數(shù)軟件安全攻擊背后的常見編程錯誤。

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

遵守以安全為中心的流程標準

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

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

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

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

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

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

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

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

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

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

使用自動化工具為安全鋪平道路

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

審核編輯 黃昊宇