软件定义汽车时代，1 亿行代码的安全保障，极狐GitLab 这么做！

本文整理自极狐GitLab 解决方案部总监张扬老师在 AUTOSEMO 会议上的主题分享“驾驭代码激增浪潮，护航软件定义汽车”。

软件定义汽车的挑战

“软件吞噬世界”，这是网景创始人 Marc Andreessen 在 2011 年说的一句话。这些年软件行业的飞速发展也验证了这句话。智能手机就是一个很鲜活的例子，各种 app 彻底改变了人们的衣食住行。

对于汽车行业来说，也进入到了软件定义汽车时代。在智能汽车领域，软件成本占据汽车成本的比重越来越高，软件带来的价值正在重塑整个智能汽车的商业模式。如下面的微笑曲线所示，整个汽车产业链的两端，有更多有意思并且能带来价值的一些商业模式在出现。

举一个典型的例子：软件订阅制。在早期的汽车售卖模式中，车辆的买卖基本都是“一锤子买卖”，车辆出售以后，OEM 厂商就很难再赚取用户的钱了（除了可能存在的一些维保）。但是在软件订阅制模式下，如果用户想要使用汽车的某一个功能（比如自动驾驶、空调远程自动启停等），就可以通过订阅汽车软件的方式来实现。订阅一个月就可以使用一个月。如果不想使用了，直接取消订阅即可。这样做的好处在于用户具备了自由选择的权利，可以按照自己的需求来通过软件“定制化”汽车的一些功能，而 OEM 厂商既通过这种方式和用户增加了粘性，又增加了一条可以让企业持续增加营收的方式。

软件定义汽车，那什么定义软件呢？答案是：代码。软件运行的基础是代码，而在软件定义汽车这样的背景下，根据专业机构的数据统计：一辆智能汽车，大约有 1 亿行代码，这个数据远大于大型客机（约 1500 万行）、战斗机（约 2500万行）以及一些众所周知的操作系统（诸如 windows vista，约 4000 万行）的代码量的。而且这些是 2020 年的数据，随着智能驾驶的蓬勃发展，这个数据在2025 年可能会达到惊人的 5 亿。

另外从下图可以看出，传统软件开发模式下，编码阶段引入的缺陷（包括质量和安全问题）数是最多的（85%），但是大量缺陷的真正挖掘却是在编码之后的阶段，这种情况带来了两个问题：

• 缺陷的修复是滞后的，问题的反馈慢，导致整个修复周期比较长；

• 修复的成本很高。从图中可以看出，在编码阶段引入的缺陷，其修复成本是最低的，而在软件运行状时发现的缺陷，其修复成本是极其高昂的，大约是编码阶段的 640 倍。

这种情况对于汽车软件来讲更加严峻，而且随着智能汽车的发展，这种激增的代码量所带来的挑战是巨大的，这对于 OEM、Tier 1 或者整个汽车软件生态里面跟软件打交道的所有组织来说都是一样的。

代码激增挑战的应对之道

汽车行业中的软件不同于一般行业的软件，在某些情况下交付的速度可以慢一点，成本稍微高一点，但是安全是永远不可能妥协的红线。“软件可以重启，但是生命不可以重启”，安全是代码激增对汽车软件带来的最大挑战。

软件安全如何保障？

先来举两个例子来。第一个是波音 737 Max 飞机，众所周知，737 Max 之前出过两次事故，后来有推测说事故可能和飞机上的一个防止飞机失速失控的软件有关。因为这个问题，导致 737 Max 飞机被大量停飞，而且很多已经确定的订单被取消。这种事情如果发生在汽车行业，由于汽车软件问题而带来的汽车召回、停用甚至停售，是任何车企无法承受的。而一旦涉及到人身安全这样的话题，舆论所带来的冲击对车企而言可能是毁灭性的。

第二个是“史诗级漏洞”的 log4j 漏洞事件。log4j 是一个开源组件，用户遍及全球，所以当被披露出有漏洞时，影响了全球众多用户，这其实是一个典型的开源软件供应链安全问题。

为了应对功能安全和信息安全带来的挑战，在汽车软件研发行业或者安全领域都有很多标准或者规范去参考，比如 ISO 26262、MISRA、AUTOSAR 以及 OWASP Top10、CWE Top 25，通过这些标准或者规范来提高汽车软件的质量和安全。

除此以外，还有一个点需要注意，那就是随着软件定义汽车时代到来的一个新概念——SBOM。SBOM 是软件物料清单，是一个软件的组件成分表。SBOM 主要应对的问题就是开源软件供应链安全问题。随着现在开源采用率的提升，已经很少有企业从零到一去构建所有的系统，基本都是采用一些开源框架或者库来加速构建自己的产品。这就带来一个问题：如何保障这些使用或者引用的开源组件的安全合规？万一使用的开源组件里面包含一些恶意代码，甚至一些高危漏洞，那带来的风险也是很大的。而 SBOM 通过盘点企业数字资产的方法很好的解决了上面的问题。

SBOM 还能解决另外一个问题：许可证的合规性。极狐GitLab 有很多车企客户，业务都是需要出海的，这个过程中如果忽略了软件的许可证合规问题，就可能会导致出海业务受阻，比如车企软件中包含了一些包含“强传染性” license （诸如 GPL ）的组件，但是却没有做到源代码的开放，这时候其实就是违反了这些 license 的一些许可特性，这些在国内外都是不被允许的，而且国外也面临全球化竞争，相关的监管都是非常严格的。

中国企业出海业务本就不易，全世界诸多友商都在盯着对手犯错的机会，而许可证合规是在软件领域非常容易被击破的一环，如果企业因为许可证合规出现安全问题，对于企业出海业务势必造成难以挽回的损失和重大影响。

那么回到代码激增所带来的安全合规挑战的应对，在代码级主要有以下三个可供参考的解决方案。

第一部分是代码的覆盖率测试，这属于单元测试的范畴。单元测试是从白盒角度验证代码中每一个部分（类、函数、条件等）是否正常工作的最佳方式，也是在软件开发早期就能识别软件问题的重要手段。但是其缺点也比较明显，因为这些测试代码也需要技术人员去编写，涉及到了资源的投入。但随着 AIGC 在软件领域不断的探索和演进，智能化的单元测试代码生成也并非是天方夜谭，在不久的将来终将实现。需要注意的一点是：单元测试即需要看数量，也就是要看代码里面函数的一些覆盖率，还要看质量，也就是要去看条件分支的一个覆盖率。

第二部分是代码静态分析，这部分不需要研发人员去做很多事情，只需要配置好相应的工具或者流程就能对代码进行检查。检查主要包括两部分：编码规范的检查和代码安全检查。编码规范是为了提高代码的可维护性，便于软件持续迭代演进，而代码安全检查可以使用 SAST 去做一个扫描，去挖掘代码中潜在的安全问题；

第三部分就是前面提到的 SBOM。通过 SBOM 清单去分析第三方组件的一些漏洞信息以及许可证信息等。

这三部分的内容在软件生命周期的编码和构建阶段就能落地，有效帮助研发团队在尽早尽快地解决软件安全和质量的相关问题。这就是我们经常所提到的 DevSecOps 体系中的安全左移概念。

所谓的安全左移，就是在软件研发生命周期的早期阶段就让安全开始介入，比如在编码阶段，甚至更早的设计阶段，就纳入相应的安全措施，这样做带来的价值就是：安全问题尽早发现、尽早修复、成本最低。那如何落地 DevSecops 呢？

落地安全左移的核心要点

首先是理念的转变，不管是 DevOps 还是 DevSecOps，其主要理念都是打破各个角色之间的壁垒。这一点和瀑布式模型（研发→ 测试 → 安全 → 运维）下是完全不一样的。DevSecOps 模式下需要一些举措去打破职能角色之间的一堵墙，让所有人员服务于统一的目标。

比如，对于研发人员来讲，写完代码提交之后，如果发现有安全漏洞，那就需要修复安全漏洞；对于安全人员来讲，就需要去设置安全门禁，需要明确这些安全问题的管理，比如是不是所有发现的问题都要第一时间修复，是不是所有的安全问题都需要修复等，而且还要有能力和研发人员沟通，来指导研发人员做一些漏洞修复或改进；对于管理人员来讲，其实是一个上帝视角，需要对要发布的汽车软件有一个整体的了解，它的质量和安全到底是怎样的。所以从理念上来讲，DevSecOps 的落地，其实是需要把这些角色都串起来，大家通过协作来做好安全这件事儿。

当然，要做到多种角色的良好协作，光靠管理是不够的，最终还需要用工具去帮助实现。也就是要用工具去构建一条数字世界的流水线。比如零部件流水线最后产出的是汽车，那么代码流水线最后的产出就是软件，而代码流水线也就是现在大家常讲的 CI/CD。所以未来车企会有两条生产线：第一条是物理世界或者工业世界的，用来进行整车制造，那另外一条就是软件流水线，用来构建企业运行所需的软件。

而这个软件流水线是需要工具去承载的。也就是要用工具去打造一个闭环的流水线。

最核心的就是当研发人员提交完代码以后，要能够自动地进行代码编译构建、测试、安全扫描等等，所有的这些操作都是高度自动化，无需过多的人为介入。等所有的自动化步骤运行完毕以后，研发、测试、安全等人员就可以找到针对代码级、应用级或者从各种环境中获取的关于安全和质量的一些数据报告，然后根据报告的数据进行持续迭代，这就形成了一个完整的流水线闭环。

明确理念、方法和工具以后，剩下的落地实施了。

落地安全左移的实施路径

安全左移的落地实践主要分三步走：

➤ 第一步：固化企业研发规范

企业研发规范不仅针对编码质量，还应该包括安全。比如说研发人员在本地开发完以后，需要将变更代码提交入库，那这个时候变更代码需要满足什么样的条件才可以入库？比如 ASPICE 里面可能追求的是需求和代码的双向追溯，那企业就可以要求研发人员在提交代码的时候，需要做到代码变更和需求 ID 一一对应，还有就是一些包含密钥信息的文件不应该被推送到代码库里面，其他还有诸如分支管理规范需要去遵守。

有”代码准入”，就有对应的“代码准出”，所谓“准出”是指研发人员开发的代码在合并到主干分支的时候要达到什么样的标准，这里面就涉及到了代码评审，也就是业界推崇的“代码责任田”。这个过程需要安全、测试人员能够一起对变更代码进行审核，这个可以通过查看变更代码的 CI/CD 构建结果和数据报告来进行，最终需要确保的是，如果 CI/CD 构建结果失败，或者数据报告显示变更代码有严重的质量或安全问题，那么代码就不应该被合入，只要能被合入的代码就是可以直接上线的。

➤ 第二步：持续集成

持续集成就是说要把前面提到的单元测试、质量扫描及安全扫描等全部自动化。要做到只需要人工配置一次，即可让整个团队受益。这个过程与编程语言无关，适用于车端或云端的应用，只是需要用自动化的手段将对应的流程串起来。

➤ 第三步：高效代码评审

如果想在研发阶段就解决更多的安全或者质量问题的话，代码评审是一个重要的手段。这个代码评审包含两部分，第一部分就是需要基于第二步持续集成所产生的一些数据报告来评判变更代码是否符合企业自身的研发标准，而且这些标准要能够通过在工具上通过自定义规则的方式来实现落地实践，最后通过将所有与代码质量、安全相关的人都纳入到审核体系中来，做好代码审核；第二部分，就是人工审核，也就是通过肉眼去挖掘代码中的问题。当然，目前极狐GitLab 也在积极探索用 AIGC 的方式来实现代码的自动审核，比如给变更代码打分，指出代码中的问题，给出建议代码等等。

极狐GitLab 一体化 DevSecOps 解决方案

落地 DevSecOps 不是简单的一两个工具就能搞定的，因为在 DevSecOps 的体系里面，有三个角色需要通力协作：研发、安全和管理人员。这三种角色的视角都是不一样的，研发主要是编写代码，安全人员主要是对安全问题进行判断，而管理人员更多的是做一个全盘管理。但是三者有一个共同的触点就是代码合并请求，也就是下图左侧这一部分：当变更代码需要合并的时候，必须要对变更代码进行评审，只有在这个过程中，所有的角色才能对齐，所以每一个企业都应该在软件研发过程中去落地实践代码评审。

需要注意的是，这个过程也带来了新的挑战：那就是工具链复杂。研发、测试、运维、项目经理等都有各自的工具，结果就是这些工具之间的严重割裂。而极狐GitLab 本身是个一体化的 DevSecOps 平台，能够让项目经理、研发、测试、运维等人员在一个具有统一交互界面的平台来上协作，这里面集成的十大功能所提供的能力，能够覆盖通用软件研发的整个过程。

而这种一体化的 DevSecOps 平台具备四大优势：完整性、统一性、高性能及可扩展。

完整性

完整性是指极狐GitLab 内置 7 种类型的安全扫描，能够覆盖软件研发全生命周期。而且有一点需要特别说明的是，当需要使用某一种安全能力时，只需要两行代码就能将安全扫描添加到 CI/CD 流水线中，基本上属于开箱即用。

统一性

统一性是指，不管是研发、安全还是管理人员，都有对应的安全仪表盘去查看与安全相关的数据报告。

高性能

极狐GitLab 可以并行展开多种安全防护手段的安全扫描，这样能够大大提升安全扫描的效率。

可扩展

可扩展是非常重要的一点，虽然极狐GitLab 本身就内置了很多安全能力，但是很多时候客户有自己使用的一些安全工具，那么这个时候我们就可以使用命令行或者 API 的方式将这些工具集成到极狐GitLab CI/CD 流水线里面来，而且只要这些工具输出的是符合极狐GitLab 要求的 JSON 格式，那么就可以把这些数据可视化，嵌入到 MR 或者展示到仪表盘中。这就是极狐GitLab 这一开源开放的产品带来的另外一个价值。

极狐GitLab DevSecOps 的价值

根据 Forrester 的调研报告，使用极狐GitLab 一体化 DevSecOps 平台带来的 ROI 高达 427%。原因有很多，比如企业不需要购买众多工具链，对应而来的就是不需要太多的人去维护众多工具链，这两方面真正做到了开源节流或者降本增效。另外，由于工具链的减少，数据孤岛的问题也将不复存在，所有与软件研发相关的数据都在一个统一的平台上，企业可以很容易的获取这些数据来对整个研发过程进行效能分析，然后采取一些提升研发效率的措施。

此外，极狐GitLab 为中国用户提供完全本土化的企业级服务支持，能够让用户通过一体化 DevSecOps 平台实现汽车软件研发的高效和安全，助力车企提升竞争力，走向海外。