案例分享：沃尔沃如何让软件安全分析支持敏捷开发中的 ISO 26262-6 合规性

软件安全分析是汽车系统安全审查的一部分，其目的在于减少车辆使用中由软件缺陷引起的风险。ISO26262-6第7节要求对车辆ECU的软件体系结构进行特定的安全导向分析，以实现以下四个目标：

证明软件能够提供特定的安全相关功能和属性；

辨识和确认软件的安全相关部分；

支持安全机制以及验证这些安全机制；

检测可能违反所需干扰自由度的故障模式。

随着软件数量的爆炸性增长，错误发生的概率也在增加。这意味着不再可能分析每个给定软件系统的状态，并确定其中是否存在相关的错误。相反，通过分析一些特定特征，如复杂性、代码静态检查等，可以估计软件中错误的数量概率。然而，ISO 26262-6第7节也要求对某些类型的错误，在架构级（即车辆功能层面）进行全面分析。下文介绍了一种基于此要求发展的方法。

软件安全分析中的一个主要挑战是，作为一个系统，软件的状态数量比硬件多得多。事实上，无法对所有状态进行分析，并以合理的方式确定哪些状态应该优先考虑。因此，我们的研究使用了一些系统安全分析方法的概念，如“指导词”和“故障模式”，作为标准表示。

除此之外，有些人提出了以软件为重点的安全分析方法，例如：

Petri网分析；

失效传播转化符号FPTN；

软件关键性分析；

软件FMEA；

软件故障模式、影响和关键性分析（SFMECA）。

然而，FPTN更多的是一种标记技术，不能进行详尽的分析。Petri网分析适用于基础软件。软件FMEA和SFMECA用于应用层软件，但随着软件复杂性的增加，需要投入更多的努力。软件临界性分析和SHARD关注数据流。SHARD提出的数据流概念在我们的背景下非常有价值，它在以下方法中有所运用，但使用的顺序和抽象层次不同。这些方法从整个架构层面开始分析，自上而下研究输入输出信号和相关的故障模式。它们假设存在一个固定的前端架构，不会随着时间显著变化。

然而，在现代软件开发中，架构基本上是不断变化的。对于沃尔沃汽车而言，敏捷团队拥有称为软件包的架构组件（见图1）。与ECU级别的架构决策相比，软件包内部的架构决策更加紧急，并且相对稳定的时间更短。紧急的架构变化阻碍了自上而下的分析，因为信号状态可能在过程中发生变化，使得分析结果无效。另外，在我们的案例中，基础软件和部分应用软件是由供应商提供的，因此无法进行自上而下的分析。

图1 沃尔沃汽车ECU软件概述

对于ISO 26262-6的合规性，应用软件的复杂性、对客户需求的敏感性、多地点开发以及迫切的架构变更等因素迫使我们构建一种全新的软件安全分析方法。然而，这种方法是专门针对以Simulink模型作为软件单元开发的应用软件而设计的。这个方法并不适用于手写代码和基础软件。相对于Simulink模型，手写代码的开发限制较少（例如，可能不强制遵循严格的编码标准），并且与其他文件和函数之间的耦合更为密切。因此，在分析不够清晰的数据流时，可能需要投入更多的工作量，这对于开发来说可能是难以接受的。

  1. 研究方法

在研究过程中，关键的决定之一是首先识别软件中存在的所有错误类型。由于错误种类繁多，确定哪些类型需要进行面向安全的软件分析，以及哪些错误会影响软件安全分析的目标实现是至关重要的。为了处理这种情况，通常会采用行动研究方法：成立一个由各领域专家组成的参考小组，在行动研究周期内进行反复迭代。该小组成员包括软件工程技术领导、软件安全技术专家、高级安全工程师、软件开发首席工程师、软件架构师、高级软件开发人员以及负责开发车辆安全关键功能的产品负责人。其任务涵盖以下方面：

根据特定的软件开发流程和工作产物，识别可能存在于应用软件中的所有错误类型；

针对已识别的错误类型，调查和记录当前的解决方法；

为尚未发现的错误类型指定预设解决方法；

审查面向安全的软件分析方法的开发。

沃尔沃为尚未发现的错误类型提出了初步的解决方法，并设计了面向安全的软件分析方法的框架。通过参考小组在行动研究周期中对这些提议的质疑和批判性讨论，初步结果得到了进一步的完善。在大约一年半的时间内，软件安全分析方法逐渐具体化。随后，该方法被应用于沃尔沃某一大型ECU内部的应用软件，这一过程中对分析方法进行了更多的调整。应用该方法的软件包括大约200个Simulink模型（生成约80万行代码），由12个敏捷团队开发。

 2. 软件安全分析方法

这个分析方法由两个主要部分组成。首先是对软件开发过程的评估，使用一套实用且有效的方法来检测整个开发链中的错误。这些方法能够识别和消除大部分开发阶段的软件错误。这个过程被称为通用软件安全分析，明确包含了对软件错误进行概率性检测的性质，因为并非所有软件状态都可以被检查。但这确保了通过可用的方法和工具将整体软件错误的可能性降至最低。

第二部分是面向安全的架构级别的软件分析，旨在消除在通用分析中可能被忽略但可能对安全目标实现不利的错误。架构级别的安全分析与软件工程保持同步，与通用分析同时进行。这两种分析通常使用自动化检查、基于度量的更正、同行评审和自动化测试等方法来辅助进行分析。

通用软件安全分析识别了开发链中的错误，并提供了解决方案。表格中记录了我们产品的这类调查结果。如果某一类错误可能影响到四个安全目标中的任何一个，就需要进行额外的面向安全的分析。这些错误类型在表格中以粗体显示。它们会定期进行评估和更新（例如，每年一次）。负责软件安全的专家应确保表格中的信息保持最新。

表1 汽车软件确定的错误和解决办法

 3. 架构级别面向安全的软件分析

这个面向安全的分析旨在识别由需求错误说明、错误分配、不正确的信号接口以及错误的功能调用导致的错误（在表1中以粗体显示）。整个分析分为两个阶段：

第一阶段：

第一阶段的分析针对Simulink模型展开。每次，一个敏捷团队选择一个Simulink模块，并在软件安全专家的支持下进行分析。

研讨会启动：产品负责人与敏捷团队和软件安全专家组织研讨会。假设团队已有关于给定模型的故障模式以及每个故障模式对应的车辆级安全级别（CLs）的正确信息。然而，这个分析的目标之一是验证和纠正这一假设。

车辆级安全级别（CLs）定义：CLs定义如下：

CL1：如果车辆级后果未违反安全目标，则分类为CL1。如果模型只包含CL1，则模型本身被归类为CL1。

CL2：如果车辆级后果违反安全目标，但有安全机制避免该后果，则分类为CL2。如果模型包含CL2和CL1，则模型本身被归类为CL2。

CL3：如果车辆级后果违反安全目标且没有任何安全机制，则分类为CL3，模型本身被归类为CL3。

第二阶段：

第二阶段的实体是应用软件，由软件架构师在软件安全专家的支持下进行分析，并利用第一阶段的结果。

以上是对第一和第二阶段的概述。接下来会有详细的逐步描述。（图2显示了第一和第二阶段的概貌）

图2 阶段1和阶段2概述

阶段 一：由敏捷团队在安全专家的支持下进行：

了解模型功能：对模型实现的功能有所了解。

确定故障模式：根据模型的输出信号和功能调用来确定故障模式。

确定车辆级后果：基于团队知识确定每个故障模式的车辆级后果。

分类车辆级后果：

如果车辆级后果不违反安全目标，则分类为CL1。

如果车辆级后果违反安全目标，但存在安全机制避免此后果，则分类为CL2，并记录相应的安全机制。

如果车辆级后果违反安全目标且没有任何安全机制，则分类为CL3。若输出信号或功能调用是CL3，则进行不适当设计的检测。

确认CL3部分：

确认具有CL3故障模式的模型在架构描述中是否有相应的ASIL等级分类。若无，则存在不适当的设计。

确认具有CL3故障模式的模型是否有相应ASIL分类的故障模式需求。若无，则存在不适当的设计。

记录故障模式和信号：

对于至少有一个CL2或CL3的模型，记录所有故障模式、输出信号（函数调用）、车辆级后果、CLs和ASIL级别的名称。

确定CL3故障的原因：

根据团队知识确定并记录CL3故障的原因，将原因按CL1、CL2或CL3分类。原因可以是输入信号、触发器、代码开关、配置和其他错误类型。

记录补充知识：记录团队认为完成第1阶段所需的补充知识。

在第1阶段完成后，所有标记为CL3的模型应与系统安全工程师共享，以确认危害分析中的相应ASIL等级。ASIL等级应与第5点下第一个条目中的信息一起记录。

在这个过程中，引导词被用于系统地表示设计意图的可能偏差，并确定可能的后果。这些词用于识别弱点、故障和故障。分析工程师应在安全专家的协助下选择适当的引导词，取决于所检查功能、行为、属性、接口和数据的特征。表2提供了第1阶段分析结果的样本。第2阶段的分析将使用第1阶段的结果来确认CL2模型的安全机制，并评估安全相关软件的抗干扰性。

表2 Simulink模型分析的示例结果 

阶段 二：由软件架构师在安全专家的支持下进行：

确认软件的CL2部分：

检查第1阶段中所有与CL2相关的模型及其安全机制。

确认目标软件版本中是否包含安全机制，评估其充分性。如果安全机制不完整，则存在不合适的设计，需要指定适当的软件/系统集成测试。

确认功能的分区合理性：

检查软件架构中的所有模型，确认各功能的分区是否合理。

确认具有给定ASIL等级的模型是否分配给具有相同或更高ASIL等级的软件分区。若分配不合理，则存在不适当的分配。

如果不同ASIL等级的模型分配到同一分区，请在架构描述中确认这些模型是根据最高ASIL开发标准设计的。

故障模式传播检查：

检查从较低ASIL分区到较高分区的故障模式传播。

确认所有CL3输入信号是否都来自CL3模型。若存在不一致的规范，则检测到紧急架构和合理架构之间的不一致性。

接口信号的ASIL分类确认：

根据阶段1的分析结果，确认应用软件的接口信号是否具有正确的ASIL分类。

建议团队在每个项目增量期间执行第1阶段。在某些敏捷方法中，每个增量可能为8到12周。第2阶段应在每次产品发布之前执行，前提是明确不会发生进一步的功能更改。这有助于确保系统的安全性和稳定性在发布前得到充分考虑和验证。

  4. 总结

这个方法之所以被视为经济上可行的连续安全分析方法，主要原因如下：

自动化与集成：软件安全的通用分析方法大部分是自动化的，并且与软件开发环境集成。一旦部署并建立（如表1所示），定期审查和更新信息就变得简单。这意味着团队可以轻松地保持对安全分析的持续性。

持续性的知识和文件：一旦进行了以安全为导向的分析，团队将会积累足够的知识和文件。这些文件可以根据输出信号的变化和相应信息（例如故障模式、车辆级后果等）进行更新和评估。文档可能采用Excel表格或者基于浏览器的半自动方式。

关注安全目标违反的错误：面向安全的软件分析有助于关注直接违反安全目标的错误。它不仅仅是自动检查，更关注于了解模型实现了哪些功能、模型之间的相互影响，以及模型与架构决策的一致性。这可以帮助避免可能对功能安全构成威胁的意外设计决策。

增强团队意识和知识面：这种分析增强了团队对模型在车辆级功能中作用的认识。它拓展了团队成员的知识面，使他们能够做出更明智的设计决策。

持续改进：使用此方法带来了关于改进的反馈。主要集中在提高自动化程度、集成到软件开发环境中以减少技术管理工作的方面。

总的来说，这种分析方法不仅有助于持续性地进行安全分析，还提高了团队的意识水平和设计决策的智慧。通过减少手动工作和持续改进，它也促进了更高效的技术管理。