软件安全分析：构建更强大的软件系统，从零基础到精通，收藏这篇就够了！

程序员肉肉

于 2025-02-13 16:39:04 发布

阅读量613

点赞数 27

文章标签：安全数据库运维服务器大数据网络

本文链接：https://blog.youkuaiyun.com/yy1715713348/article/details/145586098

版权

来源 | 博世智能驾驶与控制系统

随着汽车软件的不断发展，汽车软件开发周期变得越来越短并且软件复杂性也呈几何指数上升，与此同时我们也需要关注软件问题可能导致的安全性风险，其不仅仅关乎驾驶员和乘客的安全，也关系到其他道路使用者的生命财产安全。

因此软件开发需建立在安全需求基础上，通过有效的软件功能安全需求，我们能够避免或迁移潜在的系统故障引发的事故风险，本文将围绕什么是软件功能安全需求、如何进行软件安全分析来展开介绍。

本期专家：

Zhike(左)、Alex(右)

博世智能驾驶与控制系统事业部中国区

软件功能安全专家

软件安全需求设计

软件开发流程的需求

ISO 26262 是汽车行业广泛采用的功能安全标准，它定义了一系列的安全流程、方法和工具，用于管理汽车电子系统的功能安全。遵循这一标准，可以有效的管理软件安全开发流程和开发工作；同时这套流程也和传统V模型开发是契合一致的，因此在公司内部制定合适合规的软件质量开发流程的同时一定程度上也符合了ISO26262软件开发流程的部分要求，如下图:

为什么需要安全合规的开发流程？本质逻辑是: 过程影响结果。不规范的开发流程是导致软件bug频发的重要原因之一；通过对开发过程进行质量流程约束，开发出来的软件质量也尽可能得到保障，这是避免系统性失效的底层框架需求。

软件安全需求

从上一章得知，整个软件安全开发V模型始于需求开发，那需求从哪来？

应用层软件ASW的安全需求一般来源于以下几个方面:

① 技术安全需求TSR (系统需求级别);

② 硬件/中间层/操作系统/基础软件等导出的安全需求 (使用假设);

③ 集成平台或外部应用层软件模块的安全限制需求 (使用假设);

④ 权衡功能可用性

(functional availability)

功能安全开发实践过程中的小思考:

我们在满足安全要求的同时，也需要思考如何保证” 功能可用性”；如何避免功能安全过设计以及避免照本宣科的把安全机制生搬硬套；这是需要每一位功能安全工程师和开发人员深入到功能算法和性能测试中，才能找出真正的安全薄弱点，真正使得功能安全贴近于软件功能开发过程，助力于软件质量和性能的提升。

那什么是软件安全需求？

软件安全需求 = 安全相关的软件功能需求 + 软件安全机制

软件安全需求一定是建立在软件功能需求(SWRS)的基础之上，换言之，先有软件功能或特性需求SWRS，才会进而基于TSR导出软件安全需求。

安全相关的软件功能需求包括但不限于：

① 使标称功能能够安全执行的功能；

常见如时钟，电源等确保软件安全运行的功能；实际项目实践中也需关注安全相关的应用层功能需求，其相应的故障会直接导致safety goal的违背，这一点在ADAS安全开发中尤为重要（例如感知子系统无法采用传统E-GAS架构等安全开发方式）。

② 与性能或时间关键型操作相关的功能；

例如性能优化相关的功能模块，其失效会直接导致不满足SOTIF相关的安全指标。

③ 生产，操作，服务和退役期间与机载和非机载测试有关的功能；

例如车载通信、车辆诊断等相关内容。

④ 允许在生产和服务期间修改软件的功能；

例如可配置参数或者标定数据等。

软件安全机制包括但不限于：

① 与基本软件或应用软件本身故障相关的自检或监控功能；

例如应用层软件程序流监控，合理性校验，上电自检等。

② 与安全相关要素的故障检测，指示和缓解有关的功能；

例如控制单元电源、时钟等安全要素的故障探测。

③ 使系统能够达到或保持安全状态或降级状态的功能；

例如失效后的功能降级管理，系统安全状态的行为等。

④ 对软件功能和特性的要求，包括不同功能之间的独立性或免于干扰。

例如独立性免扰分析中的软件分区等。

软件架构安全设计

有了初步的软件安全需求后，需要开始去对软件架构进行安全设计的迭代。

软件架构是如何基于软件安全需求进行安全设计的？

① 基于软件安全需求整理出安全关键路径，这是后面安全分析和风险评估的基础；

② 在架构层面对安全关键路径和非安全功能路径做免扰分析，保证接口/内存/时序上的独立性;

③ 在静态软件架构层面，分析接口/通讯潜在失效导致的安全风险；

④ 在动态软件架构层面，分析多并发线程下可能导致的故障是否违背安全需求；例如需要考虑:

软件单元调度的优先级；
软件单元的执行时间；
故障降级管理的最小时间要求;
多应用场景下的功能模块安全部署等等。

其中，控制流和数据流的分析也是保证软件架构安全设计的重要手段。

安全需求导向软件分析

26262对安全导向软件分析的要求

根据ISO26262-6:2018的定义，安全导向软件分析的目的是确保嵌入式软件【确实】能够满足分配的功能安全需求。强调【确实】，是因为在软件安全需求从系统需求向下分解时，一方面开发人员无法很直观地保证设计的需求能够涵盖所有工况，如复杂状态机没考虑到的跳转路径，级联失效共因失效，程序流调度，通讯错误等；另一方面软件在特定某些运行工况下可能会出现不可预知的失效，如死锁活锁，跑飞，内存溢出等。

这里提一下算法性能不足导致的非预期输出，比如车速补偿，一定程度上也可以归类为性能问题，但本质上也属于系统性失效，因此安全文化保守的OEM或供应商（如博世）会将其也列入安全导向软件分析的考虑范畴。

按失效类型的不同，安全导向软件分析又可以进一步细分为独立性分析(DFA)和软件安全分析(SSA)，前者考虑的是由软件在资源、时间、通讯、系统耦合方面的独立性问题带来的安全风险如共因失效和级联失效，导出独立性机制和免扰机制（Freedom From Interference i.e. FFI）。后者考虑前者以外的其他所有可能导致安全设计无法按预期工作的失效。

本文受限于篇幅，将重点先对软件安全分析SSA的实操进行举例详解。

SSA的实操

在项目实操中，SSA通常在软件开发初期开始进行（即软件安全需求有了初步分配和架构设计，分析目标颗粒度的软件模块有了一定的成熟度时），贯穿整个开发过程。

做SSA分析前，应明确分析颗粒度，即分析对象最小到什么层级，这决定了SSA的输入信息来源（比如分析颗粒度是runnable，那么需要的输入为对runnable的安全需求，原则上不必须打开runnable内部设计，当成黑盒）。但值得注意的是，在项目实操中，这个颗粒度更多起到的是一种guide的作用，但应避免将其奉为死规，很多情况下（尤其对算法类设计这种上层需求很难清晰严格定义的设计），适当下探最小颗粒度对找全找对合理失效模式和影响有很大的帮助。

SSA实操过程一般会经历安全需求确认 > 架构路径确认 > 静动态架构流确认（以上都是输入信息收集） > SSA分析 >安全机制导出 > 安全需求生成和维护 > 软件实现 > 软件测试 > 迭代。

信息收集和实现验证的过程与软件传统V流程相统一，本文重点说明SSA分析和安全机制导出。

SSA分析

这一步旨在系统性地定位软件失效和安全影响，服务于后续安全机制设计。方法有很多种，基于当前L2+驾驶辅助功能对ADAS域的功能安全分配通常是ASIL B，这里以类似FMEA的inductive方法进行分析示例。博世实操中，以被分析对象的所有接口（包括通讯、诊断、配置、持久化）为切入点，结合类似HAZOP的引导词（如值域类的过大过小，时域类的过早过晚，通讯类的丢失等），生成单点失效模式，分析影响，作为后续安全机制导出的输入。

安全机制导出

这一步以SSA分析输出的失效影响属于安全相关的失效模式为输入，针对性地制定设计或流程机制进行counter。可以从下面几个方面分析：

① 软件复杂度：

软件接口数量，数据结构复杂程度，内部状态机数量，变量数量，程序流路径分支数量和交叉情况。越复杂的软件，越难理解，越容易出错，也越必要安全机制。

② 软件成熟度：

软件是否复用，Base软件市场运行情况，可以判断软件是否成熟，越不成熟的软件越需要额外安全机制。（值得注意的是，由于软件市场运行情况监控很难举证，这个方面在实操中需要谨慎，通常会将其转化为专家经验作为判断支持依据，但不作为决定性因素，在只有这个点支持时，一般保守考虑会要求增加安全机制）

③ 安全影响程度：

造成的impact对安全造成多大的影响，从功能安全角度考虑，违反安全目标的都是顶级，但实操时一般会根据伤害程度和伤害概率不同进行一些主观调节。（如顶层安全目标是超过ODD速度区间还是紧急避碰失效，二者都是安全相关，但critical程度有很大区别）

对于确定需要设计安全机制的失效模式，实操中可以考虑下面几类安全机制：

① 值域类监控：

Range check：如最大车速计算范围，如目标探测FOV合理范围，应注意阈值对功能可用性的合理兼容，测试log统计数据是很有效的依据。
Plausibility check：这种check一般case specific，比如雷达的RCS check，video的blindness check，都可以认为是plausibility check的一种，但常见的思路是用被检测对象本身物理属性（比如车速不可能跳变）、与其他物理量的关系（比如standstill信号不可能在轮速高时置位，不同来源时间戳不匹配）、瞬态故障机制（硬件锁步或软件锁步如冗余算法）。

② 时域类监控：

Checkpoint：基于checkpoint报出-计数机制，对进程/线程的执行时间进行超时和顺序的监控，比如alive check, deadline check, control flow check。
BSW特殊设计：通过BSW的一些特殊设计监控程序流运行及进入安全状态，如MCU周期性检查特定task运行完成情况，有问题即中断并重启。

③ 通讯类监控：

常见如外部信号E2E，内部变量由中间件内存保护机制覆盖如MPU，ECC等。

在评估安全机制的有效性时，可以从机制与安全功能设计的异源性，failure mode的覆盖率出发考虑安全机制的检测能力。

实例

如第2章所说，硬件导出的安全需求也是软件安全需求的一个重要来源，其中需要软件安全影响分析以及导出相关硬件故障监控的软件安全需求，这里以常见的硬件瞬态故障为例，简要介绍当硬件资源存在局限性而无法覆盖足够的诊断覆盖率时，如何通过软件安全分析导出软件安全需求。

进入正文前先介绍瞬态故障，瞬态故障定义是故障发生一次后随即消失；其中电磁干扰，宇宙射线干扰等都是造成瞬态故障的原因；故障导致的影响是硬件电路逻辑输出错误，如内存位翻转等，随之导致数据跳变或逻辑错误，可能会造成违背安全目标的系统失效表现行为。

行业内针对瞬态故障的安全措施一般有硬件锁步核、冗余执行等方式，但在有些项目实践过程，硬件可能没有相应的锁步核配置，冗余执行也带来计算资源消耗过大造成性能问题的额外影响等等。这时候需要权衡算力、硬件资源及成本的考量。

博世从应用层软件入手分析瞬态故障造成的实际安全影响，提出针对性的软件安全措施，最后验证其故障诊断覆盖率是否满足要求。

安全影响分析测试:

如下图，以车速计算这个安全相关的软件模块为例，其中轮速脉冲信号和其他信号作为输入，通过最小二乘法等预测方式计算车辆车速，分析瞬态故障的安全影响。

① 进行瞬态故障的故障注入测试，注入包括：

输入数据
内部数据
配置参数
逻辑指令

② 测试结果存在两种case:

Case-1: 大部分瞬态故障造成输出影响仅持续一个周期，无安全风险(within FTTI)；
Case-2: 某些功能模块的瞬态故障造成输出影响持续一段时间，系统表现存在安全风险；如下图，由于车速计算是时间累积效应，轮速脉冲信号的单个周期瞬态故障会导致一段时间的错误车速输出，从而导致感知目标属性错误，造成最终系统故障行为表现。

制定软件安全措施:

①从影响分析的结果来看，Case-2相关的功能模块即为瞬态故障下的安全薄弱点，此时可以从架构层面考虑，例如关键功能模块部署到MCU锁步核、关键逻辑冗余计算和冗余输出比较等常见软件架构安全设计。

② 这里基于车速计算模块提出了监控机制，例如对轮速脉冲信号做了以下安全机制:

Range check/gradient check;
Timestamp check;
Plausibility check.

如上面所说，制定安全机制时应该注意权衡功能可用性，尤其对感知算法类输出检验，如何将机制和阈值定义到足够严苛能够充分检测出潜在违反功能安全目标的异常，又足够鲁棒能够包容复杂运行工况下的合理波动，是安全机制设计的亘古难题。

以上文case为例，高频轮脉冲的丢帧和乱序对Parking类功能场景下的低速车速评估有巨大影响，因此理论上timestamp check应要求检测到任何丢帧情况都降级进入安全状态。但嵌入式软件在整车实际工况下的运行过程中，不可避免会出现偶发丢帧，如果直接降级则对功能可用性影响不可接受，因此在实操中，博世设计了一套备份算法，在检测到轮脉冲丢帧的一定时间内，由冗余算法持续输出满足功能安全等级的可信车速，仅当连续丢帧超过一定阈值后才进入安全状态，以此增加故障容忍能力，增强系统鲁棒性。

诊断覆盖率的验证

提出的安全机制对于瞬态故障的探测是否有效，需要通过诊断覆盖率来进行验证。

基于SSA分析出的关键软件模块需通过10000次data sequence的故障注入测试，test pass/fail判断依据基于系统表现行为是否违背安全目标，最后验证覆盖率结果是否满足应对应的ASIL指标。