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

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

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

從 DevOps 到 DevSecOps 深度防御

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

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

縱深防御和過程模型

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

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

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

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

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

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

左移：這意味著什么

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

從一開始就確定要求

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

這樣的要求可能會為 V 模型開發人員定義一個完整的系統，而對于那些應用 DevSecOps 的人來說，這只是一個迭代。但是，原理保持不變。這并不是說軟件永遠不能用作“智力模型粘土”來創建概念驗證，而是這種實驗的最終結果應該是明確定義的需求——并適當地開發生產代碼來滿足這些需求。

提供雙向追溯

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

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

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

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

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

使用安全語言子集

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

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

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

應用 MISRA C 或 CERT C 會產生更安全的代碼。在任何顯著大小的代碼庫上手動執行此類標準是不切實際的，因此需要靜態分析工具。

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

在安全關鍵領域，適當的標準經常補充那些關注功能安全的標準。例如，J3061“網絡物理車輛系統的網絡安全指南”——即將被 ISO/SAE 21434“道路車輛——網絡安全工程”取代——補充了汽車 ISO 26262 功能安全標準。如果需要，自動化開發工具可以集成到安全關鍵系統的開發人員工作流程中，并且可以同時滿足功能安全需求。

自動化 SAST（靜態）和 DAST（動態）測試過程

靜態分析是涉及自動檢查源代碼的測試制度的統稱。相比之下，動態分析涉及部分或全部源代碼的執行。此類技術對安全問題的關注分別導致靜態應用程序安全測試 (SAST) 和動態分析安全測試 (DAST)。

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

盡早并經常測試

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

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

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

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

可以在單元測試環境中使用健壯性測試來幫助證明特定功能是有彈性的，無論是孤立的還是在其調用樹的上下文中。傳統的模糊和滲透黑盒 DAST 測試技術仍然很有價值，但在這種情況下，用于確認和展示在安全基礎上設計和開發的系統的穩健性。

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

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

審核編輯 黃昊宇