共计 4294 个字符，预计需要花费 11 分钟才能阅读完成。
软件定义汽车的大趋势
近些年，因为车联网、主动驾驶汽车、共享和电动（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, 软件成分剖析）工具。
参考资料：
[1]https://www.rtinsights.com/wh…
[2]https://www.rtinsights.com/wh…
[3]https://softwaretesting.news/…