共计 5603 个字符，预计需要花费 15 分钟才能阅读完成。
本文整顿自极狐 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 平台实现汽车软件研发的高效和平安，助力车企晋升竞争力，走向海内。
