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

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

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

虽然如果底层架构不安全，安全应用程序代码对保护连接的嵌入式系统几乎没有作用，但它确实在考虑安全性的系统中发挥了关键作用。

纵深防御和 V 模型

传统上，安全代码验证的实践在很大程度上是被动的。代码是按照有些松散的准则开发的，然后进行性能、渗透、负载和功能测试以发现漏洞，这些漏洞稍后会修复。

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

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

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

尽早并经常测试

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

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

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

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

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

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

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

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

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

提供双向追溯

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

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

图 3：双向追溯

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

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

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

实践中左移

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

审核编辑：郭婷