開發(fā)一款安全性良好的軟件是困難的，它需要專業(yè)知識的積累以及對常見編程缺陷和規(guī)則的了解，例如檢查輸入范圍、管理內(nèi)存分配和回收、尋址字符串格式、避免懸空指針等等。通常情況下，編寫安全代碼與開發(fā)人員編寫“流暢”代碼的自然愿望形成了對比，開發(fā)人員更希望將編寫代碼的精力集中在正確的業(yè)務(wù)邏輯上，而非集中于保證編寫的每一行代碼是否安全上。

在日常實(shí)踐中，大多數(shù)軟件的漏洞源于一小部分編碼錯(cuò)誤，經(jīng)過多年的開發(fā)實(shí)踐均能得到改善。平均來看，每1000行代碼中仍然存在40-70個(gè)錯(cuò)誤，這些錯(cuò)誤中的一部分將導(dǎo)致可利用的安全問題，而這也是行業(yè)中普遍存在的問題。但是對于部署了數(shù)千萬行代碼的產(chǎn)品而言，這可能很快就會(huì)導(dǎo)致系統(tǒng)安全性受損。

漏洞通常被定義為 “一個(gè)可以被不法分子利用的缺陷”。如果把漏洞透明化的概念引入軟件世界就很容易受到啟發(fā)，比如在汽車產(chǎn)品本身安全的情況下，產(chǎn)品被部署到在設(shè)計(jì)上就不安全的環(huán)境中使用會(huì)發(fā)生什么情況呢？這將導(dǎo)致產(chǎn)品安全難以得到保證。作為制造商，你無法控制你的產(chǎn)品在哪里被使用、如何被使用、它們將與哪些系統(tǒng)連接、誰在使用它們、或者誰可能獲得對它們的訪問，無論是有意還是惡意的。在這種環(huán)境下，管理代碼中的漏洞這一任務(wù)就變得至關(guān)重要。

那么汽車行業(yè)的安全挑戰(zhàn)都有哪些呢？

·開發(fā)慣例

汽車軟件開發(fā)大約已有50年的歷史，汽車的生命周期至少是12年，汽車平臺每5-7年就會(huì)更換一次，但大部分遺留的硬件和軟件都是從一個(gè)平臺轉(zhuǎn)移到另一個(gè)平臺。汽車開發(fā)人員主要使用C和C++作為開發(fā)語言，雖然這兩種語言靈活性很高，但是它們從設(shè)計(jì)上就不安全，也沒有提供任何可以防止將安全漏洞引入系統(tǒng)的保護(hù)措施。盡管通過引入編碼標(biāo)準(zhǔn)(如MISRA-C)已經(jīng)做了一些工作來確保編碼的安全性，但這些指導(dǎo)方針很難強(qiáng)制執(zhí)行，并且在一些富操作系統(tǒng)中遵守這些指導(dǎo)方針是不現(xiàn)實(shí)的。

·供應(yīng)鏈

汽車行業(yè)的分布式開發(fā)實(shí)踐是獨(dú)特的，它有多層的供應(yīng)商，每個(gè)供應(yīng)商都為更高層次的系統(tǒng)集成提供軟件集成。一輛汽車可能有50-150個(gè)不同的計(jì)算單元，由10-20個(gè)不同的供應(yīng)商提供。而供應(yīng)商提供的這50-150個(gè)不同的計(jì)算單元中，每個(gè)組件可能又有多個(gè)CPU、幾十個(gè)外圍硬件組件和大量的軟件包。有了這么多第三方代碼，且考慮到OEM實(shí)際上只負(fù)責(zé)實(shí)際編碼的一小部分，這也就使得軟件的不透明性成為常態(tài)，令制造商很難評估其安全性。

· 開源軟件(OSS)

面對日益增長的客戶需求，更快、更靈活的開發(fā)模式驅(qū)動(dòng)成為眾望所歸，原始設(shè)備制造商和供應(yīng)商越來越多地引入開源軟件，并整合了大量的開源庫。這種對開源軟件的依賴導(dǎo)致了另一個(gè)安全問題的惡化。

那么面對這些問題，如何監(jiān)管才有效呢？

近幾年來，汽車行業(yè)內(nèi)相繼發(fā)布了多項(xiàng)標(biāo)準(zhǔn)，ISO/SAE21434是SAE J3061的延伸、聯(lián)合國歐洲經(jīng)濟(jì)委員會(huì)（UNECE）、WP.29車輛法規(guī)協(xié)調(diào)工作小組也制定了法規(guī)以滿足OEM和制造商的需求：當(dāng)涉及到汽車網(wǎng)絡(luò)安全時(shí)，OEM和制造商必須滿足法規(guī)要求后才能頒發(fā)汽車型號認(rèn)證，否則汽車就不能出售。ISO標(biāo)準(zhǔn)和WP.29的工作都包括一項(xiàng)指令，即在汽車生命周期中持續(xù)管理和監(jiān)測漏洞。

擁有一個(gè)明確和規(guī)范的流程是推動(dòng)車輛安全狀況改善的一大步。但僅有流程是不夠的，仍需要汽車行業(yè)自身進(jìn)行安全數(shù)字化轉(zhuǎn)型。在軟件日益復(fù)雜的現(xiàn)實(shí)中，規(guī)?；芾砺┒磶砹硕喾N挑戰(zhàn)。

·可見性

按照傳統(tǒng)來講，汽車工業(yè)是根據(jù)功能部件的概念來進(jìn)行組織的。因此，原始設(shè)備制造商已經(jīng)優(yōu)化了內(nèi)部資產(chǎn)管理系統(tǒng)來管理供應(yīng)商的零件，但這些零件的內(nèi)部軟件組成卻很少可見。這些系統(tǒng)在管理硬件組件(以及機(jī)械部件)級別的復(fù)雜供應(yīng)鏈分配方面非常出色，但在軟件級別的問題上卻收效甚微。通常情況下，產(chǎn)品安全團(tuán)隊(duì)面臨的最大挑戰(zhàn)是需要深入了解系統(tǒng)上的漏洞和威脅，而它們很少有內(nèi)部可見性。

·相關(guān)性

另一個(gè)挑戰(zhàn)是 "去除噪音"。NVD是軟件漏洞的主要來源，每年有超過16,000個(gè)CVE，其中90%以上在汽車行業(yè)沒有應(yīng)用。但如果沒有先進(jìn)的軟件將數(shù)據(jù)與實(shí)際的車輛聯(lián)系起來，安全團(tuán)隊(duì)就會(huì)花費(fèi)相當(dāng)多的時(shí)間來處理成千上萬的漏洞，最終很有可能面對的是大部分漏洞和當(dāng)前產(chǎn)品不相關(guān)的窘境。

·可追溯性

在一個(gè)組件或開發(fā)程序中發(fā)現(xiàn)的漏洞很可能與其他組件或開發(fā)程序有關(guān)，但由于團(tuán)隊(duì)可能是在孤軍奮戰(zhàn)，無法在多個(gè)項(xiàng)目之間協(xié)調(diào)程序，對于安全同事而言很難了解其整個(gè)開發(fā)范圍。

·可操作性

安全團(tuán)隊(duì)的一項(xiàng)關(guān)鍵任務(wù)是管理開發(fā)工作，以消除漏洞并不斷改進(jìn)系統(tǒng)的狀態(tài)。對于不同的個(gè)人和完全不同的組織結(jié)構(gòu)，如果不以有組織和可擴(kuò)展的方式進(jìn)行管理，管理難度會(huì)很大。

以上談到的所有挑戰(zhàn)都強(qiáng)調(diào)了汽車行業(yè)安全數(shù)字化轉(zhuǎn)型的必要性。從業(yè)者們逐漸認(rèn)識到“人+機(jī)器”的方法對于保持安全所需的規(guī)模的重要性，同時(shí)也認(rèn)識到了引入自動(dòng)化技術(shù)實(shí)施標(biāo)準(zhǔn)和法規(guī)要求的信息安全活動(dòng)對于推動(dòng)行業(yè)安全數(shù)字化發(fā)展的利害。

經(jīng)緯恒潤針對ISO/SAE 21434、WP.29 R155等法規(guī)進(jìn)行了深入研究，結(jié)合多年功能安全、信息安全經(jīng)驗(yàn)，可以為客戶提供信息安全全流程解決方案。依托自動(dòng)化工具和咨詢服務(wù)，助力客戶建立完備的信息安全流程體系，在信息安全設(shè)計(jì)、軟件開發(fā)、硬件設(shè)計(jì)、漏洞掃描、測試驗(yàn)證方面為客戶賦能，保證軟件源碼級、部件級以及整車層面的安全。