导语：随着汽车软件在新能源和智能化领域不断取得成功，迈入“软件定义汽车”时代已成为行业共识。然而，汽车从传统交通工具转变为可移动的智能终端并承载各类创新应用场景的同时，网络安全形势却愈发严峻。

基于此背景，近日，固源科技在 AutoSec 7周年暨中国汽车网络安全与数据安全合规2023峰会发表主题为《软件定义汽车下，如何保障车辆网络安全与合规性》议题演讲，从车联网安全合规和车企实际痛点出发做部分经验总结。

就像图中的2辆车，左边是2017年出厂的铃木维特拉，右边是一辆更近期的2022年款车型。两辆车的外观、内饰、行驶里程不同之外，这两辆车的主要区别在于增加了一堆新系统。在过去的5年中，维特拉车系的功能得到了发展，以满足今天的用户市场和安全需求。成为了一辆混合动力电动车，配备了先进的驾驶辅助系统（ADAS）、内置复杂的信息娱乐系统（而老款的车并没有这些功能...）等等！

随着每一次新的功能增加和版本迭代，都会带来更多的软件。有人说我们基本上是在开着电脑行驶在路上，而我们都知道，像自动驾驶和无人驾驶等迟早会取代我们来开车！

我认为这是一个非常切近日常的例子，就像十年前美国企业家-马克安德森的说法，“软件正在吞噬这个世界”，不管是图片中的这辆车，还是现在医疗行业成像设备或工厂生产线上的机械臂，软件正在支撑我们身边的创新和发展。

但是，随着更多的软件和复杂的功能实现随之而来的是网络安全风险，而随着更多的风险，就有了监管措施，帮助我们将控制措施放置在正确的位置，以保护用户的生命安全。因为最终网络安全是安全的一部分。这导致了产品安全作为一种专门的学科的出现，致力于确保我们周围的软件驱动设备是安全和可靠的，这也是Cybellum公司成立的实质原因，也是固源科技的使命之一。

对于汽车制造商和OEM厂商来说，日益激烈增长的市场环境面临严峻的挑战。

1、将新产品推向市场的压力越来越大

2、不同的行业和产品的功能模块间需要更多的研发投入，通过更多的软件来定义设备功能。

3、同时也面临更严格的监管机构监管要求。

对于企业来说，时间成本下面临的挑战也越来越严峻，

1、产品风险需要更长的补救时间

2、产品发布面临延期交付和召回风险

3、昂贵的监管合规处罚

4、同样严重的安全风险，造成的用户财产人身安全风险，甚至进一步造成公司名誉损失受益人利益受损。

随着近几年ISO/SAE 21434、WP.29 R155等体系和法规的发布，看的出来外部监管力度逐渐加强，要求确保汽车生产的全生命周期配备相关的安全活动，对汽车信息安全全生命周期做管控。最近大家也了解到工业和信息化部正在公开征求《汽车整车信息安全技术要求》等四项强制性国家标准的意见，这说明由以往的建议参考性规范逐步设定为强制要求。

车联网网络安全和传统网络安全一样是一场不断变化的动态斗争，车联网系统通常面临着诸多安全风险，主要集中在引入新的供应商、新的零部件、软件更新和软件漏洞等方面。为了保障车联网系统的网络安全，我们需要采取一系列措施，如加强网络安全意识、采用先进的安全技术、定期进行安全评估和漏洞扫描等。同时，我们也需要动态持续监测漏洞和修复更新过程的博弈，及时跟进新的安全威胁和漏洞，采取应对措施，保障车联网系统的网络安全和稳定。并持续关注车联网安全领域的最新动态和技术，为公司的发展和客户的利益不断努力。

随着技术的不断进步，越来越多的设备正在变得以软件定义为主，这意味着这些设备的主要功能和控制逻辑都由软件来实现。这种趋势在一定程度上提高了设备的可编程性和灵活性，但也带来了一些安全风险，主要包括以下几点：

代码量剧增：据麦肯锡权威报告预测：“仅汽车领域的代码行数预计从 1.5 亿增长到 3 亿，预计在 2023 年达到这个规模。”不安全的编码问题将带来更多的代码层安全风险

供应链风险：目前全球内各个安全研究组织和个人，着手对汽车车联网安全领域进行研究和测试并发布到互联网，具有代表性的漏洞案例如Log4j、Ripple20等。从研究和修复的角度来看，关键设备软件漏洞的发现越来越多，供应链成为了一个巨大的风险。这是因为现代设备的软件系统通常由多个组件和库构成，这些组件和库来自不同的供应商，因此设备的安全性和稳定性不仅取决于自身的软件系统，也取决于供应链中的其他组件和库的安全性。

各行各业都引入了新的网络安全法规：随着车联网的普及，网络安全问题也成为了关注焦点，相关部门出台了一系列法规，像ISO 26262 、ISO/SAE 21434、ISO/SAE 21434、WP.29  R155等。要求车联网企业加强数据保护、网络安全等方面的措施，确保用户信息安全。

业务发布受阻：产品上市时间正在受到影响，安全性面临与开发同样的巨大压。据有关安全情报分析车联网领域“高严重性漏洞现在需要近 250 天才能得到解决。”车联网企业往往需要全方面加强数据保护、网络安全等方面的措施，确保用户信息安全，同时要加强技术研发，提升车联网产品的安全性和可靠性，以满足市场需求和用户期望。

2020-06-16，是否还有人记得这个日期？大家可能还记得几年前公开宣布的 Ripple20 漏洞集合。以色列一家安全公司发现由美国Trek 公司开发的 TCP/IP 通信堆栈中的一组漏洞，该堆栈被用于数百万个嵌入式设备 - 从医疗设备到工业设备、消费电子设备和车辆，通过这个漏洞可能导致设备被远程攻击，造成拒绝服务甚至是命令执行获权限。

这里我并不是来分享这个漏洞的一些情况，而是通过这个漏洞我们看到了一些内部应急的现象。

在 Ripple20 的消息发布后，一家 OEM 的研究人员开始进行内部分析，以了解 Ripple20 可能带来的潜在风险，并映射到内部可能受其影响的车辆和组件。作为调查分析的一部分，OEM侧发送电子邮件给相关供应商，询问他们的组件是否受到影响以及如何受到影响。

在 Cybellum 的一次合作中，我们瞥见了这封电子邮件。它基本上是一封服务级别协议类型的电子邮件，要求在某个时间范围（SLA）内回答问题，如果需要的话并在某些天内提供一个缓解计划。我们了解到，供应商的安全团队正在努力寻求答案（OEM 也是如此）。他们试图接触负责相关产品的开发团队，但该团队已经被解散，这在开发计划结束后通常是经常发生的情况。因此，供应商的产品安全团队不得不自己进行一些研究，以尝试弄清楚他们是否受到影响以及如何受到影响。

就像看到的，这个漏洞的过程非常复杂和漫长，涉及跨外部和许多人，并在为该特定OEM工作的多个供应商进行同步调查。从最初的新闻到最终结论，整个过程耗时5-6周！

那么我们从中看到汽车供应链面临着许多挑战，包括：

1、对组件/产品软件关联资产的可见度有限，缺乏相关的产品安全数据存储库，限制了在开发和上路过程中识别受影响资产的能力。如爆发新的漏洞在供应商提供的固件中我们不容易很直观的去了解和评估受影响风险面。

2、因为部分漏洞利用比较复杂，在无法对漏洞进行利用分析复测的同时，可能无法及时优先考虑最重要的风险。

3、由于跨外部沟通和细节交流，在流程不连贯、缺乏数据支持和沟通不充分，内部协作和供应链协作不足的情况时有发生。

4、由于流程效率低下且需要大量人力，导致解决问题的时间过长。

事后分析得出了这些“教训”-传统的产品安全方式不适用于“软件定义车辆时代”。

1、以往要使用许多工具一个用于软件组合，另一个用于威胁情报收集，其他用于报告，另一个用于事件分析... 跨平台导致效率低下。

2、只在单个组件级别-观点有限，车辆是由多个组件和子系统组成的复杂系统-需要全面考虑。

3、传统方法侧重于在某个时间点风险检测，而不是在整个设备生命周期中持续检测和管理风险。

4、最重要的是，它依赖于高度手动的人工参与，使用不适合任务且无法应对汽车生态系统复杂性的通用工具，效果往往不会特别流畅。

另一家一级供应商如何在Cybellum的帮助下解决这些挑战。

1、企业目标：

（1）通过在整个产品生命周期中整合集成网络安全，成为安全可靠的汽车产品领导者。

（2）根据其日益增长的功能来扩展其产品安全计划，在与全球网络安全法规，特别是WP29法规和ISO 21434标准保持一致的同时，尽可能高效地缩短开发产品和解决安全问题所需的时间，以应对SOP后安全问题。

（3）确保建立符合WP.29 R155法规的认证CSMS，同时确保客户能够顺利获得车型批准。

2、主要挑战：

（1）开发项目数量增加

（2）产品软件复杂性增加（一些项目具有数千个包-开源软件、COTS（现成商业模块）和专有代码）

（3）手动流程减缓了工作速度（跟踪、分析、报告）

（4）建立符合WP.29 R155法规的认证CSMS、整个组织缺乏全面管理/治理。

在项目交付过程中Cybellum产品安全平台被部署为一个集中的解决方案，用于在整个产品生命周期中进行产品安全操作。

Cybellum 产品安全评估能够在整个产品设计和开发阶段以及基于任务关键型微控制器的组件中自动检测二进制（在供应商渠道中往往不会提供组件的源代码给到OEM厂商）代码中的网络风险，不需要源代码。

通过Cybellum揭示了所有产品特征（硬件架构、操作系统、SBOM、许可证、配置、控制流、API 等），支持 SBOM 管理和供应链监督、自动化漏洞管理以及法规和政策合规性。产品安全评估分析专有代码（即非开源软件），揭示可能引入重大网络风险的零日漏洞，例如远程代码执行或 DoS 攻击。

它验证是否符合软件许可和安全政策，包括行业法规和标准、安全编码最佳实践（例如 CERT C/MISRA）。

密码学相关问题（例如使用弱散列函数、代码中的私钥）、侵犯隐私和更多。它包括用于对安全、许可和合规操作进行管理监督的治理仪表板，从而能够持续降低风险并改善组织的安全状况。产品安全评估部署在本地，无需联网即可在内网中不出网使用。

可与的企业的 ALM/PLM、CI/CD 系统、资产管理、漏洞处理流程解决方案等无缝集成。

通过对底层设备软件组件的完全可见性和验证，Cybellum 促进了供应链监督、开发过程中的安全性和合规性验证，以及快速影响评估和生产后事件响应

网络安全管理体系（CSMS）可由Cybellum平台生成，及时与OEM厂商共享，作为车辆型式认证（VTA）过程的一部分结果输入。

满足ISO/SAE 21434的V字模型部分功能实现，在整车生命周期中做风险管理和控制，可以在以下三个阶段实现：

1、概念和设计阶段：

• 使用虚拟SBOM评估软件组件的安全风险
• 使用“数字孪生”能力对复杂产品进行可能的架构和风险评估
• 将复杂系统表示为系统、产品和组件的层次结构。
• 使用内置功能评估潜在风险。

2、开发阶段：

• 在每个项目的CI/CD流水线中自动创建SBOM。
• 作为CI/CD流水线的一部分，基于漏洞分析自动识别并分类漏洞。
• 使用Cybellum的多版本评估跟踪软件组件版本更改，并自动跟踪这些更改对网络安全的影响，对里程碑发布中的项目软件修订进行评估。
• 团队正在使用该平台为OEM生成详细的项目评估报告。
• 使用Cybellum策略验证引擎自动验证一级供应商自己的安全最佳实践和OEM安全要求（包括诸如操作系统硬化之类的内容-例如“内核必须有这样和那样的设置，而你的配置不是这样的”）。

3、上线生产后

• 每个项目都持续监控新的漏洞。
• 使用平台进行自动影响评估和安全事件调查。
• 自动为OEM生成进度报告。

产品安全平台是一种根本性的新方法，解决了当今实践中面临的最大问题-缺乏网络安全的统一流程、缺乏自动化和开发过程的集成。Cybellum 专注为汽车行业构建产品安全平台和解决方案。