DevSecOps 为嵌入式安全带来深度防御

虽然连接的系统带来了更容易的监控、升级和增强，但它们也呈现出更易受攻击的表面。防御此类攻击可能很困难。

应用多个安全级别——例如，正确加载图像的安全启动、域分离和减少攻击面——确保如果一个级别失败，其他级别仍然存在。虽然单独的安全应用程序代码无法在不安全的环境中提供足够的保护，但它确实在设计时考虑到安全性的系统中发挥了关键作用。

无论首选的开发生命周期如何，这都是正确的。因此，嵌入式开发团队越来越多地接受 DevOps 原则，而其他人则更喜欢传统上与功能安全标准相关的 V 模型，例如航空航天的 DO-178C、汽车的 ISO 26262 和医疗设备的 IEC 62304。

从 DevOps 到 DevSecOps 深度防御

DevOps 方法整合了开发和运营团队，专为应对不断变化的环境而设计。DevOps 为许多嵌入式应用程序带来了明显的好处。例如，通过更集成的产品开发可以更快地满足新的市场需求，也许最重要的是，应用程序补丁和更新（例如汽车软件的无线 (OTA) 安全性）可以比其他方法更快地应用。

DevSecOps（代表开发安全操作）以“左移”原则扩展了 DevOps 原则，在每次软件迭代中尽早并持续地设计和测试安全性。

纵深防御和过程模型

传统上，安全嵌入式代码验证的实践在很大程度上是被动的。代码是按照相对宽松的准则开发的，然后进行性能、渗透、负载和功能测试以识别漏洞。

更主动的方法可确保代码在设计上是安全的。这意味着一个系统的开发过程，其中代码是根据安全编码标准编写的，可以追溯到安全要求，并经过测试以证明随着开发的进展符合这些要求。

这种主动方法的一种解释是将与安全相关的最佳实践集成到功能安全领域的开发人员熟悉的 V 模型软件开发生命周期中。由此产生的安全软件开发生命周期 (SSDLC) 代表了以安全为中心的应用程序开发人员的左移，确保漏洞是在系统之外设计的（图 1）。

图1 V模型中安全测试工具和技术的使用基于安全软件开发生命周期（SSLDLC）框架。资料来源：LDRA

尽管 DevSecOps 和 SSDLC 的上下文不同，但向左移动对两者来说意味着相同的事情——早期和持续的安全考虑（图 2）。

图 2 DevSecOps 流程模型利用安全测试工具和技术。资料来源：LDRA

左移：这意味着什么

任何开发安全关键型应用程序的人都应该熟悉“左移”原则背后的概念，因为多年来，功能安全标准要求采用类似的方法。因此，在功能安全领域证明的以下最佳实践也适用于安全关键型应用程序：

从一开始就确定要求

未记录的需求会导致各方沟通不畅，并造成返工、更改、错误修复和安全漏洞。为确保项目顺利开发，所有团队成员必须以相同的方式了解产品的所有部分及其开发过程。明确定义的功能和安全要求有助于确保他们这样做。

这样的要求可能会为 V 模型开发人员定义一个完整的系统，而对于那些应用 DevSecOps 的人来说，这只是一个迭代。但是，原理保持不变。这并不是说软件永远不能用作“智力模型粘土”来创建概念验证，而是这种实验的最终结果应该是明确定义的需求——并适当地开发生产代码来满足这些需求。

提供双向追溯

双向可追溯性意味着追溯路径既向前又向后维护，而自动化使在不断变化的项目环境中维护变得更加容易（图 3）。

图 3 自动化使双向可追溯性更易于维护。资料来源：LDRA

前向可追溯性表明所有需求都反映在开发过程的每个阶段，包括实施和测试。可以通过应用影响分析来评估更改的需求或失败的测试用例的后果。然后可以重新测试修订后的实施，以提供继续遵守双向可追溯性原则的证据。

向后追溯，它突出显示不满足任何指定要求的代码，同样重要。否则，疏忽、错误逻辑、功能蔓延和恶意后门方法的插入可能会引入安全漏洞或错误。

安全嵌入式应用程序的任何妥协都需要更改或新的要求，并且需要立即响应——通常是源代码开发工程师很长时间没有触及的内容。在这种情况下，自动可追溯性可以隔离所需内容并仅对受影响的功能进行自动测试。

使用安全语言子集

对于 C 或 C++ 开发，研究表明大约 80% 的软件缺陷源于大约 20% 的语言的不正确使用。为了解决这个问题，开发人员可以使用通过禁止有问题的结构来提高安全性和安全性的语言子集。

两个常见的子集是 MISRA C 和卡内基梅隆软件工程学院 (SEI) CERT C，它们都可以帮助开发人员生成安全代码。这两个标准具有相似的目标，但实施方式不同。

一般来说，使用 MISRA C 开发新代码会导致更少的编码错误，因为它具有基于第一原则定义的更严格、更可判定的规则。参照 MISRA C 编码标准快速轻松地分析软件的能力可以提高代码质量和一致性，并缩短部署时间。相比之下，当开发人员需要追溯应用规则来编码时，CERT C 可能是一个务实的选择。针对 CERT C 分析代码可识别大多数软件安全攻击背后的常见编程错误。

应用 MISRA C 或 CERT C 会产生更安全的代码。在任何显着大小的代码库上手动执行此类标准是不切实际的，因此需要静态分析工具。

遵守以安全为中心的流程标准

在安全关键领域，适当的标准经常补充那些关注功能安全的标准。例如，J3061“网络物理车辆系统的网络安全指南”——即将被 ISO/SAE 21434“道路车辆——网络安全工程”取代——补充了汽车 ISO 26262 功能安全标准。如果需要，自动化开发工具可以集成到安全关键系统的开发人员工作流程中，并且可以同时满足功能安全需求。

自动化 SAST（静态）和 DAST（动态）测试过程

静态分析是涉及自动检查源代码的测试制度的统称。相比之下，动态分析涉及部分或全部源代码的执行。此类技术对安全问题的关注分别导致静态应用程序安全测试 (SAST) 和动态分析安全测试 (DAST)。

在这些分组中存在很大差异。例如，渗透、功能和模糊测试都是黑盒 DAST 测试，不需要访问源代码即可实现其功能。黑盒 DAST 测试是对白盒 DAST 测试的补充，白盒测试包括单元测试、集成测试和系统测试，以通过动态分析揭示应用程序源代码中的漏洞。

尽早并经常测试

所描述的所有与安全相关的工具、测试和技术在每个生命周期模型中都有一席之地。在 V 模型中，它们在很大程度上类似于和补充通常与功能安全应用程序开发相关的过程。

在 V 模型的情况下，需求可追溯性在整个开发过程中得到维护，在 DevSecOps 模型的情况下，需求可追溯性在每个开发迭代中得到维护。

一些 SAST 工具用于确认遵守编码标准，确保将复杂性保持在最低限度，并检查代码是否可维护。其他用于检查安全漏洞，但仅限于在没有执行环境上下文的情况下对源代码进行此类检查的范围内。

白盒 DAST 使编译和执行的代码能够在开发环境中进行测试，或者更好的是，在目标硬件上进行测试。代码覆盖有助于确认代码满足所有安全和其他要求，并且所有代码都满足一个或多个要求。如果系统的关键性需要，这些检查甚至可以达到目标代码级别。

可以在单元测试环境中使用健壮性测试来帮助证明特定功能是有弹性的，无论是孤立的还是在其调用树的上下文中。传统的模糊和渗透黑盒 DAST 测试技术仍然很有价值，但在这种情况下，用于确认和展示在安全基础上设计和开发的系统的稳健性。

使用自动化工具为安全铺平道路

在开始软件开发过程之前，开发人员应该能够使用自动化工具，例如加快开发、认证和批准过程的测试软件。使用这些工具在整个生命周期内支持他们的工作，同时遵循与“左移，早期测试”方法相关的最佳实践，有助于提高互联嵌入式系统的安全性，从而继续为行业带来如此重大的变化。

审核编辑 黄昊宇