雖然安全的應用程序代碼本身不能在不安全的環境中提供足夠的保護，但它確實在考慮安全性的系統中發揮著關鍵作用。無論首選的開發生命周期是什么，這都是正確的。因此，嵌入式開發團隊越來越接受DevOps原則，而其他人則更喜歡傳統上與功能安全標準相關的V型，如航空航天的DO-178C、汽車的ISO 26262和醫療設備的IEC 62304。

　　從DevOps到DevSecOps進行縱深防御

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

　　DevSecOps代表開發安全操作，它以DevOps原則為基礎，采用“左移”原則進行擴展，在每次軟件迭代中盡早并持續地設計和測試安全性。

　　縱深防御與過程模型

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

　　更主動的方法可以確保代碼在設計上是安全的，這意味著一個系統化的嵌入式開發過程，在這個過程中，代碼是按照安全編碼標準編寫的，可追溯到安全需求，并經過測試，以證明在開發過程中符合這些需求。

　　這種主動式方法的一種解釋是將安全相關的最佳實踐集成到V型軟件開發生命周期中，這是功能安全領域的開發人員所熟悉的。由此產生的安全軟件開發生命周期(SSDLC)代表了專注于安全的應用程序開發人員的一個轉變，確保漏洞是在系統之外設計的。

　　左移：這意味著什么

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

　　從一開始就確定需求

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

　　這些需求很可能為V-model開發人員定義一個完整的系統，而僅僅是應用DevSecOps的開發人員的一個迭代。然而，原則仍然是一樣的。這并不是說軟件永遠不能用作“智能建模粘土”來創建概念驗證，但此類實驗的最終結果應該是明確定義的需求和適當開發的生產代碼，以滿足這些需求。

　　提供雙向可追溯性

　　雙向可追溯性意味著可追溯性路徑可以向前和向后維護，而自動化使其在不斷變化的項目環境中更易于維護。

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

　　反向可追溯性同樣重要，它強調了不滿足任何特定需求的代碼。否則，疏忽、錯誤的邏輯、功能爬行和惡意后門方法的插入可能會引入安全漏洞或錯誤。

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

　　使用安全的語言子集

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

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

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

　　應用MISRA C或CERT C都會產生更安全的代碼。在任何規模的代碼庫上手動執行此類標準都是不現實的，因此需要一個靜態分析工具。

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

　　在安全關鍵部門，適當的標準經常補充那些注重功能安全的標準。如果需要，可以將自動化開發工具集成到安全關鍵系統的嵌入式開發人員工作流中，并同時滿足功能安全需求。

　　自動化SAST(靜態)和DAST(動態)測試過程

　　靜態分析是涉及源代碼自動檢查的測試機制的總稱。相反，動態分析涉及部分或全部源代碼的執行。這些技術對安全問題的關注分別導致了靜態應用程序安全測試(SAST)和動態分析安全測試(DAST)。

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

　　早測多測

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

　　對于V模型，需求可追溯性在整個嵌入式開發過程中保持，對于DevSecOps模型，需求可追溯性在每個開發迭代中保持。

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

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

　　健壯性測試可以在單元測試環境中使用，以幫助證明特定功能是有彈性的，無論是在隔離環境中還是在其調用樹的上下文中。傳統的模糊和穿透黑箱DAST測試技術仍然是有價值的，但在這一背景下被用來證實和證明系統的健壯性和安全性。

　　為自動化工具的安全性鋪平道路

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