软件供应链是指在整个开发生命周期中以某种方式连接到软件代码的所有事物和每个人。每个软件都由多个组件组成。除了从头编写的专有代码之外，代码还需要外部软件基础设施、云服务、操作系统才能正常工作。注册表、存储库、代码库，甚至编写该软件的人员都是软件供应链的一部分。
这个复杂链中的每个节点都是潜在的漏洞点，可能会在某些方面影响软件的性能和安全性。此依赖链中任何一点引入的漏洞都会对下游产生严重影响。这是因为软件供应链的复杂性掩盖了风险，并且如果没有用于保护供应链的标准化框架，就很难预测和识别。这就是为什么开发人员和产品组织必须 了解什么是软件供应链安全。
软件供应链安全是指从应用程序开发到持续集成和部署（CI/CD 管道）的整个软件开发生命周期中保护您的软件免受潜在漏洞影响的一组标准化实践。
安全团队了解并遵循软件供应链安全最佳实践列表非常重要，以确保组织的软件供应链安全。这篇文章详细介绍了您应该了解的供应链最佳实践。
确保软件供应链安全的最佳实践
本节引用了开发人员和产品组织为确保其软件供应链安全而需要遵循的标准实践。您可以使用这些指南作为基本框架来描述、评估和衡量您的组织在软件生命周期的不同阶段的安全实践。这些最佳实践贯穿软件供应链的采购、开发和部署阶段，以确保开发环境、源代码和最终产品的完整性。
获取安全可靠的组件
将第三方组件合并到软件中是开发人员的标准做法，因为这使他们能够利用现有的 API 功能来提供所需的功能，而不是从头开始构建。第三方组件可以是商业专有软件或免费开源工具的形式。在采购这些组件中的任何一个时，重要的是要将安全性视为软件组件必须满足的最重要标准之一。
为了确定第三方组件的安全性，您可能需要进行高级安全分析，例如安全组合分析、漏洞数据库分析、源代码评估和风险评估分析。这些检查的结果将有助于确定该组件是否安全以及是否应允许用于您的产品
此外，需要使用自动漏洞跟踪服务持续监控选定的组件，以尽快识别漏洞并及时删除它们。
遵循安全编码实践在内部创建安全软件组件
尽管集成到软件中的外部软件组件很重要，但软件产品的安全性和完整性也取决于您内部遵循的安全编码实践。
每个组织都需要一个全面的软件开发生命周期框架，其中包含安全编码实践，以确保创建的工件符合规定的准则。
首先，软件产品和内部构建的工件的完整性取决于团队的质量。您的开发团队应包括开发专家、质量保证、网络安全专业人员以及熟悉标准安全实践的构建工程师。
产品管理团队还应包括安全架构师、产品经理和产品负责人，以确保遵守安全开发策略。确保您在内部创建安全软件工件的一些基本策略包括：
- 为每个工件生成设计和架构文档
- 为软件产品创建威胁模型
- 定义和实施安全测试
- 设定评估产品的具体发布标准
- 建立每个产品的漏洞处理策略
- 记录和发布每个软件版本的安全程序
使用安全的第三方软件工具链和兼容性库
软件开发过程中使用的许多集成开发环境（IDE）都是独立的。这意味着它们允许您在开发过程中执行各种步骤，例如编码、编译、打包和调试代码——所有这些都来自同一个工具。一些 IDE 还具有将源连接到外部存储库的工具。具有此功能的IDE支持多种编译语言。除了这些核心功能之外，开发人员还可以通过插件扩展他们使用的 IDE 的功能。由于此类不可信来源的复杂性，这是本地开发环境的潜在漏洞来源。
为了确保您的开发环境安全，环境中使用的所有 IDE 和插件在扫描漏洞和验证后都必须经过审核和预先批准。
除了扩展构建环境功能的插件之外，您可能需要检查漏洞的另一类第三方构建工具是软件工具链和兼容性库。这些第三方操作系统工具安装在开发环境中，允许您使用该操作系统特有的特定实用程序和命令。例如，Windows 开发环境在构建过程中可能需要一些 Linux 操作系统特有的操作系统命令，以便在生产过程中提供两个系统之间的兼容性。
同样，API转换库还可以帮助您为两个不同的操作系统创建通用的编码环境。这些 API 工具链是开源和商业工具，在将其用于您的构建环境和项目之前，需要先访问它们以查找漏洞。
减少内部人员对源代码的修改或利用
根据网络安全和基础设施安全局 (CISA) 的定义，内部人员是指有权访问组织资源或了解组织资源的任何人。拥有或曾经访问您的设施、网络、设备和系统的个人可能会有意或无意地危害您的软件产品的完整性。
作为保护软件安全的一部分，您必须确保开发过程制定适当的策略，以防止内部人员（例如受感染的人员、训练有素的工程师或不活跃的员工）有意或无意地暴露生产代码中的恶意代码。您可以采取一些措施来缓解这种情况，包括：
- 平衡且经过验证的源代码签入流程
- 自动安全扫描漏洞
- 安全软件开发培训
- 强化开发环境
- 优先考虑代码审查
存储代码或可执行文件并在批准之前审查所有更改
版本控制是有助于维护软件完整性的标准实践之一。作为持续集成和部署流程（CI/CD 管道）的一部分，您需要维护一个存储库来存储代码和可执行文件。这提供了代码的工作历史记录，以便您可以轻松跟踪到目前为止开发堆栈中的内容。
您还需要一个持续的审批系统来审查对软件所做的所有更改，然后才能获得批准。当与团队内的其他开发人员协作时，这特别有用。在这种情况下，解决问题会更容易，因为您可以轻松识别正在进行的更改以及更改的执行者。
无论您正在构建的软件有多简单或多复杂，源代码或版本控制系统都可以轻松查看和跟踪对代码所做的所有更改，在需要时跟踪版本历史记录，甚至恢复到早期版本必要时编码。
为创建的每个软件包创建并维护 SBOM
这款 软件物料清单 是重要的文档，详细介绍了集成到您的软件产品中的所有第三方组件。 SBOM 可以轻松验证软件的所有已批准组件并轻松识别任何漏洞或缺陷。对于您创建的每个软件包，您还应该为其创建和维护一个 SBOM。
软件物料清单可以根据标准格式定义的规范来准备，例如分别由 Linux、OWASP 和 NIST 定义的软件包数据交换 (SPDX)、CycloneDX 和软件标识 (SWID) 标签。
对于您构建的每个软件产品，您使用的第三方组件的供应商或所有者应提供全面的软件物料清单。您的项目的可交付成果和供应商提供的 SBOM 也可以使用成分分析 (SCA) 工具进行验证。
即使供应商不提供SBOM，用软件构成分析工具生成的SBOM仍然可以提供描述软件的第三方组件所需的信息。的过程 生成SBOM 应该是自动化的。 SBOM自动化 至关重要，因为每次修改第三方软件时，第三方供应商和开发人员都需要生成新的 SBOM，而手动执行此操作是不切实际的。更新后的 SBOM 将描述组件代码中的任何增强或更改及其与组件的关系软件产品。
强化构建环境
确保软件完整性的方法之一是强化开发环境以防止潜在的漏洞。这包括单个开发人员环境和整体生产构建环境。
无论您的构建环境是托管在云中还是本地，您都需要对其进行配置并采取措施来保护服务器和网络，同时还控制谁有权访问哪些内容。通过这种方式优化和保护构建环境，进行尽职调查将确保源代码和最终产品的完整性。
保护构建管道的安全涉及保护您在产品构建过程中使用的所有系统的安全。这包括代码存储库、签名服务器、工程工作站、部署服务器等。您可以采取的一些措施来保护构建管道基础设施的安全，包括：
锁定系统
为了保护您的系统，您应该将系统操作限制为系统要执行的特定功能。例如，您的构建系统应该仅用于构建操作，而不能用于其他用途。
限制外部和 LAN 外网络活动
入站和出站网络活动都可能使您的系统暴露于 攻击。您应该阻止所有外部和 LAN 外活动，并限制与必要 URL 的外部连接。
监控系统数据泄露
为了确保产品源代码的完整性，您应该设置网络安全防御措施，以保护您的存储库、工作站和构建环境的其他部分免受数据的渗透和渗透。这包括阻止所有恶意行为、隔离应用程序以及设置检测系统以在任何入侵发生时立即捕获它们。
配置您的版本控制管道
您的代码管道应该受到版本控制。在对产品进行任何更改时，应该对配置代码进行更新，而不是对实际系统进行更新。
多因素认证
构建环境中的每个系统都应尽可能配置多重身份验证。还应该采取其他安全措施，例如基于角色的访问、最小权限等。 NIST 指南还建议对构建环境中的所有关键或敏感系统采用双重授权系统。
隔离您的工程网络
您的构建系统只能通过与组织其他网络不同的隔离工程网络进行访问。在可能的情况下，工程网络应处于离线状态。
分析每个漏洞以收集足够的信息来计划其修复
开发软件时，必须采取措施确保您的产品及其所有组件不存在已知的高风险漏洞。同样，当客户发现或报告新漏洞时，您应该立即响应该事件。在某些情况下，这将要求您更新系统以减轻与新发现的漏洞相关的风险。
软件供应商应制定适当的流程，接受来自第三方研究人员或客户的有关其产品中潜在漏洞或缺陷的更新或报告。您还需要一个自动化系统，通知您有关受信任组织（例如网络安全和基础设施安全局 (CISA)）宣布的漏洞更新的信息。
每个组织都需要符合标准准则的内部漏洞管理策略。应根据您的产品及其可能受所报告漏洞影响的组件之间的关系来评估有关高风险威胁的警报。您的工程团队还必须拥有一个全面的系统来检查、诊断和可能解决问题
组件维护
软件产品及其组件从来都不是静态的。您应该记住，供应商可能会定期修改或更新集成到您产品中的第三方组件。您应该监控这些修改，尤其是当它们与常见漏洞和暴露 (CVE) 相关时。
维护软件组件的一个重要部分是监控标准 CVE 报告机制和其他支持渠道，以确定产品中包含的第三方组件中新发现的漏洞是否会影响您自己系统的完整性，并采取适当的措施来降低风险（如果有的话）。
选择要包含在产品中的第三方组件时，您应该检查合同，以确保组件的所有者制定了有关如何通知产品组织有关其系统更新、漏洞存在以及漏洞出现时间范围的政策解决方案以及您可能需要执行的任何操作以确保最佳安全性。