开始阅读之前强烈建议参考之前系列文章:
汽车功能安全 ISO 26262专题内容 (点我🤪)
那么对于软件而言，很多朋友经常不知道如何下手，真的有必要做安全分析吗？和系统和硬件安全分析有什么不同，应该怎么进行安全分析，分析的颗粒度要多大等，针对这些问题，我们今天就系统地来聊聊:
软件的bug究竟源于什么？ 软件安全分析真的有必要做吗？ 软件安全分析到底在分析什么？ 软件安全分析究竟用FTA还是FMEA? 软件安全分析怎么做？
Q: 软件的Bug究竟源于什么？
但具体而言，软件的系统性失效或Bug，根据所处的软件层级不同，呈现出不同的特性:
1
软件单元或函数层级:
特点: 确定性强，易复现，易排除，多呈现静态特性。
2
软件架构层级:
Q: 软件安全分析真的有必要做吗？
但这个结论其实并不完全正确，或者至少在实际操作中，软件安全分析还是有其必要性，个人觉得主要原因在于:
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为例，应用上述表格中的引导词，可以得到如下的软件故障:
以此为例，分析所有软件模块可能存在的失效情况，这一步也是整个软件安全分析过程中最耗时的部分。
步骤四: 制定安全改进措施
根据上一步骤所识别出的失效模式，制定相应的安全改进措施，如有必要，导出相应的软件安全需求，并进行软件架构更新。重复以上步骤，直至软件失效可能性足够低！
写在最后:
AUTO世代知识店铺已上线，包括: 付费社区，AUTOTalk，AUTO课堂精品线上课程，坚持高品质原创输出，部分课程限时特价，精彩不容错过，感兴趣的朋友直接长按下方二维码了解。
END
【点赞】和【在看】= 原创的动力
多谢【点赞】和【在看】
