原创 | 关于汽车软件安全保障改进

  • A+
所属分类:云安全
作者 | 绿盟科技格物实验室 潘雨晨

前言

《Better Embedded System Software》一书的作者在其博客上发布了可致命汽车软件缺陷列表,该列表主要来源于NHTSA(美国高速公路安全管理局)官网上的召回通告。作者在博客中表示,整理出列表的目的不是要针对任何特定的公司或软件缺陷,现实是关键的安全性软件缺陷在整个汽车行业中都是普遍且持久存在的。列表详见:
https://betterembsw.blogspot.com/p/potentially-deadly-automotive-software.html?m=1 
本文将首先从清单中挑选出一些典型例子,然后讨论SAST能对这些状况提供的帮助。

汽车软件故障示例

原博客中列出的那些问题能被作为车辆召回的原因,也表明了那些问题确实是足够严重的安全隐患,以下是部分召回信息:
1、由于诊断检查问题,ABS 和 DSC 被禁用(捷豹)/ 2021 年 3 月
原创 | 关于汽车软件安全保障改进
2、无线电软件安全漏洞(克莱斯勒)/ 2015
原创 | 关于汽车软件安全保障改进
3、ESC故障(梅赛德斯)/ 2021 年 2 月
原创 | 关于汽车软件安全保障改进
4、制动性能降低(现代)/ 2020 年 12 月
原创 | 关于汽车软件安全保障改进
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


转载请注明来源:关键基础设施安全应急响应中心
原创 | 关于汽车软件安全保障改进

本文始发于微信公众号(关键基础设施安全应急响应中心):原创 | 关于汽车软件安全保障改进

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: