在嵌入式开发中，如果底层架构不安全，安全的应用程序代码在保护连接的嵌入式系统方面几乎不起作用，但在一个以安全性为设计理念的系统中，它确实扮演着重要角色。

纵深防御和V型模式

传统上，安全代码验证的实践在很大程度上是被动的。代码是通过遵循一些松散的指导方针开发的，然后经过性能、渗透、负载和功能测试来发现漏洞，这些漏洞稍后会被修复。

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

这种主动方法将安全相关的最佳实践集成到功能安全领域的开发人员所熟悉的V-model软件开发生命周期中。由此产生的安全软件开发生命周期(SSDLC)代表了以安全为中心的嵌入式开发开发人员的转变，并提供了一种实用的方法来确保漏洞被设计在系统之外或及时彻底地得到解决。

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

尽早并经常测试

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

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

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

图2：在DevSecOps过程模型中安全测试工具和技术的使用[1]

在V模型的情况下，需求可追溯性在整个嵌入式开发过程中得到维护，在DevSecOps模型的情况下，需求可追溯性在每个开发迭代中都得到维护(在每个图中以橙色显示)。

一些SAST(静态)工具用于确认遵守编码标准，确保复杂性保持在最低水平，并检查代码是否可维护。其他的用于检查安全漏洞，但是仅限于在没有执行环境的情况下对源代码进行这种检查。

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

健壮性测试可以在单元测试环境中使用，以帮助证明特定的函数是有弹性的，无论是在它们的调用树的上下文中。

在嵌入式开发中，传统上与软件安全相关的模糊和渗透黑盒测试技术仍然具有相当大的价值，但在这种情况下，这些技术被用于确认和演示在安全基础上设计和开发的系统的健壮性。

提供双向可追溯性

软件工程术语的IEEE标准词汇表将可追溯性定义为“在开发过程的两个或更多产品之间建立关系的程度，尤其是相互之间具有前任-继任者或主从关系的产品。”双向可追溯性意味着可追溯性路径被向前和向后维护(图3)。

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

图3：双向可追溯性

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

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

重要的是要记住，一个安全的嵌入式工件的生命周期一直持续到这个领域中的最后一个例子不再被使用。对这样一个工件的任何妥协都需要一个响应，一个变更的或者新的需求，一个需要立即响应的需求——通常是对开发工程师很久没有接触的源代码。在这种情况下，自动化的可追溯性可以隔离出所需要的东西，并且只对受影响的功能进行自动化测试。

实践中的左移

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