汽车安全需要无限的软件开发生命周期_技术

汽车嵌入式应用程序传统上是隔离的、静态的、固定功能的、特定于设备的实现，实践和流程依赖于这种状态。将汽车连接到外部世界会极大地改变事情，因为它使远程访问成为可能，同时无需对汽车系统进行物理修改。现在，汽车开发商有明确的义务确保不安全的应用软件不会损害安全性，不仅在整个生产生命周期内，而且只要产品在现场使用。

尽管著名的 ISO 26262:2012“道路车辆 — 功能安全”标准通过提供正式的软件开发流程有所帮助，但它并未明确讨论软件安全性。也就是说，在安全漏洞可能威胁安全的地方，ISO 26262 确实要求安全目标和要求来处理它们。使用 ISO 26262 的汽车安全完整性等级 (ASIL) 风险分类方案，为处理每个威胁安全的安全问题而采取的行动需要与风险成正比。

尽管如此，为了确保安全性，嵌入式系统的开发人员必须考虑到应用程序代码只是一个重要的组件，并且在开发该代码时，可以部署安全关键代码开发人员熟悉的许多技术，并具有更强的安全性。

然而，除了开发之外，连接性还为每个新发现的漏洞赋予系统维护新的意义，因为软件需求和安全漏洞在开发之后以及只要产品在现场使用时就有可能发生变化。对于汽车，这可能长达 10 年或更长时间。

保护应用程序代码安全的嵌入式系统不仅仅是确保应用程序代码的安全。安全强化 *** 作系统、虚拟机管理程序、分离内核和引导映像完整性验证等技术都发挥着至关重要的作用。这些技术不仅提供了针对侵略者的多层次防御，而且还可以以相互支持的方式使用。

例如，当使用分离内核或管理程序以多域架构部署汽车系统时。域分离方法将高度关键的应用程序与系统中更普通的部分分开，为安全系统提供了有吸引力的基础。但是该底层架构将存在优点和缺点。

风险分析的使用有助于系统地揭示弱点，这些弱点可能存在于以下领域：

不同域之间的接口

从网络外部访问文件的接口

向后兼容的接口

旧协议，有时是旧代码和库，以及难以维护和难以测试的多个版本

自定义应用程序编程接口 (API)

安全码

加密、身份验证和授权会话管理

采用这种专注的方法有助于确保即使在现有代码部署的地方，如果解决高风险区域以支持安全架构，那么整个系统可以变得足够安全，而无需诉诸于重写每个组件部分的不切实际的极端.

安全可靠的应用程序代码开发确保软件开发安全的传统方法往往是被动的：开发软件，然后使用渗透、模糊测试和功能测试来暴露任何弱点。有用的是，孤立地遵守诸如 ISO 26262 之类的功能安全标准是不够的。该标准隐含地要求从一开始就考虑具有安全含义的安全因素，因为安全关键系统不可能是安全的如果它不安全。

常见的 V 模型在这方面很有用。该模型交叉引用了 ISO 26262 标准和可能在当今高度复杂和复杂的汽车软件开发的每个阶段部署的工具（图 1）。出于本文的目的，此模型有助于作为参考，了解引入安全视角如何影响每个阶段。请注意，其他流程模型（例如敏捷和瀑布）同样可以得到很好的支持。

图 1：交叉引用 ISO 26262 和标准开发工具的软件开发 V 模型。

系统设计阶段的产品（左上）包括细化并分配给硬件和软件的技术安全要求。在连接的系统中，这些将包括许多安全要求，因为为处理每个威胁安全的安全问题而采取的行动需要与风险成比例。在这些需求和后续阶段的产品之间保持可追溯性通常会导致项目管理头痛。

软件安全需求的规范涉及它们从系统设计中的推导，隔离软件特定的元素，并详细说明较低级别的软件相关需求的演变过程，包括那些具有安全相关元素的需求。

接下来是软件架构设计阶段，可能使用 UML 图形表示。静态分析工具通过提供代码组件之间关系的图形表示来帮助与预期设计进行比较（图 2）。

图 2：静态分析工具提供代码组件之间关系的图形表示，以便与预期设计进行比较——在本例中，是控制和数据流之间的关系。

显示了来自 ISO 26262-6:2011 的与软件单元设计和实施有关的表格的典型示例（图 3）。它显示了在实施过程中要强制执行的编码和建模指南，并附有指示可以在自动化工具的帮助下确认合规性的地方。

图 3：ISO 26262 编码和建模指南。

“语言子集的使用”（表中的主题 1b）举例说明了安全考虑对流程的影响。语言子集传统上被视为对安全的帮助，但对 MISRA C:2012 标准和安全特定标准（如通用弱点枚举 (CWE)）的安全增强反映了人们对它们在解决安全问题中必须发挥的作用越来越感兴趣. 这些也可以通过静态分析进行检查（图 4）。

图 4：编码标准违反 MISRA C:2012 标准和安全特定标准（如通用弱点枚举 (CWE)）的安全增强可以通过静态分析进行检查。

动态分析技术（涉及部分或全部代码的执行）适用于项目集成和测试。项目测试旨在孤立地关注特定的软件过程或功能，而集成测试确保当单元根据软件架构设计协同工作时满足安全、保障和功能要求（图 5）。

图 5：项目测试界面显示软件界面如何在功能范围内公开，允许用户输入输入和预期输出以形成测试工具的基础。

在一个好的测试工具套件中，软件接口在功能范围内公开，允许用户输入输入和预期输出以形成测试工具的基础。然后在目标硬件上编译和执行该线束，并比较实际输出和预期输出。这种技术不仅可以根据功能、安全和安全要求显示功能正确性，而且还可以显示对边界条件、空指针和默认切换情况等问题的d性——所有重要的安全考虑因素。

除了显示软件功能正确之外，动态分析还用于生成结构覆盖率度量。安全标准 CWE 要求使用代码覆盖分析来确保不存在旨在增加应用程序攻击面和暴露弱点的隐藏功能。

管理无限的开发生命周期双向可追溯性原则贯穿整个 ISO26262 V 模型，每个开发阶段都需要准确反映之前的开发阶段。理论上，如果遵循标准的确切顺序，那么需求永远不会改变，测试也永远不会抛出问题。但生活不是这样的。

例如，很容易想象这些过程与“绿地”项目相关。但是，如果需要集成许多不同的子系统怎么办？如果其中一些是预先存在的，并且要求以不同的格式定义怎么办？如果其中一些系统是在没有考虑安全性的情况下编写的，假设是一个孤立的系统怎么办？如果不同的子系统处于不同的开发阶段怎么办？

然后是需求变化的问题。如果客户改变主意了怎么办？一个好主意？律师建议现有方法可能存在问题？

如果需要更改，则需要重新静态分析修改后的代码，并且需要重新运行所有受影响的单元和集成测试（回归测试）。尽管这可能会导致当时的项目管理噩梦，但在一个孤立的应用程序中，它的持续时间比产品正在开发的时间长一点。

连通性改变了这一切。每当发现一个新的漏洞时，就会导致满足它的需求变化，再加上额外的压力，即如果产品在现场不受到损害，那么快速响应可能至关重要。

自动化的双向可追溯性将来自许多不同来源的需求链接到设计、编码和测试。任何需求更改的影响——或者实际上是失败的测试用例的影响——都可以通过影响分析来评估并相应地解决。工件可以自动重新生成，以提供持续符合 ISO 26262 的证据（图 6）。

在开发传统的、孤立的系统时，这显然是足够有用的。但是连通性需要对漏洞做出响应的能力，因为每个新发现的漏洞都意味着一个变化的或新的需求，并且需要立即响应——即使开发工程师可能已经有很长一段时间没有触及系统本身了。在这种情况下，能够隔离所需内容并仅自动测试已实现的功能变得更加重要。