本篇属于汽车功能安全专题系列第24篇内容，我们聊聊软件安全分析相关的内容。
开始阅读之前强烈建议参考之前系列文章:
系统及硬件级别的安全分析，相信朋友们都不陌生，网上也有很多相关资料，在此就不再赘述。
那么对于软件而言，很多朋友经常不知道如何下手，真的有必要做安全分析吗？和系统和硬件安全分析有什么不同，应该怎么进行安全分析，分析的颗粒度要多大等，针对这些问题，我们今天就系统地来聊聊：
- 软件的bug究竟源于什么？
- 软件安全分析真的有必要做吗？
- 软件安全分析到底在分析什么？
- 软件安全分析究竟用FTA还是FMEA?
- 软件安全分析怎么做？
Q: 软件的Bug究竟源于什么？
总体而言，和系统和硬件失效相比，软件失效或Bug属于系统性失效，也就是由人为设计疏忽，错误等原因导致的确定性的失效问题，这些失效都必须通过相应的修改和调整才能消除。
但具体而言，软件的系统性失效或Bug，根据所处的软件层级不同，呈现出不同的特性:
1、软件单元或函数层级:
示例: 函数语句语法错误，变量错误，计算逻辑错误，死循环，函数漏写，漏定义等。
特点: 确定性强，易复现，易排除，多呈现静态特性。
2、软件架构层级:
示例: 执行时序错误，数据流错误，接口错误，资源抢占等。
特点: 不易复现，难排除，和FFI(Free from Interference)相关，本质上源于硬件随机失效问题，只是具体在软件层面的结果体现，多呈现动态特性，甚至不可或很难复现。
Q: 软件安全分析真的有必要做吗？
针对软件系统性失效问题，ISO 26262 一般通过安全开发流程的约束，即严格的开发流程要求及测试完备性要求，尽可能降低系统性失效的可能性。
所以，理论上来讲，即便没有软件安全分析过程，通过严格的安全开发流程约束(ASIL等级越高，安全开发流程约束越严格)，软件的系统性失效问题已经得到有效控制，这也是有些朋友认为专门的软件安全分析没有必要的原因。
但这个结论其实并不完全正确，或者至少在实际操作中，软件安全分析还是有其必要性，个人觉得主要原因在于:
1、随着汽车软件复杂性不断提高，软件组件的开发涉及多个开发团队的协同工作，软件组件之类的交互以及动态属性也愈加复杂，单纯的软件安全开发流程约束，很难完全覆盖软件失效问题。
2、系统架构层面的软件失效多具有动态过程，很难通过软件安全开发流程约束识别出来。
3、在ISO 26262 Part 6专门明确了软件安全分析的要求，这个也是2018版本新增的内容之一。
4、机器学习(AI)等非白盒模型的应用，使得软件可解释性降低，失效可能性增加，基于架构的安全分析虽然并不能使得非白盒模型完全可解释，但有助于从逻辑层面分析潜在失效问题。
综上所述，软件安全分析还是非常有必要，尤其是适用于比较复杂的或动态特性比较高的软件系统。
Q: 软件安全分析到底在分析什么？
在前面第一个问题"软件Bug到底源于什么?"中，我们聊到了软件系统性失效多存在于两个层级，即软件单元和软件架构层级。
由于软件单元层级的失效多带有静态特性，基本上可以通过流程约束覆盖。此外，针对软件单元层级的安全分析工作量巨大，实际操作可行性也不大，而架构层面的失效多涉及运行时序，数据流问题等，具有明显的动态特性，复杂度高，软件安全开发流程约束不容易检出，需要进一步通过安全分析进行识别，并制定相应的安全措施，对软件安全需求进行补充，执行，此次进行迭代，最终改善软件安全问题！
所以，软件的安全分析的对象是软件架构，重点在于分析架构动态特性可能带来的功能安全问题，非具体的软件单元层面代码级别的语法，逻辑等错误，这样的软件安全分析才更有意义和实操性。
而对于软件动态特性而言，最常见且重要的的失效问题就是不同ASIL等级，或者安全和非安全相关软件共存，出现的避免要素之间的干扰问题(FFI, Free From Inteference)，即：
— 时序和执行;
— 内存;
— 信息交换。
所以在软件安全分析过程中，需要着重针对以上问题进行相应的软件安全分析。
那么紧接着的问题是，软件架构本身颗粒度也不同，我们应该分析到哪个颗粒度？
这个问题在ISO 26262中并没有规定，个人觉得可以从两个角度考虑这个问题:
1、根据软件架构的复杂度，选择一个在项目周期内可实施的颗粒度，但为了保证分析的有效性和完整性，颗粒度不可过大。
2、可以考虑以软件调度层级进行软件架构分析。
此外，需要特别注意的是，软件架构级别的安全分析不区分不同的ASIL等级，所有ASIL等级都必须执行！
Q: 软件安全分析究竟用FTA还是FMEA?
在ISO 26262, Part 6附录E中，提到可以采用归纳或演绎的方法，识别可引发因果链而导致违反安全要求的设计缺陷、条件、故障或失效。
在实际操作中，比较推荐采用归纳分析方法，即FMEA(或STPA)，主要原因在于:
1、FMEA由原因到结果的分析过程，更适合软件安全分析的需求，即以软件架构为分析基础，识别潜在软件失效可能性。
2、在软件层面不存在类似于安全目标这样的顶层失效目标，软件安全分析不是将安全需求进行细化分解的过程，而是补充检查原有设计的不足。
Q: 软件安全分析怎么做?
前面聊到软件安全分析，多采用归纳分析方法，以FMEA为例，基本的安全分析步骤还是保持一致，只是会省略一些步骤，具体执行过程中也存在一定的差异:
步骤一: 分析范围及对象的确定
确定分析的对象，范围，以软件架构输入作为安全分析的基础，选择合适的软件架构颗粒度。
软件架构需要描述相关软件的静态方面(例如,显示功能要素及其接口/关系的框图表示)以及动态方面(例如,顺序图、时序图、调度图或状态图表示)。
软件架构的安全分析和相关失效分析可以遵循功能和/或处理链，同时考虑静态和动态方面。
步骤二: 软件模块结构分析
罗列分析对象对应的软件架构中所有的软件模块，并初步区分是否和安全相关。
这里需要注意的是，这里涉及的软件模块，不仅仅包括已经分配了软件安全需求的模块，还包括在分析范围内的正常功能软件模块！
步骤三: 失效模式分析
逐个分析软件模块的失效模式，这里可以使用引导词生成问题去检查架构要素的特定功能或特性。当使用引导词时，使用引导词重复执行每个设计要素的特定功能或特性的安全导向分析，直到预定的引导词都被检查过。
针对执行，调度或通信相关的引导词以及对应的可能的失效示例如下图所示:
以步骤一中的软件架构中的功能O为例，应用上述表格中的引导词，可以得到如下的软件故障:
以此为例，分析所有软件模块可能存在的失效情况，这一步也是整个软件安全分析过程中最耗时的部分。
步骤四: 制定安全改进措施
根据上一步骤所识别出的失效模式，制定相应的安全改进措施，如有必要，导出相应的软件安全需求，并进行软件架构更新。重复以上步骤，直至软件失效可能性足够低！
写在最后:
功能安全软件安全分析相关的内容我们就聊完了，希望能够给朋友们更好地理解功能安全，推动功能安全落地带来帮助。
END
文章来源：汽车MCU软件设计
推荐阅读
更多物联网安全，PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA技术交流群，请备注研究方向。
