雖然連接的系統為更容易監控、升級和增強帶來了新的機會，但它們也帶來了更易受攻擊的攻擊面。不幸的是，連接系統的任何單一防御都不能保證不可穿透性。幸運的是，有多個級別的安全性可以確保如果一個級別失敗，其他級別就會站穩腳跟。

這些縱深防御方法可以包括安全啟動，以確保正確的圖像加載；域分離；多個獨立的安全級別 （MILS） 設計原則，例如最小權限；攻擊面減少；以安全為中心的測試，例如靜態和動態分析，以及最后但并非最不重要的安全編碼技術。

雖然如果底層架構不安全，安全應用程序代碼對保護連接的嵌入式系統幾乎沒有作用，但它確實在考慮安全性的系統中發揮了關鍵作用。

縱深防御和 V 模型

傳統上，安全代碼驗證的實踐在很大程度上是被動的。代碼是按照有些松散的準則開發的，然后進行性能、滲透、負載和功能測試以發現漏洞，這些漏洞稍后會修復。

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

這種主動方法將與安全相關的最佳實踐集成到功能安全領域的開發人員熟悉的 V 模型軟件開發生命周期中。由此產生的安全軟件開發生命周期 （SSDLC） 代表了以安全為中心的應用程序開發人員的一種轉變，并提供了一種實用的方法來確保漏洞是在系統之外設計或及時徹底地解決的。

相同的原則可以應用于 DevOps 生命周期，從而產生所謂的 DevSecOps。盡管 DevSecOps 和 SSDLC 的上下文有所不同，但左移因此對兩者來說意味著相同的事情——即對安全性的早期和持續考慮。

盡早并經常測試

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

圖 1：在基于 V 模型的安全軟件開發生命周期 （SSDLC） 中使用安全測試工具和技術

在 DevSecOps 模型中，DevOps 生命周期與整個持續開發過程中的安全相關活動疊加（圖 2）。

圖 2：在 DevSecOps 流程模型中使用安全測試工具和技術［1］

在 V 模型的情況下，需求可追溯性在整個開發過程中得到維護，在 DevSecOps 模型的情況下，需求可追溯性在每個開發迭代中得到維護（在每個圖中以橙色顯示）。

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

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

可以在單元測試環境中使用健壯性測試來幫助證明特定功能是有彈性的，無論是在其調用樹的上下文中隔離。

傳統上與軟件安全相關的模糊和滲透黑盒測試技術仍然具有相當大的價值，但在這種情況下，用于確認和證明在安全基礎上設計和開發的系統的穩健性。

提供雙向追溯

IEEE 軟件工程術語標準詞匯表將可追溯性定義為“在開發過程的兩個或多個產品之間可以建立關系的程度，尤其是彼此之間具有前繼或主從關系的產品。” 雙向可追溯性意味著追溯路徑既向前又向后（圖 3）。

自動化使在不斷變化的項目環境中維護可追溯性變得更加容易。

圖 3：雙向追溯

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

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

必須記住，安全嵌入式工件的生命周期一直持續到該領域的最后一個示例不再使用。對此類工件的任何妥協都需要響應、更改的或新的需求，并且需要立即響應——通常是針對開發工程師很長時間沒有接觸過的源代碼。在這種情況下，自動可追溯性可以隔離所需內容并僅對受影響的功能進行自動測試。

實踐中左移

左移原則所包含的概念對于開發安全關鍵型應用程序的個人和團隊來說是很熟悉的。多年來，功能安全標準要求采用類似的方法。因此，在功能安全領域證明的許多最佳實踐適用于前面討論的安全關鍵型應用程序，包括在開始時（V 模型）或每次迭代之前（DevSecOps）建立功能和安全要求，及早和經常測試，以及應用雙向跟蹤需求到開發的所有階段。

審核編輯：郭婷