向左移动以保护连接的嵌入式系统

虽然连接的系统为更容易的监控、升级和增强带来了新的机会，但它们也带来了更容易受到攻击的攻击面。不幸的是，没有一个连接系统的单一防御可以保证不可穿透性。幸运的是，有多个安全级别可以确保如果一个级别失败，其他级别将保持警惕。

这些纵深防御方法可以包括安全启动，以确保正确的映像加载;域分离;多个独立的安全级别 （MILS） 设计原则，例如最小特权;攻击面减少;以安全为中心的测试，如静态和动态分析，最后但并非最不重要的一点是，安全编码技术。

虽然如果底层架构不安全，安全的应用程序代码在保护连接的嵌入式系统方面几乎无能为力，但在设计时考虑了安全性的系统，它确实起着关键作用。

纵深防御和 V 型模型

传统上，安全代码验证的做法在很大程度上是被动的。代码是通过遵循一些松散的指南来开发的，然后进行性能，渗透，负载和功能测试以查找漏洞，这些漏洞稍后会修复。

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

这种主动方法将与安全相关的最佳实践集成到功能安全领域开发人员所熟悉的 V-model 软件开发生命周期中。由此产生的安全软件开发生命周期（SSDLC）代表了以安全为中心的应用程序开发人员的左转，并提供了一种实用的方法，以确保漏洞被设计出来或及时彻底地解决。

相同的原则可以应用于 DevOps 生命周期，从而产生所谓的 DevSecOps。尽管 DevSecOps 和 SSDLC 之间的上下文不同，但左移对两者意味着同样的事情，即早期和持续地考虑安全性。

尽早并经常测试

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

图 1：在基于 V 模型的安全软件开发生命周期 （SSDLC） 中使用安全测试工具和技术

在 DevSecOps 模型中，DevOps 生命周期在整个持续开发过程中与安全相关的活动叠加在一起（图 2）。

图 2：在 DevSecOps 流程模型中使用安全测试工具和技术

对于 V 模型，需求可追溯性在整个开发过程中得到维护，对于 DevSecOps 模型（在每个图中以橙色显示），每个开发迭代都会保持需求可追溯性。

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

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

可以在单元测试环境中使用健壮性测试来帮助证明特定函数是可复原的，无论是在其调用树的上下文中隔离。

传统上与软件安全相关的模糊和渗透黑盒测试技术仍然具有相当大的价值，但在这种情况下，它们用于确认和证明以安全为基础设计和开发的系统的健壮性。

提供双向可追溯性

IEEE软件工程术语标准词汇表将可追溯性定义为“在开发过程中的两个或多个产品之间建立关系的程度，特别是彼此具有前置 - 继任者或主从关系的产品。双向可追溯性意味着可追溯性路径既向前保持又向后（图 3）。

自动化使得在不断变化的项目环境中保持可追溯性变得更加容易。

图 3：双向可追溯性

前向可追溯性表明，所有需求都反映在开发过程的每个阶段，包括实现和测试。可以通过应用影响分析来评估对需求或失败测试用例的任何更改的影响，然后可以对其进行处理。然后可以重新测试由此产生的实现，以提供继续遵守双向可追溯性原则的证据。

同样重要的是向后可追溯性，它突出显示了不满足任何指定要求的代码。疏忽、错误逻辑、功能蠕变以及恶意后门方法的插入都可能引入安全漏洞或错误。

必须记住，安全嵌入式工件的生命周期将一直持续到该领域的最后一个示例不再使用为止。对此类工件的任何妥协都需要响应、更改或新要求，并且需要立即响应 — 通常是开发工程师长时间未接触的源代码。在这种情况下，自动可追溯性可以隔离所需的内容，并仅对受影响的功能进行自动测试。

在实践中向左移动

左移原则所采用的概念对于开发安全关键型应用程序的个人和团队来说很熟悉。多年来，功能安全标准要求采用类似的方法。因此，在功能安全领域经过验证的许多最佳实践适用于前面讨论的安全关键型应用程序，包括在开始时（V模型）或每次迭代（DevSecOps）之前建立功能和安全要求，尽早和经常进行测试，以及将双向跟踪需求应用于开发的所有阶段。

审核编辑：郭婷