正如云原生计算基金会 (CNCF)的供应链危害目录中所引用的那样，软件供应链攻击正在上升。Google、Linux 基金会、OpenSSF 等行业领导者和 NIST 等公共部门组织在过去一年左右就该主题提供了指导。
美国国家安全局 (NSA) 与网络安全和基础设施安全局 (CISA) 以及国家情报局局长办公室 (ODNI) 现在通过他们的出版物《保护软件供应链：开发人员推荐实践指南》加入了该名单。
该出版物的公告强调了开发人员在创建安全软件中所扮演的角色，并指出该指南致力于帮助开发人员采纳政府和行业的建议。持久安全框架 (ESF) 的后续版本将侧重于供应商和软件消费者，因为它们各自在更广泛的软件供应链及其弹性中发挥着独特的作用。
在高层次上，该文档分为三个部分：
- 第 1 部分：软件开发人员的安全指南
- 第 2 部分：软件供应商注意事项
- 第 3 部分：软件客户推荐
开发人员、软件供应商和客户的角色
该指南指出了开发人员、供应商和客户在更广泛的软件供应链生态系统中扮演的独特角色。
软件供应链集团的关系和活动
软件供应商及其开发团队最终可能会在上市速度与安全且有弹性的软件或支持软件的产品之间陷入两难境地。
如上图所示，这三个角色中的每一个都有其可以并且应该执行的安全活动。这些活动涵盖了从最初的安全软件开发、组合和架构一直到客户端的安全验收测试和完整性验证的各个方面。
安全软件从安全软件开发生命周期 (SDLC) 开始，该指南引用了许多团队可以使用的选项，例如美国国家标准与技术研究院 (NIST) 的安全软件开发框架 (SSDF )、卡内基梅隆大学的安全软件开发生命周期Processes和其他课程，例如最近宣布的 OpenSSF安全软件开发基础课程。
安全的软件开发过程
如何开发安全软件
该指南强调不仅要使用安全的软件开发流程，还要制作用于验证的有形工件和证明，软件生产者和消费者都可以保证与软件的安全性和弹性相关。
这些流程和活动包括最佳实践，例如威胁建模、SAST、DAST和渗透测试，还包括使用安全发布活动，例如数字签名，一个显着的例子是Sigstore的增加采用，它是签名、验证和保护软件的标准。
OpenSSF 的开源安全动员计划也提到了 Sigstore 的采用和使用作为增强对软件供应链信任的一种方法。
威胁建模得到了重要的提及，认识到在产品开发和交付期间，团队应该检查可能发生的潜在威胁场景以及可以采取哪些控制措施来缓解它们。
团队还应该建立安全测试计划和相关的发布准备标准，以确保不可接受的漏洞不会进入生产环境或接触客户。
成熟的产品团队也建立了支持和漏洞处理策略。这包括拥有一个可以提交产品漏洞的系统，以及一个能够在事件发生时做出响应并参与其中的相关事件响应团队。
鉴于开发人员对生产安全或不安全产品的影响，必须进行正式的评估和培训。确定需要哪些培训以及需要谁以指定的频率进行培训。
OpenSSF 的开源软件安全动员计划将提高安全软件开发技能的开发人员列为一个关键目标，该目标被认为是全行业的必要条件。培训主题包括安全软件开发、代码审查、验证测试以及在开发过程中使用漏洞评估工具来降低漏洞，使其成为最终产品。
上面讨论的活动和实践，例如安全开发培训、威胁建模、安全测试计划和开发的安全策略和程序，映射到前面提到的 NIST SSDF 中的活动，这将很快成为软件供应商自我证明的要求，向美国联邦政府销售软件产品时。
安全代码开发有很多方面，包括选择可以从一开始就减轻漏洞的编程语言。组织还需要解决内部威胁，这些威胁可能是受感染的工程师或只是训练有素的工程师。组织可以通过编码源代码控制流程和适当的身份验证、对代码运行静态和动态测试以及寻找暴露的秘密来减轻这些威胁。
组织还应实施夜间构建和安全回归测试，以识别和解决缺陷和漏洞。开发工作不应该是临时性的，应该通过相关的安全测试映射到特定的系统要求，以避免可能引入风险的功能蔓延。
应优先考虑代码审查，尤其是关键代码，以确保密码学等基础知识到位，并要求对资源进行权限升级和访问保护。不仅要保护代码，还要保护开发环境。
有一些值得注意的事件，例如 SolarWinds，其中开发环境可能受到损害并毒害下游消费者，因此开发人员端点、源代码存储库和 CI/CD 管道等系统应该进行威胁建模并进行漏洞评估。
开源软件 (OSS) 引入了其自身独特的风险，该指南建议使用专用系统下载、扫描和定期检查内部开发团队可以使用的 OSS 组件。NIST 在其第 4 节的改进国家网络安全行政命令指南中也提倡这一概念，并被称为连续包装。
强调的另一种做法是保护开发人员环境，使用安全的开发构建配置和安全的第三方软件工具链和库。
开发系统应该被强化并且只用于开发目的，不能访问互联网，并且只能使用预先批准的工具和软件。
该指南建议根据 NIST国家漏洞数据库 (NVD)审查CVE的第三方模块。工具和自动化可以帮助促进这一过程，甚至可以作为集成开发环境 (IDE) 的一部分使用安全依赖分析器和类似工具来识别漏洞。
强化构建环境至关重要，包括开发者网络、企业网络和内部构建环境。这减轻了来自互联网和外部恶意行为者的威胁以及完整性和验证措施，以验证没有发生破坏产品的恶意活动。
安全的构建环境
软件组件应来自已知的可信赖供应商，这些供应商应满足组织要求，并通过SPDX 或 CycloneDX SBOM 格式等方法以及供应商对漏洞的响应能力以及已建立的漏洞报告方法进行验证。
保护软件供应链的指导不仅仅是强化构建环境，还提出了使用密封可重现构建等建议。这意味着完全声明的构建步骤、不可变的引用和无网络访问，以及相同的输出和工件，无论变量元数据更改如时间戳。
软件应安全交付，包括最终组成的 SBOM 给客户。作为包验证的一部分，客户可以使用二进制分析输出来确保只有预期的软件组件到位。为了解决软件包和更新的妥协，产品和组件都可以使用散列和数字签名来进行产品分发、组件和升级。
组织还应采取措施减轻对分配系统本身的危害。这可以包括将安全措施应用于存储库和包管理器以及使用安全传输层机制。
用于保护软件供应链的其他资源
该指南包括与开发人员、供应商和客户的各种场景之间的人行横道，以实现 SSDF 中概述的特定实践。它还包括供应商、第三方供应商和最终客户之间存在的依赖关系和工件的映射。
与 SLSA (软件工件的供应链级别)框架的映射显示了指南中的具体建议如何映射到 SLSA 的各个级别，从 L1 到 L4。
最后，有一个完整的工件列表和清单将在整个 SDLC 中使用，还有一个信息参考列表，如网络行政命令、DoD 和 NIST 文档以及行业组织（如 OWASP）。
这种安全的软件供应链指南是一个关键资源，无疑将被业界用作希望为软件生产商和消费者加强其软件供应链实践的组织的首选参考。
由于本文档以开发人员为中心，因此建议行业寻找后续指南，该指南将重点关注软件供应商和消费者。
相关资源：
保护软件供应链：开发人员推荐实践指南
软件物料清单的最低要素
https://kaishi.lanzouv.com/b04p0uxng 密码: 0917
SLSA • 软件工件的供应链级别
保护任何软件供应链中的工件完整性
供应链威胁
GitHub 咨询数据库
包含 CVE 和 GitHub 的安全漏洞数据库源自开源软件世界的安全建议。
软件供应链危害目录：
供应链危害目录提供了真实示例，有助于提高认识并提供详细信息，让我们了解攻击媒介并考虑如何降低潜在风险。
此存储库包含指向软件供应链妥协文章的链接。我们的目标不是对所有已知的供应链攻击进行分类，而是捕捉许多不同类型的攻击示例，以便我们能够更好地了解模式并开发最佳实践和工具。
https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises
