它包含龐大的代碼庫并跨越關(guān)鍵的板載系統(tǒng)。多年來，制造商一直依賴MISRA C/C++ 編碼指南來幫助軟件開發(fā)。該框架為汽車行業(yè)及其他行業(yè)帶來了實(shí)際好處和安全收益。

許多創(chuàng)建汽車軟件的開發(fā)團(tuán)隊(duì)使用 MISRA 指南和應(yīng)用程序安全工具，包括靜態(tài)應(yīng)用程序安全測試 （SAST）。這使得在途中發(fā)現(xiàn)語法和其他編碼錯(cuò)誤成為可能，從而降低安全漏洞和關(guān)鍵安全問題的風(fēng)險(xiǎn)。該框架還有助于降低開發(fā)成本并加快上市時(shí)間。

然而，以最大效率結(jié)合使用這些指南和工具可能具有挑戰(zhàn)性。問題？許多應(yīng)用程序安全 （AppSec） 工具需要大量的人工干預(yù)或監(jiān)督，才能充分了解它們?nèi)绾斡绊懜鞣N流程。

破解密碼

問題的核心是一個(gè)基本事實(shí)：在手動(dòng)執(zhí)行 MISRA 標(biāo)準(zhǔn)時(shí)會(huì)很困難。許多基本的 AppSec 工具只處理規(guī)則檢查——因此提供了一些幫助，但回避了與應(yīng)用程序安全相關(guān)的核心問題。它們不解決關(guān)鍵任務(wù)，例如錯(cuò)誤檢測和安全漏洞分析。

不幸的是，遵循基本的 MISRA 指南并不能提供足夠的保護(hù)。雖然它可以消除一些錯(cuò)誤并提高 C 或 C++ 的代碼質(zhì)量，但它并不針對龐大的代碼庫和日益復(fù)雜的開發(fā)實(shí)踐。錯(cuò)誤和缺陷仍然是編寫代碼的不幸和不可避免的副作用。

這是所有汽車制造商都面臨的問題。研究表明，商業(yè)軟件平均每 1，000 行代碼 （KLOC） 就有一個(gè)缺陷。雖然開源表現(xiàn)更好一些，但它的測量值為 0.68/KLOC，但它仍然是一個(gè)嚴(yán)重的問題。考慮一下：今天的豪華車有大約 1 億行代碼。即使在最佳情況下，這也代表了大約 10，000 個(gè)影響質(zhì)量、安全和安保的潛在缺陷。

當(dāng)然，事后補(bǔ)救問題和修復(fù)問題既昂貴又耗時(shí)。當(dāng)召回車輛以修復(fù)軟件缺陷時(shí)，這也會(huì)給消費(fèi)者帶來壓力。不幸的是，問題的根本原因通常仍然未知，并且很難找到漏洞的實(shí)際來源。這意味著開發(fā)人員必須重現(xiàn)故障，對其進(jìn)行分析，并嘗試了解它如何影響代碼庫的其他部分。實(shí)際上，這意味著許多錯(cuò)誤可能永遠(yuǎn)無法修復(fù)。

但是，當(dāng)組織以更深入、更廣泛的方式將包括 SAST 在內(nèi)的 AppSec 集成到開發(fā)過程中時(shí)，就有可能將安全性提升到更高級的水平。組織不再局限于代碼庫的部分快照?？梢陨钊胙芯?，獲得可見性并進(jìn)行更詳盡的測試。使用 SAST，可以在開發(fā)過程的早期解決和修復(fù)缺陷，加速軟件發(fā)布并確保質(zhì)量、安全和保障。

推進(jìn) AppSec

好消息是高級測試解決方案支持更全面的應(yīng)用程序安全框架。他們可以發(fā)現(xiàn)傳統(tǒng)開發(fā)方法中漏掉的缺陷。這包括確定關(guān)鍵問題，例如：

經(jīng)常隨機(jī)發(fā)生的并發(fā)缺陷，只有在組織在最終硬件平臺上集成各種系統(tǒng)和代碼存儲庫后才可見。

安全漏洞，也就是軟件缺陷，可以被攻擊者利用，以便他們可以干擾系統(tǒng)的行為并獲得對關(guān)鍵數(shù)據(jù)的訪問權(quán)限。

警告潛在漏洞的污染數(shù)據(jù)分析可能格式不正確。因?yàn)檫@些數(shù)據(jù)要經(jīng)過許多系統(tǒng)，所以通常很難發(fā)現(xiàn)。

難以檢測的復(fù)雜程序間缺陷，尤其是單元和子系統(tǒng)測試。

對顯示為目標(biāo)文件、庫和可執(zhí)行文件的編譯代碼進(jìn)行錯(cuò)誤檢測。這些可以掩蓋關(guān)鍵的安全問題。

雖然一些 MISRA 規(guī)則足夠簡單，只依賴于代碼語法檢查器，但單獨(dú)依賴這種方法是錯(cuò)誤的。更好的方法是更深入地?cái)U(kuò)展分析并解決上述關(guān)鍵問題。這包括生成軟件材料清單 （SBOM） 的能力，該清單可識別軟件的成分列表——包括第三方和開源組件。

SBOM 還將附有這些已識別組件的漏洞報(bào)告。這允許組織檢測可能影響軟件安全性的隱藏問題。更高級的框架還可以檢測困難的情況，例如需要查看多個(gè)連接點(diǎn)、檢查所有編譯單元并比較每個(gè)編譯單元中的所有此類標(biāo)識符。這些通常會(huì)導(dǎo)致假陽性和假陰性。

增加挑戰(zhàn)：人類經(jīng)常誤解這些情況——尤其是在依賴手動(dòng)工具和報(bào)告時(shí)。最后，一個(gè)組織在試圖完全理解規(guī)則的超集和子集、識別安全漏洞和避免死代碼時(shí)會(huì)被蒙在鼓里。另一方面，最佳實(shí)踐框架可以發(fā)現(xiàn)規(guī)則指定的內(nèi)容與檢查器發(fā)現(xiàn)的內(nèi)容之間的重疊和差距。

該模型最終通過在開發(fā)的早期階段發(fā)現(xiàn)和修復(fù)缺陷和漏洞來降低風(fēng)險(xiǎn)和節(jié)省時(shí)間。它通常使文檔自動(dòng)化并削減成本。反過來，這種增加的文檔級別改進(jìn)了治理框架并簡化了法規(guī)遵從性。通過將該解決方案集成到對安全至關(guān)重要的環(huán)境中，汽車制造商和其他公司可以獲得巨大的收益。

今天，企業(yè)級開發(fā)項(xiàng)目需要復(fù)雜的測試框架來支持和增強(qiáng)整個(gè)軟件開發(fā)生命周期——包括與其他開發(fā)自動(dòng)化工具的集成。超越 MISRA 規(guī)則執(zhí)行和基本 AppSec 的能力帶來了巨大的收益。它改善了保護(hù)，降低了成本，并使開發(fā)人員能夠?qū)Ｗ⒂谒麄冏钌瞄L的事情：構(gòu)建出色的軟件。

審核編輯：郭婷