从开源安全看汽车安全新挑战_车载开源法律风险-CSDN博客

本文链接：https://blog.csdn.net/sectrend/article/details/128534603

“汽车制造商需要依托开源软件的灵活性和可扩展性来开发当前和未来软件定义下的汽车。”

软件定义汽车的大趋势

近些年，由于车联网、自动驾驶汽车、共享和电动（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, 软件成分分析）工具。

参考资料：

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/