雖然安全的應(yīng)用程序代碼本身不能在不安全的環(huán)境中提供足夠的保護(hù)，但它確實在考慮安全性的系統(tǒng)中發(fā)揮著關(guān)鍵作用。無論首選的開發(fā)生命周期是什么，這都是正確的。因此，嵌入式開發(fā)團(tuán)隊越來越接受DevOps原則，而其他人則更喜歡傳統(tǒng)上與功能安全標(biāo)準(zhǔn)相關(guān)的V型，如航空航天的DO-178C、汽車的ISO
26262和醫(yī)療設(shè)備的IEC 62304。
從DevOps到DevSecOps進(jìn)行縱深防御
DevOps方法集成了開發(fā)和運(yùn)營團(tuán)隊，專門用于應(yīng)對不斷變化的環(huán)境。DevOps為許多嵌入式應(yīng)用程序帶來了明顯的好處。例如，通過更加集成的產(chǎn)品開發(fā)，可以更快地滿足新的市場需求，也許最重要的是，應(yīng)用程序補(bǔ)丁和更新(如汽車軟件的空中傳送(OTA)安全性)可以比其他方法更快地應(yīng)用。
DevSecOps代表開發(fā)安全操作，它以DevOps原則為基礎(chǔ)，采用“左移”原則進(jìn)行擴(kuò)展，在每次軟件迭代中盡早并持續(xù)地設(shè)計和測試安全性。
縱深防御與過程模型
傳統(tǒng)上，安全嵌入式代碼驗證的實踐在很大程度上是被動的。代碼是根據(jù)相對寬松的指導(dǎo)原則開發(fā)的，然后進(jìn)行性能、滲透、負(fù)載和功能測試，以識別漏洞。
更主動的方法可以確保代碼在設(shè)計上是安全的，這意味著一個系統(tǒng)化的嵌入式開發(fā)過程，在這個過程中，代碼是按照安全編碼標(biāo)準(zhǔn)編寫的，可追溯到安全需求，并經(jīng)過測試，以證明在開發(fā)過程中符合這些需求。
這種主動式方法的一種解釋是將安全相關(guān)的最佳實踐集成到V型軟件開發(fā)生命周期中，這是功能安全領(lǐng)域的開發(fā)人員所熟悉的。由此產(chǎn)生的安全軟件開發(fā)生命周期(SSDLC)代表了專注于安全的應(yīng)用程序開發(fā)人員的一個轉(zhuǎn)變，確保漏洞是在系統(tǒng)之外設(shè)計的。
左移：這意味著什么
任何開發(fā)安全關(guān)鍵應(yīng)用程序的人都應(yīng)該熟悉“左移”原則背后的概念，因為多年來，功能安全標(biāo)準(zhǔn)要求采用類似的方法。因此，以下在功能安全領(lǐng)域得到驗證的最佳實踐也適用于安全關(guān)鍵應(yīng)用：
從一開始就確定需求
未記錄的需求會導(dǎo)致各方溝通錯誤，并造成返工、更改、錯誤修復(fù)和安全漏洞。為確保嵌入式開發(fā)順利進(jìn)行，所有團(tuán)隊成員必須以同樣的方式了解產(chǎn)品的所有部分及其開發(fā)過程。明確定義的功能和安全需求有助于確保它們做到這一點(diǎn)。
這些需求很可能為V-model開發(fā)人員定義一個完整的系統(tǒng)，而僅僅是應(yīng)用DevSecOps的開發(fā)人員的一個迭代。然而，原則仍然是一樣的。這并不是說軟件永遠(yuǎn)不能用作“智能建模粘土”來創(chuàng)建概念驗證，但此類實驗的最終結(jié)果應(yīng)該是明確定義的需求和適當(dāng)開發(fā)的生產(chǎn)代碼，以滿足這些需求。
提供雙向可追溯性
雙向可追溯性意味著可追溯性路徑可以向前和向后維護(hù)，而自動化使其在不斷變化的項目環(huán)境中更易于維護(hù)。
正向可追溯性表明，所有需求都反映在嵌入式開發(fā)過程的每個階段，包括實現(xiàn)和測試。通過應(yīng)用影響分析，可以評估變更需求或失敗測試用例的后果。然后可以重新測試修改后的實施，以提供繼續(xù)遵守雙向可追溯性原則的證據(jù)。
反向可追溯性同樣重要，它強(qiáng)調(diào)了不滿足任何特定需求的代碼。否則，疏忽、錯誤的邏輯、功能爬行和惡意后門方法的插入可能會引入安全漏洞或錯誤。
安全嵌入式應(yīng)用程序的任何妥協(xié)都需要一個更改的或新的需求，并且需要對源代碼開發(fā)工程師很長時間沒有接觸到的內(nèi)容立即做出響應(yīng)。在這種情況下，自動跟蹤可以隔離所需的內(nèi)容，并僅對受影響的功能進(jìn)行自動測試。
使用安全的語言子集
對于C或C++的開發(fā)，研究表明大約80%的軟件缺陷源于錯誤的使用語言的大約20%。為了解決這個問題，開發(fā)人員可以使用通過禁止有問題的構(gòu)造來提高安全性和安全性的語言子集。
兩個常見的子集是MISRA C和卡內(nèi)基梅隆軟件工程研究所(SEI)CERT
C，它們都幫助嵌入式開發(fā)人員生成安全代碼。這兩個標(biāo)準(zhǔn)的目標(biāo)相似，但實施方式不同。
一般來說，使用MISRA
C開發(fā)新代碼會導(dǎo)致更少的編碼錯誤，因為它具有更嚴(yán)格、更可判定的規(guī)則，這些規(guī)則是根據(jù)第一原則定義的。參考MISRA
C編碼標(biāo)準(zhǔn)快速方便地分析軟件的能力可以提高代碼質(zhì)量和一致性，并縮短部署時間。相反，當(dāng)開發(fā)人員需要對代碼追溯應(yīng)用規(guī)則時，CERT
C可能是一個實用的選擇。針對CERT C分析代碼可以識別大多數(shù)軟件安全攻擊背后的常見編程錯誤。
應(yīng)用MISRA C或CERT
C都會產(chǎn)生更安全的代碼。在任何規(guī)模的代碼庫上手動執(zhí)行此類標(biāo)準(zhǔn)都是不現(xiàn)實的，因此需要一個靜態(tài)分析工具。
遵守以安全為中心的流程標(biāo)準(zhǔn)
在安全關(guān)鍵部門，適當(dāng)?shù)臉?biāo)準(zhǔn)經(jīng)常補(bǔ)充那些注重功能安全的標(biāo)準(zhǔn)。如果需要，可以將自動化開發(fā)工具集成到安全關(guān)鍵系統(tǒng)的嵌入式開發(fā)人員工作流中，并同時滿足功能安全需求。
自動化SAST(靜態(tài))和DAST(動態(tài))測試過程
靜態(tài)分析是涉及源代碼自動檢查的測試機(jī)制的總稱。相反，動態(tài)分析涉及部分或全部源代碼的執(zhí)行。這些技術(shù)對安全問題的關(guān)注分別導(dǎo)致了靜態(tài)應(yīng)用程序安全測試(SAST)和動態(tài)分析安全測試(DAST)。
在這些分組中有很大的差異。例如，滲透測試、功能測試和模糊測試都是黑盒DAST測試，不需要訪問源代碼來實現(xiàn)其功能。黑盒DAST測試是對白盒DAST測試的補(bǔ)充，白盒DAST測試包括單元測試、集成測試和系統(tǒng)測試，以通過動態(tài)分析揭示應(yīng)用程序源代碼中的漏洞。
早測多測
所描述的所有安全相關(guān)工具、測試和技術(shù)在每個生命周期模型中都占有一席之地。在V模型中，它們在很大程度上類似于通常與功能安全應(yīng)用程序開發(fā)相關(guān)的過程，并與之互補(bǔ)。
對于V模型，需求可追溯性在整個嵌入式開發(fā)過程中保持，對于DevSecOps模型，需求可追溯性在每個開發(fā)迭代中保持。
一些SAST工具用于確認(rèn)遵守編碼標(biāo)準(zhǔn)，確保復(fù)雜性保持在最低限度，并檢查代碼是否可維護(hù)。另一些用于檢查安全漏洞，但僅限于在沒有執(zhí)行環(huán)境上下文的情況下對源代碼進(jìn)行此類檢查。
白盒DAST使編譯和執(zhí)行的代碼能夠在開發(fā)環(huán)境中進(jìn)行測試，或者更好地在目標(biāo)硬件上進(jìn)行測試。代碼覆蓋有助于確認(rèn)代碼滿足了所有安全性和其他要求，并且所有代碼都滿足了一個或多個要求。如果系統(tǒng)的關(guān)鍵性需要，這些檢查甚至可以進(jìn)入目標(biāo)代碼級別。
健壯性測試可以在單元測試環(huán)境中使用，以幫助證明特定功能是有彈性的，無論是在隔離環(huán)境中還是在其調(diào)用樹的上下文中。傳統(tǒng)的模糊和穿透黑箱DAST測試技術(shù)仍然是有價值的，但在這一背景下被用來證實和證明系統(tǒng)的健壯性和安全性。
為自動化工具的安全性鋪平道路
在開始軟件開發(fā)過程之前，嵌入式開發(fā)人員應(yīng)該能夠使用自動化工具，例如測試軟件，以加快開發(fā)、認(rèn)證和批準(zhǔn)過程。使用這些工具在整個生命周期中支持他們的工作，同時遵循與“左移，盡早測試”方法相關(guān)的最佳實踐，有助于提高連接嵌入式系統(tǒng)的安全性，這些系統(tǒng)將繼續(xù)為行業(yè)帶來如此重大的變化。
