新思科技杨国梁：通过Shift-Left提高汽车软件竞争力

由盖世汽车、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年。

新思科技