“新思科技杨国梁：通过Shift”

由格斯坦汽车、汽车公司、上海车展三方共同主办的sdvf2021第二届软件定义汽车峰会论坛暨autosar2021中国将于4月19-21日在上海举行，此次活动也将是2021上海车展的同步活动 在这次会议上，邀请了新思科技软件质量和安全门高级安全设计师杨国梁先生在本次论坛上发表了 shift-left [/S2// ]

本公司是1986年以eda为中心业务设立的。 企业设立了软件质量和安全这个部门。 我属于这个部门。 进行软件水平、应用水平、安全系统、质量系统的测试，将研发系统的工具纳入研发流程中，提高产品的质量和安全性。

在昨天的会议上，大家对于汽车未来的快速发展，感觉价格在哪里已经很清楚了。 回想一下过去的一两年里，新势力制造商、以前流传下来的制造商推出的新车种。 基本上，发广告的时候和方向就在这两个方向上。 车外的自动驾驶有多智能，或者车内对乘车者和驾驶员来说体验有多好。 我看过一点数据，保守估计，三五年内电子设备和软件的价格可能占汽车的五成以上。 当然昨天也听到了一点声音，但激进地说将来7成的价格会在软件上。

当然这里罗列的还是狭义的in-vehicle部分，如果把它推得更广，整合成远程信息技术v2x、车上生态系统APP、后台的各种东西，那个软件涵盖的范畴可能会更广。

如何提高软件的竞争力呢？ 而且我们说的shift-left是什么意思？ 无非是更迅速的软件反复投入，更可靠的质量，更安全。 这可以理解为两个方向。 一个方向是，通过虚拟化的手段，将原来连接的先进行硬件开发，然后基于硬件开发的事业，通过虚拟化的手段变为硬件和软件的同时开发 请这样计算一下发售时间。 芯片出来后，请尝试调配、测试、发售。 这样时间被大幅压缩。 从大的方向来说，虚拟化是能够完成整体软件开发的左撇子。 从几个方向来说，所有软件、所有软件项目的迭代都需要适当的工具来尽量将测试中可能发现的问题左移。 这也被称为左偏移。

正如许多制造商已经说过的那样，这些术语不是功能安全/预期的功能安全/新闻安全等关系。

这是从测试的角度说的，也就是所谓的shift-left的理念。 在你最终确定问题的时候，大多数问题可能是因为你在写代码的时候无心，或者水平不够，那个代码不能很好地解决你的场景。 该条形图表示引入主要错误的阶段，在coding和集成阶段最多。 绿线表示在各个阶段进行测试，发现相应的错误所花费的价格。

我记得昨天有一位ito嘉宾说现在汽车领域的平均使用者价格是20多万人，软件人才也是2万多人，这还算平均。 看看新势力。 他们有大量的开发者来自互联网。 你知道网络人员有多高吗？ 请再考虑一下。 在软件发布到这么贵的人身上之后，如果花2-3天研究写代码时应该很容易修好的bug，他的整体价格就会非常低。 这是shift-left上面的做法论的介绍。

2019年，我们(新思科技安全研究中心)和sae一起做了一份名为汽车产业网络安全实践研究的调查报告。 因为这里数据很多，所以不是和大家说，而是简单地说。 从整体来看，调查询问你公司的产品在哪个阶段实施质量和安全类测试，设计阶段的19%的人在这个阶段做，28%的人在研发和测试阶段，越来越多的是发布后的阶段，早在sop等的 另外，将车辆合并到道路上后，或者产品发布后进行该事件。 当然，主机厂目前在sop阶段寻找制造商进行渗透等，大致的市场大多处于这样的阶段。

总而言之，现在安全问题的判断在产品发布中进行得太晚了，太晚了有我刚才说的问题。 请在发现问题之后进行修改。 修改的价格非常高。

让我们来看看里面的数据。 现在，让我们来看看前三个安全补丁管理、渗透测试和动态安全测试dast，了解这些汽车企业在出现安全问题后如何改进他们的软件。 因此，这些目前排名靠前的手段实际上在开发阶段处于低位。 在编码阶段能够相应地进行的静态测试、软件结构的分解、安全体系结构的分解等，目前看来非常少。 后来成熟了，有了ota，出了问题随时可能会有人说推ota来应对，但是即使ota了，本质上也是安全补丁的行为，从整个研发周期来看还是落后了一步。 在同一份报告中，我们的统计显示37%的人开始运行ota。 当然，现在会更贵。 而且，这个时候，就算不考虑做ota也不能说没有竞争力。

总结了一下，大家谈谈21434。 在21434中，我们列举了各个阶段开发业务需要做什么，安全业务需要做什么。 白色是需要开发的，蓝色是安全活动，从最初的安全计划分发开始，以tara为指导，指导安全编码，管理第三方组件，进行内部各种安全测试，引入第三方渗透测试，然后是易普 我们现在看到一个典型的场景，oem绞尽脑汁提出安全诉求，或者在基层进行安全测试(比如渗透)，有些还组织团队大量做tara； 传说现在制造商像组装工厂，没有源代码，但新势力现在看起来似乎希望全栈自研，反应速度自然会快一些。

让我们再来看看另一个数据，看看汽车上出现漏洞的首要原因。 项目时间紧( 71%不多说，但可以通过虚拟化shift-left等手段缓解的更低的60%和55%对安全编码实践缺乏了解，是意外的编码错误。 此外，在测试阶段，40%的客户采用了不安全或过时的开源软件组件。 各位，请看这些问题的种类。 编码有什么问题？

在此，对汽车领域常见的编码系统的规格进行了说明。 众所周知的是misra、autosar和26262。 例如，cert、misra和autosar还有很多来自cert的规则。 这里面有几百条规则，人工检查是不现实的。 其他规格也一样。 可以看到上面的coverity支持以下规范: 随着汽车智能化的进一步发展，远程信息技术、人机交互越来越多，这里罗列的其他编码规范，例如owasp等其他领域的司空所熟悉的安全规范在汽车领域也变得越来越值得参考

在汽车领域还有另一种特殊情况。 像ecu这样的嵌入式开发，不同的制造商有自己的开发版和编译器。 对于白盒代码类工具，如果不能准确识别编译过程，则检查起来很困难。 例如，一种类型在你的系统中以16位或32位存在，没有编译过程的捕获很可能不知道这个，其白盒检测的结果实际上更鸡肋。 coverity是业界最好的支持嵌入式开发环境的白盒工具，适用于各种编译器，同时也是业界最好的错误报告率管理工具。

要说白盒工具的最佳实践，让我们来看看这个典型的开发过程。 从编写代码到提交，从编译到定时检查到发布，这个场景中可以进行白盒测试的地方是什么呢？ ide方面首先可以减少一些检查规则，在编写代码的第一时间检查速度快、精度高的规则，避免问题，将检查本身需要时间控制在秒的水平上，其次，在提交代码时，通过工具的配置，公司自身的top 例如，命令注入和key被硬编码等，检查本身需要时间，可以控制在2-3分钟的水平上。 到项目的建立，都涉及到文件间/函数间/数据流间的分解，虽然时间有点长，但是分解深度也会更深，时间会控制在十几分钟到几十分钟级别； 最后在发布前进行详细检查。 这将在时间级别或夜间执行。 所以，这是一点取舍，你在什么阶段，你的招聘习性，你接受检查能介入到什么程度，要根据位置进行不同的调整，以适应这些白盒工具的整合。

其实在国内某新势力制造商，几年前就在做这样的实践。 当时的方法在最终发布阶段进行了一些测试，在近两年内逐步过渡到构建检查位置，并在构建各个版本时进行了相应的测试。 只是，当时学习制度还很低，提供这样的测试服务，但没有强制招聘。 但是，目前新势力制造商智能座舱的代码量非常大，安卓要完善编译本身可能需要一天的时间。 它会更进一步，推送到所有的开发，所有的模块，得到合适的结果，实时调查，再去shift-left。 上面的是静态的工具。 当然，工具有各种各样的报告。 misra、his公制、质量、安全性等。

发现40%的问题是不安全或使用了过时的组件。 这里指的是常见的开源组件。 你的开发过程加速后，肯定有几个前提。 只有大量重复使用开源的现成组件，效率才能提高。 我们的新思科技每年都会发布开源风险评估报告，各行各业使用多少开源组件，面临着怎样的风险，面临着趋势。 这是今年刚公布的，经过审查，汽车领域70%的代码是开源的。 如果增加智能客舱的话可能会更贵。 即使是后端的tsp、app，只要参考其他领域就知道了，但在这里不多做说明。

例如，你的汽车上市后，你用了curl7.58组件。 如果它明年发现了重大的安全漏洞，这时如果你有自己的alm，plm系统会把这些组件用于那些软件版本，这些软件版本用于那些部件

21434还规定，需要fuzz (模糊测试)。 本文尝试排列了车辆需要模糊测试的各种协议、接口。 目前典型的方法是oem在最后阶段进行下一次fuzz测试； 但是，根据shift-left的做法，fuzz也需要调整，是比需要适合开发流程更早的阶段。

除了上述各种测试方法外，在实践21434的过程中需要的安全性测试也在增加，但所有测试类型都有自己的shift-left方法和实践。

综上所述，v字型模型在现阶段进行该开发时，需要考虑它们的安全活动和流程。 现在，我们来看看21434中的安全活动流程图。 其实是圆形的。 请仔细想想右下角的尾巴“结束生命”。 车型有退市，软件有退市吗？ 除非软件经过维护，否则上一车型的软件版本很可能会重复用于下一车型，所以那是一个一直在重复的过程。

在我刚才提到的实践中，其实文案已经属于devsecops的范畴，总结三个可以认为，21434模型是从v形模型向devsecops迁移的中间产物。 未来一定是一个快速迭代和快速发展的过程。

我在这里找到了例子。 这是美国国防部采用devsecops，f16部署kubernetes，开发周期3-8个月缩短为一周，节省了37个项目的总开发时间100多年。 这是重型武器，虽然比汽车开发慢得多，但总之可以用devsecops的方法完成开发。

总的来说，我们现在正在比较所有开发周期所需的工具水平。 我们从软件架构的角度来说，其结构通常依赖开源组件，在上面写一点专用代码，构建业务所需的框架，在上面运行你的业务逻辑，成为webui和api 对不同阶段使用什么样的测试手段？ 具有在代码开发时检查和修正安全漏洞和质量问题的coverity。 blackduck软件成分的分解，开源和第三方组件风险的检测和管理。 seeker，交互式安全测试，在qa中，然后自动完成安全测试。 defensics和tinfoil，模糊测试和动态安全性测试。

至此，我们介绍了实际上各种具体项目中可能使用的质量/安全测试工具和方法，那么我们说通过虚拟化实际进行软件和硬件的开发并这样做怎么样？ 简单跟大家解释一下，还是可以理解为这个v形模型，从下往上从半导体制造商再到tier1都是在芯片基础上进行了一系列的开发，从上到下给了oem。 我们实际上可以与半导体芯片制造商合作，通过虚拟化手段vdk将芯片规格交付给第1层，然后第1层基于vdk开发ecu，交付给oem。 oem最初开始了各种APP应用层的业务。 在sil和pil阶段，还有ecu虚拟化工具silver。 众所周知，sil和pil阶段的代码赶上hil还有一定的差异，但差异在一定程度上意味着风险。 vdk能够以vhil的形式弥补空的不足，解决了hil时间紧张、资源紧张的问题，在vhil中执行的代码接近于非常真实的hil环境。

vdk可以模拟芯片中的所有各种接口。 模拟到哪一层都可以。 性能与实际的芯片环境相比有一定的损失，但足以进行功能测试。

从汽车硬件和软件层面的角度来看，从上面的软件阶段开始使用silver工具进行虚拟仿真，到与硬件直接交互的阶段，vdk将其整个虚拟化，下面的saber是比较物理层信号的另一个虚拟化工具。

这里有例子。 英飞凌2023年推出了他的新一代自动驾驶芯片aurix 3g mcu系列，现在用vdk虚拟化了这个芯片的规格，交给了第1层。 tier1基于这个设计软件交给了有名的国际oem大工厂。 现在，这个oem正在基于这里进行整体方案的整合。 那样的话，就很容易理解其利益了。 芯片出来后不需要等待软件部分的制作

最后，这在软件安全方面我们的事业部一直很低调，但已经连续三年在gartner中处于领导者的位置。 如果大家感兴趣的话，之后也请试着交流。 这里还有我的微信和我们事业部的二维码。 大家可以扫描添加，如果有兴趣的话也可以去外面的展台进一步交流。