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