從開源安全看汽車安全新挑戰

“汽車制造商需要依托開源軟件的靈活性和可擴展性來開發當前和未來軟件定義下的汽車。”

軟件定義汽車的大趨勢

近些年，由于車聯網、自動駕駛汽車、共享和電動（CASE）技術的進步，汽車行業走上了一條軟件定義汽車的革命性道路。汽車正加速從傳統的工業架構向智能化轉型，智能汽車已成為全球汽車產業發展的戰略方向。汽車不再僅僅扮演從A地到B地的交通工具，如今，人們可以在汽車上實現從云端傳輸音樂，撥打免提電話，查看實時交通信息和個性化的道路援助，甚至是使用高級別的自動駕駛。

汽車實現智能化、網聯化、電動化、共享化的能力背后是不斷增長的代碼量。2010年，主流車型約含1000萬行源代碼，而2016年這一數字達到約1.5億行。相比之下，一架波音787夢幻客機只包含約1400萬行源代碼。預計到2025年，汽車使用的代碼量將達到2億，并可能隨著自動駕駛系統的不斷采用而達到10億行代碼。大眾汽車表示，到2030年，軟件開發成本將占整車開發成本的一半以上。推動汽車行業技術革命的是軟件，而這些軟件大多是建立在開源代碼的核心之上的。

整車中的軟件大部分是由供應商提供的自研代碼和第三方代碼（包括專有和開源代碼）的混合使用。由于有數千萬行代碼在多達100個基于微處理器的電子控制單元（ECU）上執行，并在整個汽車上聯網，要準確了解使用了哪些開源組件，對OEM廠商來說是非常困難的。并且當每年有數千個開源漏洞不斷涌現（例：2020年新增9658個開源漏洞， 來源：Mend， 《The State of Open Source Vulnerabilities 2021》）、且這一數字在不斷增長的時候，汽車行業逐漸意識到開源軟件對于汽車的安全影響巨大。其次，軟件的許可證合規與基于EAR出口管制的合規也成為車企面臨的巨大挑戰。對于如何確保整個研發流程中的軟件供應鏈安全也是這些正在進行現代化轉型的傳統車企的噩夢。

輪子上運轉的計算機面臨的挑戰

（“Computer Running on Wheels”）

1. 軟件的復雜性大幅增加導致軟件漏洞可能成為威脅人身安全的重大因素

根據麥肯錫的報告，“在過去的十年里，汽車行業單個軟件項目的平均復雜度增長了300%。”例如，當有額外的功能需求時，OEM廠商會發現現有的軟件不能被復用，這意味著需要在一個完全不同的系統配置上進行移植。這將導致額外的工作量和潛在的兼容性問題。更加復雜的是，電子控制單元（ECU）上一直是采用孤島式的方法建造；每個單元都有自己的硬件和軟件（其中包括中間件、操作系統和服務）。除此以外，人工智能（AI）和機器學習（ML）算法也在很大程度上導致了汽車中嵌入的軟件越來越復雜。

使用開源軟件進行應用開發的情況每年都在持續增長。根據Forrester的報告，所有行業的各種規模的組織都在使用開源軟件。原因很簡單--開源降低了開發成本，加快了上市時間，并加速了創新。但與此同時，開源也通過各種途徑進入了車載應用。依靠廣泛的組件和應用軟件供應商，汽車制造商用開源組件構建解決方案并擴展開源平臺。開源軟件與自研代碼一樣都有很嚴重的安全性風險，并且開源代碼的某些特點使一些廣泛使用的組件漏洞對黑客來說非常有吸引力。開源代碼被廣泛用于幾乎所有形式的商業和內部軟件。對于黑客來說，尋找開源漏洞的投資回報率很高。一個漏洞就可以被利用來破壞成百上千的應用程序和網站。

當安全研究人員證明他們可以通過互聯網入侵吉普車以劫持其剎車和變速箱時，這便暴露了汽車軟件存在極為嚴重的安全風險。因此克萊斯勒召回了140萬輛汽車，以修復與此相關的軟件中的bug。近五年來，數百萬輛通用的汽車和卡車受到一個遠程漏洞的影響，該漏洞能夠跟蹤車輛，在高速上啟動剎車，以及完全禁用剎車。

特斯拉Model S的信息娛樂系統存在一個數年前的漏洞，可以讓攻擊者通過遠程黑客攻擊完全控制汽車。

許多汽車制造商及其軟件供應商都部署了測試工具，如靜態和動態應用程序安全測試（SAST和DAST）工具，以確定可能導致安全問題的編碼錯誤。雖然SAST和DAST在發現內部開發人員編寫的代碼中的錯誤方面很有效，但它們在識別第三方代碼中的開源漏洞方面并不能發揮很大的效果。自2004年以來，美國國家漏洞數據庫（NVD）已經披露了超過74000個漏洞，但其中只有13個是由SAST和DAST工具發現的。

這些潛在的漏洞會變成軟件中的薄弱點，但是對于汽車來說，會變成威脅汽車功能安全的重大隱患進而威脅人身安全。

2. 軟件許可證合規性成為車企亟需重視的方面

Telsa和BMW在此前都收到了消費者的投訴，要求公開使用GPL協議的代碼，兩家車企都根據GPL的條款對代碼進行了公開。對于車企來說，認識到許可證合規作為開源風險的一部分也非常重要。

大多數開源組件受大約2000多種已知開源許可證規制，許多都包含需要遵守的義務和受到不同程度的限制。只有明確了解企業使用的開源組件及其相應的許可證之后，才能有效的進行管理、遵守許可證中的權利義務。不遵守開源代碼的許可證條款會使企業面臨訴訟和知識產權受損的風險。

即使是所謂的 “寬松型”的開源許可證，通常也要求遵守再分配和在Notice文件、License文件記錄的要求。如果一個開源組件沒有可識別的許可條款也是有極大風險的，因為這意味著無法獲得軟件原始開發者的許可來使用、修改或分發該軟件。缺乏明確的權利和義務聲明，會造成使用該開源軟件的組織面臨更大的違反 “隱藏 ”條款的風險。使用開源代碼軟件的最佳實踐要求開發人員了解他們的代碼中采用了哪些組件和相關的許可證，以及他們使用開源代碼可能會產生哪些義務。

OSSRA 2021年的報告顯示，所掃描的汽車行業的代碼庫中，高達61%的代碼庫中包含許可證沖突。

3. 汽車行業的轉型中缺乏對研發流程的革新和相關專業人才匱乏

汽車新四化的大背景下，汽車行業向軟件模式的轉變推動了開發周期的變化，由V字型開發流程轉向DevOps敏捷開發進而擴展到DevSecOps，以幫助軟件團隊縮短開發周期，加速軟件迭代，更快速的交付用戶。但是從互聯網行業所經歷的DevOps發展和變革來看，針對軟件供應鏈層面的攻擊日益增多，其中針對代碼倉庫、構建、CI/CD管道、分發等過程的攻擊成為威脅軟件安全的新的隱患。這些流程層面的安全核心之一是溯源（provenance）信息，即我們是否能確保這些代碼/制品的來源可靠。

與此同時，這些技術與流程的轉型還推動了所需技能組合的全面轉型。在當前的勞動力市場上，公司面臨著吸引和保留具有軟件技能的候選人的挑戰。更為重要的是，汽車廠商正在與互聯網公司競爭，因為互聯網公司也在尋找具有同樣技能組合的候選人。另一方面，對開發者社區以及開源模式的缺乏重視，正在成為阻礙傳統車企加速軟件化和智能化轉型的攔路虎之一。

4. 產品生命周期帶來的長期維護挑戰

相比于汽車來說，手機和電腦的使用壽命可能只有幾年，但其中的應用與操作系統會收到頻繁的定期更新。但是對于汽車來講，整體的汽車架構可能已經使用了很長時間，平均使用壽命會超過10年甚至更久，所以車企及其上下游供應商需要考慮相應的支持軟件是否會因為超長的硬件生命周期而帶來風險。

比如：你如何確定使用的組件在未來會得到開源社區的支持？如果社區（或供應商）放棄了該項目，你是否準備為其提供持續支持？開源軟件的發布周期是怎樣的？與代碼庫的規模相比，該組件在過去幾年里有多少個漏洞？社區是否具有安全意識？

車企如何應對這些挑戰？

車企如何應對軟件供應鏈帶來的挑戰這是一個很大的話題，由于本文篇幅有限，先從一些較大的層面來闡釋，安勢信息將在之后的文章推送中為大家詳細解析。

1. 建立正確應用和管理開源的思維模式與組織

我國的頭部互聯網企業基本建立了較為完善的開源治理體系，但是傳統的車企對于為什么要治理開源、怎么樣正確治理開源了解甚少，所以在面臨重大開源安全事件之時應對能力不足。在世界范圍內，企業開源合規治理的一大趨勢便是建立開源項目辦公室（OSPO），OSPO的主要職能涉及安全、法務、研發等部門，在企業中協調和解決為什么使用開源、如何合法合規的使用開源、如何安全的使用開源以及把開源上升為企業的戰略。企業的法務部門應該進行人才的投入來從上到下的建立企業開源版權意識。這些對于我國傳統車企來說還有很長的路要走。但是值得欣喜的是，我們在長期的實踐中已經看到了越來越多的新興車企，由于其互聯網基因相對比較強大，已經在這方面走在了前列。

2. 建立適應新型開發模式的研發體系和流程

由V字型開發流程轉向DevOps對于傳統車企是非常巨大的轉變，其難度是不言而喻的，這其中不但包括工具鏈的選型，也包括研發、安全、運維等部門建立新型的思維模式。前文提到，流程層面的安全核心之一是溯源（provenance）信息，即我們是否能確保這些代碼/制品的來源可靠。國際頭部互聯網公司開始使用一些諸如SLSA或sigstore這類的框架或方案來在整個研發流程中保護軟件制品的完整性。另外，企業對于開源軟件選型和建立白名單等機制也對安全合規地使用開源組件大有助益。我們也看到越來越多的國內企業在探索適應企業內部研發體系的開源治理之路。

3. SBOM SBOM SBOM

用一個例子來闡述SBOM的重要性：

假設一個Tier 2正在使用一個開源組件。此時，一個漏洞被披露出來。

首先，供應商需要了解在哪些應用中使用了有漏洞的開源組件。

But HOW？

接下來，需要監控開源組件來源，以便知道新報告的漏洞。

然后，他們需要重新構建和測試代碼，以補救這個問題。

當所有這些步驟都完成后，軟件更新需要交給OEM或Tier 1，納入該實體組件的更新中，并最終對每個消費者的車輛進行更新。

對于車企來講，軟件供應鏈不單單涉及企業內部研發的供應鏈，更有明顯的上下游特點。在發生安全事件的時候迅速掌握企業研發的軟件中是否涉及相關組件（如Log4j事件）是至關重要的。從OEM到Tier 1到Tier 2都需要構建生成SBOM的能力。SBOM是開源治理的基礎，當供應商或汽車OEM不了解其產品軟件中使用的所有開源代碼時，就無法抵御針對這些開源組件的漏洞攻擊。任何利用網聯汽車技術的組織都需要檢查它用來提供這些功能的軟件生態系統，并在其安全計劃中涉及對開源代碼的識別和管理。更進一步來講，生成完整準確的SBOM離不開SCA（Software Composition Analysis, 軟件成分分析）工具。

清源CleanSource SCA

清源(CleanSource) SCA是安勢信息研發的一款擁有完全自主知識產權的軟件成分分析工具，能夠幫助企業降低和管理其應用或容器中因使用開源軟件和其他第三方代碼（軟件）引入的安全、質量與許可證合規性風險。

清源 SCA 成功通過信通院《可信開源治理工具》認證，作為國內擁有完全自主知識產權的權威SCA分析工具，可幫助企業快速構建準確的SBOM (軟件物料清單),  提供清晰的軟件成分可視性分析，降低軟件供應鏈風險，并幫助企業在軟件開發全生命周期對其進行管理。

掃描上方二維碼

一鍵試用清源(CleanSource) SCA

關于安勢信息

上海安勢信息技術有限公司成立于2021年，致力于解決軟件供應鏈中的安全和合規問題，目前已完成數千萬元天使輪融資。作為中國市場領先的軟件供應鏈安全治理工具提供商，安勢信息以SCA（軟件成分分析）產品作為切入點，圍繞DevSecOps流程，著力于從工具到流程再到組織，堅持持續創新，打造獨具特色的端到端開源治理最佳實踐。

歡迎訪問安勢信息官網www.sectrend.com.cn或發送郵件至 info@sectrend.com.cn垂詢。

參考資料：

https://www.information-age.com/open-source-security-challenges-cars-6252/

https://www.rtinsights.com/why-open-source-is-the-best-road-ahead-for-the-software-defined-car/

https://softwaretesting.news/is-open-source-software-a-cyber-security-risk-in-connected-vehicles/