智能汽车时代如何保障代码安全

盖世汽车可爱多

2023年4月20-21日盖世汽车与上海市国际展览(集团)有限公司(SIEC)共同主办第二届中国汽车信息安全与数据安全大会上，新思科技高级安全架构师许焱表示，汽车软件安全面临的挑战有五大挑战：供应链安全挑战大；E/E架构不断调整；软件开发和部署更加复杂；攻击面剧增，安全漏洞层出；TTM加速，迭代加速。

汽车行业数据显示，汽车行业开源软件代码库，其中60%都具有代码漏洞，高出整体行业水平。通过SCA进行深度扫描分析，准确识别风险，针对不同的项目来源，为第三方制定供应链软件安全解决方案。而企业自有代码安全实践，把专业的SAST工具融入流程，才能提高软件开发的代码和质量，同时保证开发效率。

许焱 | 新思科技高级安全架构师

以下为演讲内容整理：

智能汽车时代代码安全的严峻性

从三四十年前只有一部分发动机控制单元的代码，到现在的ADAS、智能座舱、车身控制、V2X等。单一的架构也在向多域融合的方向演进，这是软件量的提升。现在的智能网联汽车对于汽车的算力也提出了更多的要求，在做高算力比拼的背后，其实也是软硬件协同的一个结果。

此前某芯片厂商在发布高算力芯片时曾提出，依靠软件架构的改进来大幅提升了算力，这可以说是软件质的变化。还有一种可能，是软件直接和钱挂钩。

比较典型的例子是特斯拉，在选购时它的高级智能辅助驾驶系统是收费的软件包，并且价格也在不断上涨，与其车本身降价形成鲜明对比。21年时，特斯拉软件部分的收入占到整体营收的6%，并且这个比例还在不断的提升。但也要看到软件与汽车联网的需求虽然大增，但安全方面的攻击也在增加。

下图是统计的软件的攻击面，可以看到受到攻击最多的是后端服务器，包括进入系统的攻击。比如传统的OBD接口、SD卡等，这样的攻击面已经多达十几个。另外造成软件安全漏洞的原因也各不相同，可以看到右边SAE的统计，除了最上面可能是来自于软件上市的压力以外，下面三个主要是跟软件的代码和测试相关。可以归纳为没有使用好的应用安全测试系统，导致发现问题和软件开发能力需要提高。

图源：演讲嘉宾材料

因为汽车受到的攻击面增多，所以汽车上存在的一些安全漏洞问题会被利用，形成了一个安全事件。这边列出了一部分2022年公开的汽车事件的案例，可以看出网络安全事件的攻击类型多样化，比如蓝牙攻击、授权不当引起的漏洞、数据泄露的漏洞等，所以保障网络安全已经成为了较大的课题。

图源：演讲嘉宾材料

智能汽车时代代码安全的严肃性

因为汽车中有各种安全问题的隐患，国内外的立法机构、国际组织也在不断的更新网络安全的法规和标准。最重要的是两年前发布的ISO21434的国际标准，如果车企是基于此标准来建立车辆安全体系的，那么它也基本上符合了WP29 R155对网络安全管理体系的要求。有了证书之后，才可以去进行VTA的认证。CSMS体系搭建也要在应用场景和开发流程中加入安全活动，比如安全测试、OTA升级、应急响应等。

下图蓝色背景的部分是安全活动，可以看到，在用户需求方面要加入相关的安全管理，并且在产品测试等方面也要做安全的测试。这是21434标准中要求的活动事例，比如与静态分析相关时，要求集成和验证活动必须符合相关的网络安全规范，静态代码测试就可以被用来进行这样一个验证活动，当然它还要求在做静态代码测试时，还可以去做相关的编码安全规范的测试。另外在测试方面，对测试用力的驱动也提出了一些建议，比如需求的分析、边界值的分析等，在去验证安全漏洞问题时，也提供了相应的方法和建议，比如功能测试、漏洞扫描等。

图源：演讲嘉宾材料

保障智能汽车代码安全的实践

首先将汽车软件分为嵌入式和企业IT相关的软件，但软件本身的侧重点、开发模式等都是不同的。软件安全开发面临的五大挑战，首当其冲的是供应链安全的挑战。比如汽车软件是由OEM、Tier1、Tier2，Tier2++等组成，那么供应商软件是否安全、不同软件模块调用接口是否安全等都会对供应链的安全提出挑战。另外随着汽车的电子电器架构在不停的调整，软件开发的部署也变得更为复杂。并且攻击面的增加，也对安全测试提出了更高的要求。还有软件上市加速，也对开发周期进行了不断的压缩，这就对软件开发的效率提出了更高的要求。

那么如何针对第三方代码去做一个安全保障，在此之前先来分享一些数据，来源于新思科技今年年初发布的开源软件安全与风险分析报告，从整体情况来看，1703个代码库里包含有开源组建的代码库达到了96%，也就是只有4%的代码库是没有开源软件的。开源软件占整体代码库的比重是76%，并且开源软件和自研代码的比例是3：1，而这些代码库里面已知漏洞的代码库占到了48%。从汽车行业来看，100%的代码库都包含了开源代码，所占比重约为80%。那么在安全漏洞上，汽车行业的比例要高达60%。

从时间维度来看，过去五年十七个行业的高危漏洞的增长方面，汽车行业排名第五，增长了232%，增速较快。提到开源软件绕不开的话题，是许可证的风险。所谓许可证冲突是各个开源组建的许可证条款与本身项目的许可证条款存在冲突。另外一个运维风险可以理解为开源社区活跃度较低的开源软件。所以安全漏洞、许可证和运维风险都会对供应链安全造成影响，需要引起重视。

不管什么样的开源风险，处理风险的第一步是通过SCA工具去识别软件中的风险，只有使用了SCA工具根据不同的应用场景，准确识别所有的开源组件才能进行下一步的操作处理。

针对汽车行业的供应链软件安全的解决方案，可以使用SCA工具，比如新思科技的Black Duck，可以扫描整个项目的原代码和二进制文件，也可以直接导入SPDX等格式的SBOM文件，形成项目的一个初版，在此基础上用OSS治理策略来自动识别安全漏洞或是许可证违规的情况。那如果产生这样的情况，需要将相关的信息反馈到审核团队，进行处理之后再次扫描，直到确认项目里没有出现违反公司OSS治理要求的情况，才可以去做软件的发布。软件发布后，还有进行持续的监控，所以这个流程是一个持久的过程。

汽车行业的特殊性具有安全编码规范，目前的车企都在做安全编码的相关检查，虽然它可以解决整个软件的可读性等问题，但仅依靠编码规范的检查是很难确保代码的质量和安全性。如果是外界输入的变量或是其他的数据类型，不对其做严格的检查和验证，就会发生数据篡改等问题，此时就需要更专业的工具来检查。

从下图中可以看到左上角A点到B点的过程中，软件的问题在大量的减少，产品质量和安全性在逐步提升，那么竞争力也会有相应的提升。在减少的过程中，需要更强的数据流、控制流检查才能发现问题，虽然它的量相对较少，但它往往是一些质量事件或是安全漏洞背后的原因。所以在选择扫描工具时，除了安全编码规范的检查外，还需要一个相对更综合、更全面的检查。并且误报率也是一个检验的标准，如果误报率过高，那意味着研发人员需要投入大量的时间去判断是不是误报，这会降低开发的效率。

图源：演讲嘉宾材料

新思科技解决方案

新思科技研发的Coverity软件是误报率最低的SAST工具，它的检出率是97%，误报率可以控制在10%以内。除了传统的模型以外，CICD，DevOps等开发模式也在汽车开发中被应用。对SAST工具的使用，要让其无缝融入，这样才能在提高软件质量和安全性的同时，提高开发效率。

针对汽车行业SDLC的推进方案，在开发人员自检阶段，可以通过IDE的一些插件，或者是命令行的方式，对当前修改的代码做快速且高效的扫描和验证。并且代码入库门禁，可以结合代码review系统去做，只有通过了代码入库门禁的提交，才可以提交到整体的代码仓库。在代码入库后，不仅有编码规范的检查，还增加一个流程，可以根据本身的分类，去制定相应的分数，只有通过一定的标准检查的结果，才会把它提交到最终的报告中，这样可以减少确认这些问题的数量。

下图是我们软件代码做的资源相关等检查，检查完之后，可以通过邮件的方式发送给开发人员确认，开发人员可以通过浏览器或者IDE插件，快速修复问题，并且也可以把一些问题集成到BTS系统去做一个闭环。作为应用安全测试领先的供应商，可以在工具层面提供更多的解决方案，为车企的相关活动做一个支撑。