持续保证：软件供应链安全的整体实践

本篇 是研究新 NIST SP 800-218 指南的系列文章中的第二篇。第一篇文章可以找到 点击这里.

持续保证：
软件供应链安全的整体实践

正如我们在上一篇文章中讨论的那样，美国国家标准与技术研究所 (NIST) 制定的指导方针将极大地改变向美国政府提供软件产品和服务的方式。 

具体而言， NIST SP 800-218 建立了一套高级安全软件开发实践，这些实践将集成到每个软件开发生命周期（SDLC）中。将这些实践纳入整个软件供应链预计将促进更安全的产品和服务不仅交付给美国政府，而且最终交付给各个行业和全球各地。 

在本文中，我们将探讨持续保证 (CA) 在满足这些新要求方面的关键作用。 

概述：什么是持续保证，它是如何运作的？ 

CA 是一个概念和一组正在制定的解决方案，是对 DevOps 学科已经熟悉的持续集成、开发和测试概念的补充。 CA 精细地收集有关开发生命周期中所有事件的证据，包括可能影响最终软件产品安全的产品构建和部署。它是软件消费者（例如用户、购买者和其他风险利益相关者）控制其使用的产品风险的一种手段。 

如今，企业应用大量安全工具来提高其开发的软件产品的安全性。然而，他们很少使用总体策略来为这些工具的一致使用设定标准。此外，如果软件产品的消费者来自另一个组织，他们就没有设置风险标准所需的信息或工具。简而言之，这就是CA要消除的软件供应链盲点。 

CA 的直接成果是确保软件产品不被篡改，并在开发过程中执行关键的安全相关测试，但从中可以获得更多好处。

为了阻止攻击者或供应商掩盖来自可疑来源（例如来自被禁止国家/地区）的底层组件的篡改，CA 通过对信息进行加密签名并将其存储在不可变的存储中，将收集到的证据转化为防篡改证明。隔离的安全环境。 

通过使收集到的证据变得机器可读，策略引擎可以持续验证风险利益相关者为每个产品版本或更新设置的规范或规则。这样，利益相关者就可以确信产品符合其安全标准。 

从概念上讲，使用 CA 方法也可以提高产品质量。通过使用特定产品管道的中央策略来控制代码审查和安全测试的基线标准，将消除对有序流程的不一致和临时更改。

为什么是连续的？

开发过程中的安全配置并不是什么新鲜事。例如，您可能已经确定，未经漏洞扫描，任何二进制文件都不会投入生产。 

如今，软件交付周期变得越来越短。因此，可能会偷工减料。可能会跳过代码审查，或者可能不会执行安全测试或重要过程。此外，新的 CVE 和漏洞一直在报告，新的组件版本也在不断发布。 

所有这些因素结合在一起，要求我们根据设定的安全标准不断测试组件，以验证所使用的流程仍然符合安全策略。 

安全策略由风险承担者确定。以下是可能采用的策略规则的一些示例： 

• 仅允许使用批准列表中的开源软件包
• 每个拉取请求都需要两名审阅者。
• 验证最终工件中的所有专有组件是否可以追溯到源代码控制存储库。

提高软件安全门槛

软件供应链攻击改变了软件组件的预期行为。如今，这些攻击依赖于软件消费者和生产者缺乏验证软件组件完整性的能力。 

然而，通过签署开发生命周期各个部分的证据（从开源依赖项到最终产品）并不断将此证据与预期进行比较，攻击者在尝试篡改文件、工具或应用程序时将面临更大的困难。 CI/CD 管道的预期行为。     

收集证据：示例和建议

以下是可以通过 SDLC 收集的一些证据示例：

根据这些证据，可以使用以下政策类型：

持续代码保证的未来

在 2022 年 XNUMX 月安全软件开发框架中（SSDF），NIST 建议在整个开发过程中实施安全工具应高度依赖自动化。我们的持续保证方法与此建议一致。 

即使您确定所有安全步骤和防护措施都已正确配置，您仍然必须提供方法来向客户和供应商保证您的安全策略得到一致和持续的执行。所有利益相关者、软件生产者（开发者或供应商）和消费者（用户或购买者）都应该能够持续、自动地检查和验证软件供应链中每个环节的证据，以确保满足他们自己的安全标准。 

目前对软件供应链的信任度很低，这一直是所有利益相关者的担忧之源。提高已实施的安全措施的可见性并提供持续代码保证的证据对于重建软件供应链中的信任和生产可验证的更安全的产品至关重要。