在嵌入式開發中，如果底層架構不安全，安全的應用程序代碼在保護連接的嵌入式系統方面幾乎不起作用，但在一個以安全性為設計理念的系統中，它確實扮演著重要角色。

 

縱深防御和V型模式

傳統上，安全代碼驗證的實踐在很大程度上是被動的。代碼是通過遵循一些松散的指導方針開發的，然后經過性能、滲透、負載和功能測試來發現漏洞，這些漏洞稍后會被修復。

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

 

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

 

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

 

盡早并經常測試

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

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

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

圖2：在DevSecOps過程模型中安全測試工具和技術的使用[1]

 

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

 

一些SAST(靜態)工具用于確認遵守編碼標準，確保復雜性保持在最低水平，并檢查代碼是否可維護。其他的用于檢查安全漏洞，但是僅限于在沒有執行環境的情況下對源代碼進行這種檢查。

 

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

 

健壯性測試可以在單元測試環境中使用，以幫助證明特定的函數是有彈性的，無論是在它們的調用樹的上下文中。

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

 

提供雙向可追溯性

軟件工程術語的IEEE標準詞匯表將可追溯性定義為“在開發過程的兩個或更多產品之間建立關系的程度，尤其是相互之間具有前任-繼任者或主從關系的產品。”雙向可追溯性意味著可追溯性路徑被向前和向后維護(圖3)。

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

圖3：雙向可追溯性

 

前向可追溯性表明所有需求都反映在嵌入式開發過程的每個階段，包括實現和測試。任何需求變更或者失敗的測試用例的影響都可以通過應用影響分析來評估，然后再進行處理。然后，可以對最終的實現進行重新測試，以提供繼續遵循雙向可追溯性原則的證據。

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

 

重要的是要記住，一個安全的嵌入式工件的生命周期一直持續到這個領域中的最后一個例子不再被使用。對這樣一個工件的任何妥協都需要一個響應，一個變更的或者新的需求，一個需要立即響應的需求——通常是對開發工程師很久沒有接觸的源代碼。在這種情況下，自動化的可追溯性可以隔離出所需要的東西，并且只對受影響的功能進行自動化測試。

 

實踐中的左移

開發安全關鍵應用程序的個人和團隊都熟悉左移原則所包含的概念。多年來，功能安全標準要求采用類似的方法。因此，許多在功能安全領域得到驗證的最佳實踐適用于前面討論的安全關鍵型應用程序，包括在一開始(V-model)或每次迭代之前(DevSecOps)建立功能和安全需求，盡早并經常進行測試，以及將雙向跟蹤需求應用于嵌入式開發的所有階段。