由蓋世汽車、AUTOSAR組織、上海車展三方聯合主辦的SDVF2021第二屆軟件定義汽車高峰論壇暨AUTOSAR2021中國日于4月19-21日在上海舉辦，本次活動也是2021上海車展的同期活動之一，同時也是AUTOSAR組織在中國區唯一官方活動。本次會議邀請到了新思科技軟件質量與安全部門高級安全架構師楊國梁先生在本次論壇進行了題為《通過Shift-Left提高汽車軟件競爭力》的主題演講，以下是他在本次演講的主要內容：

我們公司成立于1986年主營業務是EDA，公司后來成立了一個部門叫軟件質量與安全，我屬于這個部門，我們會做軟件層面，應用層面，安全類，質量類的測試，通過研發類的工具嵌入到研發流程提高產品質量和安全性等等。

昨天的會議，感覺大家對汽車將來的發展，成本都在什么地方，都已經很清晰了。大家回想一下過去一兩年時間，新勢力廠商，傳統廠商推出的新的車型，基本上打廣告的時候或者方向就在這兩個方向上，要么是車外自動駕駛有多智能，要么就是車內對于乘車人或者開車人體驗有多好。我看過一些數據，保守估計可能三五年之內電子電器和軟件成本可能占到汽車五成以上，當然昨天我也聽到一些聲音，比較激進的說將來七成成本都會在軟件上面。

當然我們這里羅列出來的還是比較狹義的in-vehicle部分，如果把它推的更廣一點，合并到車聯網V2X，車上生態系統APP，后臺各種各樣的東西，那軟件涵蓋的范疇可能就更廣了。

再來看一下軟件競爭力怎么來提升呢？以及我們說的Shift-Left是什么意思？無非就是更快速的軟件迭代投放市場，更可靠的品質，更安全。大家可以把它理解成兩個方向，一個方向往大說可以通過虛擬化的手段把原先串聯的先做硬件開發，硬件出來之后基于此做軟件開發的工作，通過虛擬化手段變成硬件和軟件同步開發。這樣你算一下上市時間，芯片一出來，做一下聯調，測試，上市，這樣時間極大的壓縮。從大的方向說虛擬化能夠完成整體軟件開發的Shift-Left。從小一點的方向來說，每一個軟件，每一個軟件項目的迭代都是需要相應的工具在測試過程中，把你可能會發現的問題盡量的左移，這也是所謂的Shift-Left。

上面這些術語我就不講了，因為很多廠商都已經在講了，功能安全/預期功能安全/信息安全等等之間的關系。

這是從測試角度來說的所謂Shift-Left的理念。你最終定位問題的時候，可能絕大多數問題都是由于你寫代碼的時候無心之失或者水平不夠導致這個代碼不能很好的處理你的場景。這個柱狀圖就代表了主要BUG被引入的階段，可以看到在Coding和集成階段是最多的，綠色線就代表不同階段開展測試發現相應BUG所花掉的成本是多少。

我記得昨天有一位講ITO的嘉賓講到目前汽車行業的平均用人成本是20來萬，軟件人才也就2萬多人，這還是平均的，你看一下新勢力，他們大量開發人員來自互聯網，你知道互聯網的人員有多貴嗎？你再想一下，如果你讓一個這么貴的人在軟件發布之后，再花2-3天時間去研究一個本可以在寫代碼的時候順手改掉的BUG，他的總體成本是降低非常非常多的，這是Shift-Left上面方法論的介紹。

2019年我們（新思科技安全研究中心）跟SAE一起做了一個調研報告，叫做汽車工業網絡安全實踐研究，這里數據很多，不展開給大家講，只簡單說一下。總體來看，調查問到你的產品在什么階段開展質量和安全類的測試，需求設計階段19%的人在這個階段做，28%的人在研發和測試階段，更多的是在發布后的階段，早一點可能SOP之類的。還有把車輛集成到上路之后或者產品發布之后才做這個事情。當然主機廠現在做得比較多是SOP階段找一個廠商做滲透等等，大概市場都處于這樣一個階段。

匯總來講，現在安全問題的評估在產品發布過程中進行的太晚了，太晚就有我剛才說的那個問題，你發現問題打回去再進行整改，整改的成本是非常高的。

再看一下里面的數據，就目前這些車企出了安全問題之后如何改進他們的軟件，我們就看前三個安全補丁管理，滲透測試以及動態安全測試DAST。所以目前排名很靠前的這些手段其實都是在開發階段很靠后的位置才開展的。相應的在Coding階段可以做的靜態測試，軟件組成分析，安全架構分析等等，目前看來開展的非常少。大家可能會說，之后成熟了，有OTA了，出了問題隨時推送OTA來解決，但即使OTA了，本質上也是安全補丁的行為，在整個研發周期來看還是太靠后了。而在同一個報告里面，我們當時統計有37%的人開始落實OTA了，當然目前更加會更高，而且這個時候再不考慮做OTA也沒有什么競爭力可言了。

我們做了一些總結，大家都會講到21434，我們羅列了一下在21434映射到在每個不同階段開發工作需要做什么，安全工作需要做什么？白色指的開發需要做得，藍色是指的安全活動，從最早的安全計劃的下發開始做TARA，再下面指導Secure Coding，再對第三方組件進行管理，再做內部各種各樣安全測試，甚至引入第三方滲透測試，以及貫穿整個流程的安全漏洞的實時處理。我們現在看到典型的場景是OEM掐頭去尾提安全需求以及在做末端做安全測試（比如滲透），有些就組織一個團隊大量的做TARA；現在傳統廠商更像是一個組裝廠，沒有源代碼，但是新勢力現在看起來更希望全棧自研，反應速度自然會快一些。

再往后看一個數據，看一下汽車上面出現漏洞的主要原因。項目時間緊（71%）就不多說了，可以通過虛擬化shift-left等手段緩解；再往下60%和55%缺乏對安全編碼實踐的理解，意外的編碼錯誤。再往下是測試階段，占40%是使用不安全或者過時的開源軟件組件。大家看一下這些問題的種類，編碼會有什么問題？

這里講了汽車行業常見的編碼類的規范，比較熟的是MISRA，AutoSAR，26262，其他的比如說CERT，MISRA和AutoSAR有大量規則是來自于CERT，這里面有幾百條規則，用人工檢查是肯定不現實，其他的規范也類似。上面Coverity可以看到支持了下面這些規范。當汽車的智能化程度進一步提升，車聯網，人機交互更多的時候，這里羅列的其他編碼規范，比如OWASP這類在其他行業司空見慣的安全規范就會在汽車行業也越來越多的被參考。

在汽車行業還有一個比較特殊的情況，對于ECU這類嵌入式的開發，不同廠商會有自己不同的開發版和編譯器，對于白盒代碼類工具來說，如果不能準確識別編譯過程那檢查將會是很雞肋的。舉個例子，某個類型在你的系統是以16位或者32位存在的，沒有編譯過程的捕獲很可能這個都不知道，那白盒檢查出來的結果其實是更加雞肋。Coverity是目前業界支持嵌入式開發環境的最佳白盒工具，適配各類編譯器，并且對誤報率的控制業界最佳。

說到白盒工具的最佳實踐，我們可以看一下這個典型的開發流程，從寫代碼到提交到編譯到定時檢查再到發布，在這個場景下有什么位置可以做白盒測試呢？在IDE端首先可以裁減一些檢查規則，把速度快，準確度高的規則在寫代碼的第一時間就同時檢查，規避問題，檢查本身耗時控制在秒級；其次，在提交代碼時，可以通過工具配置，檢查企業自身的Top10類型的問題，比如命令注入以及Key被硬編碼等，檢查本身耗時控制在2-3分鐘級；到項目構建的時候，涉及到跨文件/跨函數/數據流的分析，時間雖然長一點，但是分析深度也會更深入一點，時間控制在十幾到幾十分鐘級；最后在發布之前做一個詳細的檢查，這樣時間更長，小時級或夜間執行。所以這都是一些取舍，你在什么階段，你的使用習慣，你能接受檢查介入到什么程度，在不同的位置要做不同的調整來適配這些白盒工具的集成。

其實在國內某新勢力廠商，幾年前就開始做這樣的實踐，當時的做法是在最后發布階段做一些測試，近兩年逐步的推移到構建檢查的位置，在每一個版本構建的時候做相應的測試。只不過當時強制程度還比較低，提供這樣的測試服務，但是不強制要求你使用。但是現在新勢力廠商的智能座艙代碼量非常大，一個安卓完整編譯本身可能就花一天時間，那更進一步往前推，推到每一個開發，每一個模塊，都會拿到相應的結果實時去查，進一步去Shift-Left。以上是靜態工具，當然工具還有各種各樣的報告，MISRA，HIS Metrics，Quality，Security等等。

剛才看到出現問題占40%是使用不安全或者過時的組件，這里指的是常見的開源組件。你的開發流程速度加快之后一定有一些前提，肯定大量復用開源現成組件效率才能提的上去。我們新思科技每年會發開源風險審計報告，各行各業用了多少開源組件，面臨什么風險，以及趨勢。這是今年剛剛發的，審下來汽車行業里面所有代碼70%是由開源構成的。如果把智能座艙加上去可能會更高，甚至后端的TSP，APP，可以參考其他行業就知道了，這里不做多解釋。

舉一個例子，你的汽車上市之后，你用到了curl7.58組件，如果它在明年發現了一個嚴重的安全漏洞，這個時候如果你有自己的ALM，PLM系統可以追溯這些組件被哪些軟件版本用到了，這些軟件版本被用到了哪些部件上，這些部件又被用到了哪些車型上，那一個完整的攻擊范圍就知道了，這樣你就可以精準推送你的軟件補丁。

另外，在21434中還規定了，需要進行Fuzz（模糊測試）。我們羅列了一下在車輛上會需要模糊測試的各種協議，接口。目前典型的做法是OEM在最后的階段進行一下Fuzz測試；然而，根據Shift-left的方法，Fuzz也是需要進行調整并適配到開發過程的更早階段。

除了以上提到的各種測試方法，還有更多的需要在實踐21434過程中需要做的安全測試，然而所有測試類型都有自己Shift-Left的方法與實踐。

匯總一下，我們剛才講到V字模型上現階段做這開發的時候需要考慮哪些安全活動以及流程。現在再看一下21434里面對于安全活動流程的圖示，其實是一個圓圈型的，對于右下角的尾巴End-Of-Life, 仔細想一下車型有退市，軟件有退市嗎？除非軟件不維護了，不然的話很有可能上一個車型軟件版本迭代用到下一個車型上，所以它是一直不停地迭代的過程。

我們剛才講的某些實踐其實內容已經是DevSecOps的范疇，把三者放在一起看就讓我們想到，21434模型會不會只是V字模型向DevSecOps過渡的中間產物？將來一定是不斷快速迭代和快速演進的過程。

這里我找到一個案例，這是美國國防部使用DevSecOps的方法，在F16上部署了kubernetes，開發周期3-8個月縮短到一周，37個項目總開發時間節省超過100年；這是重武器，應該比汽車開發慢多了吧，但是姑且可以用DevSecOps的方法來完成開發。

總結一下，我們目前所有針對每一個開發周期需要用到的工具層面，我們從軟件架構角度來講，它的構成一般是依托于開源組件，上面寫一些專用代碼，構建業務需要的框架，在上面跑你的業務邏輯，通過WebUI或API等服務接口對外提供服務。對于不同階段用什么測試手段呢？我們有Coverity，在代碼開發時檢查和修復安全漏洞以及質量問題。BlackDuck軟件成分分析，檢測和管理開源以及第三方組件風險。Seeker，交互式安全測試，在QA的同時自動完成安全測試。Defensics與Tinfoil，模糊測試與動態安全測試。

講到這兒為止其實都是每個具體項目里可能都會用到的質量/安全測試工具以及方法，那剛才說的通過虛擬化把軟件和硬件開發工作同時來做，這個怎么回事兒呢？跟大家簡單講一下，還是這個V字模型，從下到上可以理解為從半導體廠商進一步到Tier1基于芯片做一系列的開發，再往上給OEM。我們其實可以和半導體芯片廠商合作，把芯片規格通過虛擬化的手段VDK交付給 Tier1，然后Tier1基于VDK開發ECU，再交付給OEM，OEM第一時間開始做各種應用層的工作。對于Sil和pil階段，我們還有ECU虛擬化工具，Silver。大家知道SiL和PiL階段的代碼跟上HiL的還是有一定的區別，而區別某種程度上就意味著風險，VDK能夠以vHiL的形式填補空缺，解決HiL時間緊張，資源緊張的問題，vHiL上運行的代碼已經非常接近真實HiL環境了。

VDK可以把芯片里面各種接口全部模擬了，模擬到哪一層都是可以的，雖然性能相比真實芯片環境會有一定的損耗，但是對于功能測試來講已經足夠了。

從汽車軟硬件層級角度來看，從上面SW階段可以用SILVER工具對它進行虛擬仿真，然后到直接跟硬件打交道階段VDK把它整個虛擬掉，再往下是Saber這是另外一個針對物理層信號的虛擬化工具，這些工具都可以跟其他常見的汽車行業用到的工具做聯合仿真。

這里有一個案例，英飛凌在2023年才會推出他的下一代自動駕駛芯片AURIX 3G MCU系列，然而現在已經把這個芯片規格用VDK虛擬，交給Tier1，Tier1基于此設計軟件并交給知名的國際OEM大廠，現在該OEM已經基于此在做整體方案的集成了，這樣做可以很簡單理解它的好處，你不用等芯片出來再做軟件部分的開發，把整個周期Shift-Left提前了2-3年。

最后再總結一下，這是軟件安全層面的我們這個事業部一直比較低調，但是已經連續三年在Gartner排名上面處于領導者的位置，如果大家感興趣也可以后續交流一下。這里也有我的微信和我們事業部的二維碼，大家可以掃描添加，如果感興趣也可以到外面展臺進一步交流。

返回第一電動網首頁 >