在互联汽车开发生命周期中构建安全性-电子发烧友网

一架波音 787 飞机包含大约 650 万行软件。令人印象深刻的是，直到您意识到现代汽车平均有 2000 万行代码，才能使客机超过三倍。虽然人类生命和安全取决于两个系统中软件的正常运行，但汽车行业在确保功能安全性方面落后于航空航天。

近年来，汽车行业采用了 ISO 26262 等功能安全标准，但并未同样重视安全性。根据BI Intelligence的数据，现在该行业正在迎头赶上，预计联网汽车的数量将从 2015 年的 3600 万辆增长到 2020 年的 3.81 亿辆，测试继续显示联网汽车的安全漏洞。

从客户（驾驶员）的角度来看，确保安全和安全的责任落在了汽车制造商身上。反过来，这些 OEM 依赖于一级和二级供应商提供一系列电子控制单元（ECU）、车联网（V2X）通信、高级驾驶辅助系统（ADAS）和信息娱乐系统。现在，这些系统中的每一个都连接到一个通用的车辆网络（图 1），每个系统都有助于不断扩大的攻击面。分离内核和管理程序等安全方法可以通过提供运行时分离和隔离在一定程度上缓解该问题，但它们不能提供安全保证——仅仅是一道防线。

最佳实践表明，安全性（如功能安全性）不能是事后才想到的。它必须是整个软件开发生命周期的一部分。

需求是安全软件开发生命周期的一部分

安全开发生命周期始于 OEM 向一级和二级供应商提出的特定安全要求。然后必须将这些要求应用于开发过程和生产的软件。必须向 OEM 验证和证明过程和生成的软件方面的结果，以便 OEM 可以验证整个车辆及其系统是安全的。

只有可以跟踪和验证要求才有意义，而实施这些要求依赖于遵守必须不断检查和验证的实践和标准。可以将安全编码实践和标准与策略（整体方法）和策略（详细执行）进行比较。不遵守其中任何一个都可能导致危害安全的错误。幸运的是，可以使用适当的自动化测试工具和方法来检测这些错误。

计算机应急准备小组（ CERT ）网站列出了 12 种安全编码实践，可被视为战略编码方法或安全要求。它们包括诸如“验证输入”和“注意编译器警告”等建议，同时使用编译器的最高警告级别。另一条建议是“保持简单”，这可以通过圈复杂度等指标进行测试。这突出了比预期更复杂的函数，因此任何超出指定范围的复杂度值都可以证明是合理的，目的是创建更清晰、更可维护和更可测试的代码。12 项实践中的另一个关键建议是采用安全编码标准。

采用安全编码标准

编码标准规定了使用特定语言（例如 C 或 C++）编写安全代码的特定规则和指南（策略）。其中一个编码标准是 CERT C，它有 98 条规则用于开发安全、可靠和可靠的系统。规则按部分分组，涵盖字符串、内存和表达式等内容。MISRA C 和 MISRA C++ 是另外两种在汽车行业广泛使用的流行编码标准。这些 MISRA 标准始终针对“关键”代码，这意味着它们始终适用于安全和安保关键系统。MISRA C:2012 修正案 1 通过引入 14 条专门针对安全的新指南进一步强调了这一点。

编码标准处理为安全系统正确使用高级语言的细节，限制编码结构以最大限度地减少潜在漏洞。使用标准的一个好处是可以使用静态分析工具检查源代码是否符合所选标准，最好在整个开发过程中进行。

结构性覆盖提供信心

保护联网汽车及其广泛多样的攻击面是一项艰巨的任务。例如，可以通过信息娱乐系统、GPS、ODB2 诊断端口或软件/固件更新过程进行访问。一旦车载网络被破坏，安全关键系统（如安全气囊、制动、转向、传输和防撞）中的漏洞可能会被暴露和利用。任何这些系统中的编码错误都可能导致灾难，因此开发人员必须测试安全性，然后衡量该测试的有效性。

在执行和测试编译的代码时，结构覆盖分析通过识别和突出显示哪些代码已经过测试和没有经过测试，有助于衡量测试过程的有效性。颜色编码格式化的源代码和流程图可以很容易地确定还需要做什么（图 2）。获得的覆盖范围越多，就可以确信不存在包含漏洞的代码。软件组件的安全性或安全性越关键，应应用的覆盖分析级别的要求就越高——从简单的语句覆盖到修改的条件/决策覆盖（MC/DC）。