OWASP Cheat Sheet Series 软件供应链安全（SSCS）防护实践指南

• 应用安全

软件几乎从不孤立开发：无论使用何种技术栈，每一款软件都嵌入在一条软件供应链（Software Supply Chain, SSC）之中。本指南以 cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.md 为核心骨架，系统梳理软件供应链的定义、威胁模型，以及覆盖源码、依赖、构建、部署运行时四个环节的缓解措施。读完本文，你将能够建立 SSC 威胁分类框架，并掌握从访问控制、日志监控、依赖评估与版本固定，到代码签名、来源验证（provenance）、临时隔离构建的完整落地清单；文中同时以本仓库自身的 CI/CD 与依赖管理实践作为佐证。

一、软件供应链（SSC）是什么

按照 NIST 的界定，一个实体的软件供应链可以定义为"一系列创建、转换并评估软件制品（software artifacts）质量与策略符合性的步骤集合"。从开发者的视角看，这些步骤横跨整个 SDLC（软件开发生命周期），并通过大量组件与工具完成。与原文档一致，下面这些组件与开发者的关联尤其密切（并非穷举）：

• IDE 与代码编辑器；
• 内部自研源代码；
• 第三方软件库；
• 版本控制系统（VCS）；
• 构建工具（Maven、Rake、make、Grunt 等）；
• CI/CD 软件（Jenkins、CircleCI、TeamCity 等）；
• 配置管理工具（Ansible、Puppet、Chef 等）；
• 包管理与包生态（pip、npm、Composer 等）。

上述每一个组件都必须被妥善保护。任何单一组件的缺陷——例如一个存在漏洞的第三方依赖、或一个配置不当的 VCS——都可能危及整条供应链。因此，想要强化软件供应链安全（Software Supply Chain Security, SCSS），开发者至少需要理解三件事：SSC 是什么、针对它的常见威胁有哪些、以及能够降低 SSC 风险的实践与技术。

二、威胁全景：四大攻击类别

SSC 的广度与复杂性决定了其威胁面同样庞大。已知威胁包括依赖混淆（dependency confusion）、上游供应商基础设施被攻陷、代码签名证书被盗、CI/CD 系统被利用等。更宏观地看，威胁可以依据其试图攻陷的供应链环节归为四类：

威胁行为体的特征同样多样。虽然 SSC 被攻陷常与高度老练的 APT 相关联，但这种"老练"并非攻击 SSC 的必要条件——尤其当攻击目标是安全实践糟糕的实体的 SSC 时。行为体的动机也五花八门：一次 SSC 利用可能造成任何组织资产的机密性、完整性或可用性损失，从而满足间谍活动、牟利等多种攻击目标。

最后必须认识到：许多 SSC 威胁具有跨实体传播的能力，这源于 SSC 内生的"消费者—供应商"关系。一旦某个大规模软件供应商（无论专有还是开源）被攻陷，其下游的众多消费实体都可能连锁受害——2020 年的 SolarWinds 事件与 2021 年的 Codecov 事件正是现实中的典型案例。

三、缓解措施与安全最佳实践

缓解 SSC 相关风险看似艰巨，实则未必。即便面对针对上游供应商的复杂攻击，单个组织仍可采取合理步骤保卫自身资产——即使其供应商已被攻陷，也能缓解风险。SSC 的某些部分可能超出开发团队的直接控制范围，但团队仍需尽己所能提升组织内的 SSC 安全水平。以下实践按"通用 / 源代码 / 依赖 / 构建 / 部署运行时"五个板块展开，与 CI_CD_Security_Cheat_Sheet.md、Dependency_Graph_SBOM_Cheat_Sheet.md、Vulnerable_Dependency_Management_Cheat_Sheet.md 等仓库内姊妹篇互为补充。

3.1 通用实践

以下实践面向多种威胁类型，是构建 SSC 安全基线的通用技术。

3.1.1 实施强访问控制

被攻陷的账户（尤其是高权限账户）是 SSC 的重大威胁。账户接管能让攻击者实施多种恶意行为，包括：向合法依赖注入代码、操纵 CI/CD 流水线执行、用恶意制品替换良性制品。因此，构建、开发、版本控制等环境必须实施强访问控制。最佳实践包括：

• 遵循最小权限与职责分离这两项基本安全原则；
• 强制启用MFA（多因素认证）；
• 定期轮换凭据；
• 确保凭据绝不以明文形式存储、传输或提交到源代码控制中。

关于凭据的集中存储、轮换与动态凭据，可进一步参阅仓库内的 Secrets_Management_Cheat_Sheet.md——该文档详细讲解了 HashiCorp Vault、AWS Secrets Manager 等方案的架构模式，并提供了 Kubernetes Sidecar 与 Serverless 轮换函数的可运行示例。

3.1.2 日志与监控

在 SSC 安全中，检测性控制（detective controls）的价值常被低估，但它们对发现攻击、促成快速响应至关重要。就 SSC 而言，日志尤为关键。SSC 中涉及的所有系统——包括 VCS、构建工具、交付机制、制品仓库、以及负责运行应用的系统——都应配置为记录认证尝试、配置变更及其他有助于识别异常行为或对事件响应至关重要的日志事件。SSC 各环节的日志必须在深度与广度上同时足够，以支撑检测与响应。

然而，仅仅记录日志并不足够。这些日志必须被监控，并在必要时被处置。考虑到 SSC 的复杂性，优先推荐集中式 SIEM、日志聚合器或类似工具。无论采用何种技术，基本目标一致：日志数据必须是可行动的（actionable）。关于 CI/CD 环境下的可见性落地细节（日志格式、敏感数据规避、SIEM 告警配置），可参考 CI_CD_Security_Cheat_Sheet.md 中的 "Visibility and Monitoring" 章节。

3.1.3 借助安全自动化

对于复杂的 SSC，安全任务的自动化（如扫描、监控、测试）至关重要。自动化虽不能替代熟练专业人员的人工评审与操作，但能以人工难以企及的规模与一致性发现、有时甚至响应漏洞与潜在攻击。支撑自动化的工具类型包括：

• SAST（静态应用安全测试）；
• DAST（动态应用安全测试）；
• SCA（软件组成分析）；
• 容器镜像扫描器，等等。

具体哪类工具能为组织带来最大价值，将因组织特性而显著不同。但无论工具类型与厂商如何，都必须认识到：这些工具本身也需要被维护、加固并正确配置。否则，它们要么无法带来有意义的收益，要么反而增加组织的 SSC 风险。同时必须清醒理解：这些工具只是整体 SSCS 项目的一个组成部分，不能被视为全面解决方案，也不应被寄望于发现所有漏洞。

3.2 缓解源代码威胁

以下实践有助于降低与源代码和开发过程相关的 SSC 风险。

3.2.1 同行评审（Peer Reviews）

人工代码评审是降低 SSC 风险的一种重要且相对低成本的技巧；评审既能充当检测性控制，也能起到威慑作用。评审应在代码被合入源代码控制系统之前进行，且应由具备所用技术经验与安全编码流程经验的同行执行。评审应同时关注：

• 非故意的安全缺陷；
• 可能服务于恶意目的的有意代码。

评审结果应被记录在案，以备日后复核。

3.2.2 版本控制系统的安全配置

源代码控制系统的失陷或被滥用，一直被公认为重大的 SSC 风险。强化 VCS 的两条途径是前文所述的强访问控制与日志监控；此外还应充分利用 VCS 系统特有的安全特性，例如 git 的受保护分支（protected branches）与合并策略（merge policies）。为管理 SCM 系统配置，也有现成工具可用，例如由 Legit security 开源的Legitify——它专门用于检测 GitHub 与 GitLab 中的错误配置，并协助落地最佳实践（例如：避免自动合并规则、强制 PR 评审且不可绕过、要求提交签名、启用 MFA、限制 fork 私有仓库等，详见 CI_CD_Security_Cheat_Sheet.md 的 "Secure SCM Configuration" 一节）。无论为 VCS 添加何种安全控制，都必须牢记：秘密绝不应被提交到这些系统中。

3.2.3 安全开发平台

IDE、开发插件及类似工具能辅助开发流程；但与其他软件一样，这些组件也可能存在漏洞并成为攻击向量。因此，不仅要确保这些工具被安全使用，还要加固底层系统：

• 开发系统应安装端点安全软件，并对其执行威胁评估；
• 开发流程中只应使用可信、经过充分验证的软件——不仅包括 IDE 这类"核心"开发工具，也包括任何插件或扩展；
• 这些工具应纳入组织的系统资产清单。

3.3 缓解依赖威胁

下面介绍与安全使用依赖相关的实践与技术。

3.3.1 评估供应商

在将第三方服务、产品或软件组件纳入 SSC 之前，供应商与具体产品都应接受彻底的安全评估——这一要求对开源与专有产品同样适用。分析的形式与深度应随被评估组件的关键性与性质而显著变化。在几乎所有情况下，以下信息都很有用：组件成熟度、安全历史、以及供应商对过往漏洞的响应方式。对于较大型的供应商或服务，考察其是否通过了第三方评估与认证（例如针对 FedRAMP、CSA STAR、或 ISO/IEC 27001、ISO/IEC 15408、ISO/IEC 27034 等 ISO 标准开展的评估）是有用的数据点，但绝不能作为唯一依据。

由于开源项目天然透明，它提供了额外的评估机会。纳入前建议审视以下问题（源自 OpenSSF 的简明指南）：

• 项目是否积极维护？
• 项目在相关社区是否足够流行与知名？
• 项目是否足够成熟？
• 所评估的产品或版本是否为release 版本（而非 alpha、beta 或同类版本）？
• 考虑到项目复杂度，维护者与贡献者数量是否充足？
• 项目是否及时更新其依赖？
• 项目是否有足够的测试覆盖，且测试是否包含与安全相关的规则？
• 项目文档是否完善，文档中是否包含安全使用该组件的方法？
• 项目是否有成熟、文档化的漏洞报告流程，且漏洞是否被及时处理？
• 项目的预期用途是否与其许可证相符？

3.3.2 理解并监控软件依赖

第三方依赖能极大加速开发，但也是现代应用面临的主要风险之一。依赖不仅在纳入应用前要谨慎选择，在整个 SDLC 期间也要被仔细监控与维护。为此，洞悉应用消费了哪些依赖是至关重要的第一步——SBOM（软件物料清单）正是实现这一洞察的利器。SBOM 的生产与消费都应自动化，最好作为组织 CI/CD 流程的一部分。关于 SBOM 的生成时机、标准格式（CycloneDX / SPDX）、签名与来源绑定、最小元素清单等落地细节，仓库内的 Dependency_Graph_SBOM_Cheat_Sheet.md 给出了非常实用的清单与命令示例。

在完成依赖清点后，组织还必须持续监控这些依赖的已知漏洞，且同样应尽量自动化。可用的工具与数据源包括：

• OWASP Dependency Check或retire.js等扫描工具；
• NVD（国家漏洞数据库）；
• OSV漏洞数据库；
• CISA KEV 目录（已知被利用漏洞目录）。

关于漏洞被发现后的分级处置（有补丁 / 无补丁需等待 / 供应商不修复 / 无法升级需自行 backport 等五种 Case），仓库内的 Vulnerable_Dependency_Management_Cheat_Sheet.md 提供了完整的决策树与可运行的 Java 防护代码示例。

3.3.3 SAST

将 SAST 用于检测自研代码中的潜在安全问题是广泛使用的技术；同样地，它也可以用于 SSC 中的开源组件。与用于内部代码时一样，必须认识到这类工具既会产生误报也会产生漏报。因此，SAST 结果未经人工验证不应被直接接受，也不应被解读为对项目安全性的全面视图。但只要理解其局限，SAST 扫描在分析内部代码与开源代码时都能发挥价值。

3.3.4 Lockfile / 版本固定

为降低被攻陷或有漏洞的版本被无意拉入应用的可能性，应将应用依赖限制在先前已验证为合法且安全的特定版本。这通常借助 lockfile 实现，例如 npm 使用的package-lock.json（以及 Pipenv 的Pipfile.lock等）。落地时还应注意：固定版本必须经过已知良好的哈希/校验和比对来验证包完整性，并强制使用 lockfile；优先使用私有仓库并配置包管理器仅使用单一私有源，利用 scoped npm 包、NuGet ID 前缀预留等机制降低依赖混淆风险；同时确保.npmrc等控制文件被提交到源代码控制并在 CI/CD 环境中可用（详见 CI_CD_Security_Cheat_Sheet.md 的 "Dependency Management" 一节）。

3.4 缓解构建威胁

本节描述对保障构建相关威胁尤为关键的技术。

3.4.1 清点构建工具

了解 SSC 中使用的组件是保障其安全的前提，这一概念同样适用于构建工具。应自动收集并维护所有构建工具的清单，包括版本与任何插件；同时持续监控漏洞数据库、供应商安全通告及其他来源，以发现与已识别构建工具相关的漏洞。

3.4.2 加固构建工具

被攻陷的构建工具可被用于实施广泛的利用，因此对攻击者极具吸引力。构建过程使用的所有基础设施与工具都必须加固。加固构建环境的技术包括：

• 确保构建工具位于适当隔离的网络中；
• 使用DLP（数据防泄漏）及其他工具与技术检测并阻止数据外泄；
• 禁用/移除任何未使用的服务；
• 使用版本控制系统管理并存储流水线配置。

3.4.3 强制代码签名

从软件消费者的视角看，只接受经过数字签名、并在使用前验证签名的组件，是确保组件真实且未被篡改的重要步骤。对于执行代码签名的一方而言，必须彻底加固代码签名基础设施；否则可能导致签名系统被攻陷，进而引发进一步利用，包括针对软件消费者的攻击。在 CI/CD 环境中，可使用 Sigstore、SignServer 等技术实施代码签名，并可引入 in-toto 框架强化端到端完整性（参考 CI_CD_Security_Cheat_Sheet.md 的 "Integrity Assurance" 章节）。同时要牢记：代码签名及相关技术并非绝对的安全保证，签名流程本身也可能被利用。

3.4.4 使用私有制品仓库

使用私有制品仓库能提升组织对 SSC 内各类制品的控制力。制品在获准进入私有仓库前应经过评审，组织还必须确保这些仓库的用途无法被绕过。虽然私有仓库会带来额外维护成本或降低敏捷性，但它们——尤其对敏感或关键应用而言——是 SSC 安全的重要组件。

3.4.5 对构建脚本与配置使用版本控制

VCS 的收益可扩展到源代码之外，对 CI/CD 流水线相关的配置与脚本尤其如此。对这些文件强制版本控制，可以将评审、合并规则等控制机制融入配置更新流程；同时，使用 VCS 还能提升可见性，使任何变更（无论恶意与否）都易于被发现。

3.4.6 验证来源（Provenance）/ 确保生成充分元数据

确保 SSC 组件来自可信来源且未被篡改，是 SSC 安全的重要一环。来源信息（provenance）——SLSA 1.0 将其定义为"关于软件制品的可验证信息，描述制品在哪里、何时以及如何被生产"——的生产与消费是其中的关键。来源信息应满足以下要求：

• 由构建平台（而非本地开发系统）生成；
• 对攻击者而言极难伪造；
• 包含将结果精确回溯到构建者所需的一切细节。

符合 SLSA 1.0 的来源信息可使用 FRSCA 或 GitHub Actions 的 slsa-github-generator 等构建器生成，并使用 SLSA Verifier 进行验证。关于 SBOM/制品与签名/证明的绑定流程（build → generate SBOM → compute digests → sign/attest → publish），Dependency_Graph_SBOM_Cheat_Sheet.md 给出了配套的 GitHub Actions 工作流示例与 Cosign 签名命令。

3.4.7 临时、隔离的构建（Ephemeral, Isolated Builds）

构建环境的复用与共享可能让攻击者实施缓存投毒或以其他方式更容易注入恶意代码。构建应在隔离、临时（ephemeral）的环境中进行：可使用 VM 或容器执行构建，并确保构建完成后立即销毁该环境。

3.4.8 限制参数使用

向构建过程传入用户可控参数虽然能提升灵活性，但也会增加风险。如果用户可以修改参数以改变构建方式，那么拥有足够权限的攻击者同样可以修改参数，并可能攻陷构建过程。因此，应尽量最小化或消除用户可控的构建参数。

3.5 缓解部署与运行时威胁

本节概述可用于在部署与运行阶段保护软件的几项技术。

3.5.1 扫描最终构建二进制

构建过程结束后，不应想当然地认为最终产物就是安全的。二进制组成分析（binary composition analysis）可以帮助检测暴露的秘密、检测未授权组件或内容、验证完整性。这项任务应由供应商与消费者双方共同执行。

3.5.2 监控已部署软件的漏洞

SSC 安全并不随软件部署而结束；已部署软件必须被持续监控与维护以降低风险。新漏洞——无论由更新引入还是新近被发现（或被公开）——都是软件系统中的持续隐忧。进行此类监控时必须采用整体性方法：代码依赖、容器镜像、Web 服务器、操作系统组件等仅是必须考虑清单中的一部分。为支撑监控，一份准确且最新的系统组件清单至关重要；此外，不安全的配置变更也必须被监控并处置。

四、仓库自身的供应链安全实践：一个可对照的实例

本仓库（OWASP Cheat Sheet Series 的文档仓库）本身就是一个小型的软件供应链，其 CI/CD 与依赖管理配置可作为前述理论的现实对照：

• 依赖自动更新：.github/dependabot.yml 配置了 Dependabot，对github-actions、npm、pip、docker四类生态按周自动检查更新，并分别分组（groups）以便统一升级——这正是"依赖监控应自动化"的直接落地。
• CI 中的完整性校验：.github/workflows/md-link-check.yml 在 push 与 PR 时执行npm run link-check，通过markdown-link-check检测文档中的失效链接；package.json 还提供了lint-markdown（markdownlint）与lint-terminology（textlint）等质量门禁，一旦失败即中断流水线。这类"扫描结果影响流水线结果"的模式，正是 3.1.3 所述安全自动化的体现。
• 扫描配置的维护：markdown-link-check-config.json 集中管理链接检查的忽略规则与 HTTP 请求头（自定义 User-Agent），说明安全工具自身的配置也需要被认真维护——呼应了原文档"工具本身必须被正确配置"的告诫。

需要说明的是，上述配置面向文档仓库，与生产软件的供应链安全场景在规模上有差异，但其自动化检查、依赖分组更新、配置纳入版本控制的思路完全一致，可迁移到任何项目。

五、结论

软件供应链安全不是单一产品、单一扫描器或一次性项目就能解决的问题，而是一套覆盖源码、依赖、构建、部署与运行时全环节的持续性工程。本指南给出了可立即上手的行动清单：从强化访问控制与日志监控做起，通过同行评审与 VCS 安全配置保护源代码，通过供应商评估、SBOM、SCA 与版本固定管理依赖，通过构建工具加固、代码签名、私有制品仓库、来源验证与临时隔离构建守护构建环节，最后在部署后持续扫描与监控。团队无需等待上游供应链的完全安全——即使供应商被攻陷，充分落实上述分层控制也能显著压缩自身风险敞口。

六、继续深入阅读（仓库内相关文档）

• Software_Supply_Chain_Security_Cheat_Sheet.md——本文的原始骨架文档
• CI_CD_Security_Cheat_Sheet.md——CI/CD 流水线自身的十大风险与防护（SCM 配置、IAM、秘密管理、依赖链滥用、完整性、可见性）
• Dependency_Graph_SBOM_Cheat_Sheet.md——SBOM 生成、签名、管理及漏洞处置工作流
• Vulnerable_Dependency_Management_Cheat_Sheet.md——依赖漏洞被检出后的五类处置 Case 与工具选型
• Secrets_Management_Cheat_Sheet.md——秘密集中管理、轮换与内存安全
• NPM_Security_Cheat_Sheet.md——npm 生态的 lockfile 强制与依赖安全

• 应用安全