一、前言
《Better Embedded System Software》一书的作者在其博客上发布了可致命汽车软件缺陷列表，该列表主要来源于NHTSA（美国高速公路安全管理局）官网上的召回通告。作者在博客中表示，整理出列表的目的不是要针对任何特定的公司或软件缺陷，现实是关键的安全性软件缺陷在整个汽车行业中都是普遍且持久存在的。列表详见：
https://betterembsw.blogspot.com/p/potentially-deadly-automotive-software.html?m=1
本文将首先从清单中挑选出一些典型例子，然后讨论SAST能对这些状况提供的帮助。
二、汽车软件故障示例
原博客中列出的那些问题能被作为车辆召回的原因，也表明了那些问题确实是足够严重的安全隐患，以下是部分召回信息：
- 由于诊断检查问题，ABS 和 DSC 被禁用（捷豹）/ 2021 年 3 月。
| NHTSA ID：21V-167 |
| 在汽车启动时运行的防抱死制动系统(ABS)的诊断检查可能不能在所需的时间内完成，这可能会导致ABS和动态稳定控制(DSC)系统在该行驶工况内失效。 |
| 有时，ABS模块的CCF读取周期没有在预期的时间内完成，诊断检查需要长达25秒。15秒后ABS停止传输，ABS和DSC系统终止，仪表盘上的故障指示灯亮起，以警告驾驶员系统不可用。 |
2、无线电软件安全漏洞（克莱斯勒）/ 2015。
| NHTSA ID：15V-461, 15V-508 |
| 利用软件漏洞可能对某些车辆系统实施未经授权的远程修改和控制，增加撞车的风险。 |
3、ESC故障（梅赛德斯）/ 2021 年 2 月。
| NHTSA ID：21V-071 |
| 在某些规避驾驶测试中，电子稳定程序（ESP）软件可能会向一个前轮施加扭矩，将车辆拉向一侧。如果车辆在躲避过程中被意外拉到一侧，可能会增加撞车的风险。 |
4、制动性能降低（现代）/ 2020 年 12 月。
| NHTSA ID：20V-748 |
| 集成式电子制动 (IEB) 系统可能会检测到异常的传感器信号，因此可能会降低制动性能。 HMC在IEB电机控制软件中发现了这样一种情况，即在缺乏适当“故障安全”逻辑的情况下，当检测到异常传感器信号时，IEB电机将被禁用，从而降低了基本的制动性能。 |
5、由于偏航传感器软件的缺陷，特别是诊断程序缺陷，导致错误干预电子稳定程序（ESP）。在这种情况下，传感器漂移会增加撞车的风险。
6、 由于软件代码缺失以及与新引入的硬件不兼容，自动紧急制动可能无法启动。
以上只是一些有代表性的问题，还有非常多类似的召回案例，其中涉及到的软件和硬件缺陷，可能影响车辆稳定性、制动和发动机控制等关键方面。
三、SAST在安全关键软件开发中的作用
汽车软件的安全保障显然是一个系统性问题，需要企业文化、管理流程和研发技术变革共同推进。行业自认证也存在问题，ISO 26262等标准并没有被普遍采用，由于这个主题太大，以下将仅关注可以通过SAST (static application security testing，静态应用程序安全测试) 和SCA (软件组成分析) 改进的流程和过程。
SAST的强大之处在于不依赖于测试用例来发现问题，也不需要重现错误或失败。类似GrammaTech CodeSonar这样的SAST工具可以在不实际运行程序的情况下推断出程序的运行时行为。此外，当它识别出一个问题时，还能在代码中定位到导致失败的位置。这使得调试工作变得简单。
静态分析并不能完全替代测试，而是对测试的有效补充。现实情况是，在大型的复杂软件系统中，可能的状态非常之多，可能的执行路径数量更是惊人，所以对它们进行详尽的测试是不现实的。静态代码分析可以从总体上探索这些路径和状态，以发现测试中遗漏的问题。
- 通过编码标准进行预防：编码标准是安全关键软件开发的重要组成部分，因为它们定义了一组更安全的编程语言子集。汽车软件中最常用的标准是 MISRA C 和 MISRA C++（还有相关的AUTOSARC++标准）。执行更严格的安全编码标准，可以提前消除许多软件缺陷，重点是避免使用已知的危险语法和每种语言中潜在未定义行为的部分。
- 代码覆盖率不代表一切：许多安全标准需要高水平的代码覆盖率（以证明测试执行了大部分语句和条件）。虽然这是非常详尽的，但做起来成本很高，而且必须在开发的每个主要阶段重复进行（单元、集成和系统测试）。其实软件的关键性决定了覆盖率的水平，一些不太关键的软件不需要正式的测试覆盖率。虽然测试代码覆盖率是评估软件质量的一个指标，但在有些情况下，它并不是绝对的。
- 被基于覆盖率测试所遗漏的漏洞和错误：基于覆盖率指标的软件测试本质上是基于单元的测试（尽管覆盖率也会在系统层面进行评估）。而并发性错误和安全漏洞是两个在严格测试中也可能被遗漏的隐患。并发产生的错误（如竞争条件）只有在运行过程中出现一些不可预见的情况时才会被发现。安全漏洞是存在于代码中的错误 – 造成错误的原因通常是由于在测试期间没有考虑输入的类型。SAST可以及早发现这些错误，并防止它们在开发周期的后期成为绊脚石。
- 及早发现缺陷：严格的测试可以发现软件中的大多数缺陷，但成本高昂且极其耗时。在编写代码时就发现和修复这些错误比在开发周期后期便宜得多（随着时间的推移，发现缺陷的成本呈指数级增长）。静态分析可以在代码编写时检测错误——如果能作为开发人员开发环境的一部分，这将大大降低缺陷出现在下游时的成本。
- 分析开源和第三方代码：在嵌入式软件开发中，使用第三方代码和开源软件是一个常见现象。一些安全标准认为，任何没有按照特定标准开发的软件都是血统不明的软件（SOUP）–是需要仔细检查后才能纳入系统的。针对这类情况，软件组成分析工具SCA可以提供帮助，如GrammaTech CodeSentry，可以分析第三方二进制文件以发现缺陷和安全漏洞，并生成软件材料清单（SBOM）。
四、总结
NHTSA对存在软件相关缺陷车辆的召回正在增加，这表明汽车软件开发需要加快改进步伐。然而，为汽车系统开发嵌入式软件，需要遵守严格的方法和承诺，以增加安全和保障，改进需要自上而下地进行文化和流程的改变。与此同时，还需要自下而上的改变，采用最佳实践，包括流程和编码标准以及其他经过验证的方法来提高代码质量。
引入高级静态分析工具将有助于自动执行编码标准，更重要的是它们能在查找被其他验证测试活动遗漏的缺陷方面发挥重要作用，并且有助于开发人员理解和纠正代码问题。对软件成分分析以及审查开源和第三方软件的已知漏洞，并创建软件物料清单 (SBOM) 会对降低软件供应链风险起到关键作用。
参考链接
[1] https://blogs.grammatech.com/automotive-software-safety-and-security-still-needs-improvement
[2] https://betterembsw.blogspot.com/p/potentially-deadly-automotive-software.html?m=1
[3] https://www.nhtsa.gov/recalls
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。