5 Software Supply Chain Security Best Practices for Development Teams

5 软件供应链安全最佳实践 | Docker

开发团队的 5 项软件供应链安全最佳实践

发布于 2026 年 6 月 8 日

Aditya Tripathi

理解软件供应链安全是一回事，而在一个真实的流水线中，面对真实的截止日期和真实限制将其付诸实践则是另一回事。大多数组织都认识到，其软件供应链正在成为一个日益增长的攻击面，但将这种认识转化为具体、可重复的实践才是真正的难点所在。

但为什么你的团队现在就应该着手解决这个问题呢？根据 Sonatype 的数据，2025 年发现的超过 99% 的开源恶意软件都出现在 npm 上。而且，第一个自我复制的 npm 蠕虫出现了，它在几天内自主传播到开发环境，导致数百个软件包被入侵。与此同时，Verizon 的《2025 年数据泄露调查报告》发现，涉及第三方的泄露比例每年翻倍，达到 30%。

本指南聚焦于对构建和部署基于容器的工作负载的团队最重要的实践。它围绕五个类别组织，这些类别遵循软件交付的自然流程：可信内容、构建安全、部署前验证、访问和策略控制以及持续监控。这样，你的团队可以更好地应对日益自动化和复杂的攻击，从而更好地保护软件供应链。

关键要点：从可信的、最小化的基础镜像开始，并通过摘要固定所有依赖项，以消除上游漂移。使用加密证明验证构建来源，并在每次构建时生成 SBOM。将漏洞分析集成到开发人员的工作流程中，并在注册表和流水线中实施基于策略的访问控制。最有效的计划将供应链安全视为一种工程学科，而不仅仅是一个合规性检查框。

1. 从可信内容开始

选择经过验证的、最小化的基础镜像

每个容器镜像都继承其基础镜像的安全状态。如果这个基础镜像包含未修补的漏洞、过时的库或你不需要的组件，这些风险将传播到所有基于它的镜像中。第一个也是最具影响力的供应链实践是选择最小化、持续维护且可验证构建的基础镜像。

寻找附带完整 SBOM 的基础镜像，SLSA 构建级别 3 的来源证明，以及在部署前可以验证的加密签名。最小化的镜像通过移除生产工作负载很少需要但攻击者经常利用的外壳、包管理器和工具，从而减少攻击面。这就是为什么经过加固并验证来源的基础镜像成为基础实践。团队无需为每个基础镜像维护自定义的加固脚本，而是可以从那些以源代码重建并完全透明地展示其生产方式的镜像开始。

固定依赖项并验证完整性

依赖项固定是一项看似简单但极具影响力的实践，可以防止一类供应链攻击。当 Dockerfile 引用像 python:3.12 这样的标签时，该标签明天可能指向一个与今天不同的镜像摘要。上游的被篡改或意外更改会悄无声息地流入你的构建中。

通过 SHA256 摘要固定容器镜像，而不是通过标签。使用锁定文件将语言级别的依赖项（如 npm、pip、Maven）固定到确切的版本，并在 CI 中验证这些锁定文件的完整性。如果构建系统拉取依赖项时哈希值与提交的不一致，构建应失败。

• 场景聚焦：考虑一个团队，他们从一个标记为 :latest 的基础镜像进行夜间构建。某天早上，一次例行构建部署到预发布环境，集成测试开始失败。根本原因：基础镜像中的上游包更新引入了破坏性变更。通过摘要固定和明确的升级工作流程，这类问题将完全消失，更危险的变种（恶意更改未被察觉地引入）也将消失。

2. 保护构建流水线

强制执行构建来源和证明

构建来源回答了一个 SBOM（软件物料清单）本身无法回答的问题：这个工件是在哪里构建的，由什么系统构建的，以及来自什么源？没有来源信息，你可以验证镜像中包含的内容，但无法确定构建环境本身是否可信。

SLSA 框架定义了不同级别的构建完整性，从第 1 级的基本来源文档到第 3 级的强化、防篡改构建平台，生成不可伪造的来源信息。至少，构建应生成签名的来源证明，将每个工件追溯到其源提交、构建配置和构建者身份。

实际上，这意味着配置 CI/CD 系统在每次镜像构建时生成 SLSA 来源证明（通常使用 in-toto 证明格式表示）。这些证明成为部署策略在允许镜像进入生产环境之前可以验证的加密证据。

加固 CI/CD 基础设施

构建流水线本身是一个高价值目标。如果攻击者入侵了你的 CI/CD 系统，他们可以将恶意代码注入你生成的每个工件中，而你现有的检查可能无法发现，因为恶意修改发生在源代码审查之后。

关键的加固实践包括：

• 隔离构建环境，使每个作业在全新的、临时的上下文中运行，没有来自之前构建的残留状态。

• 限制构建作业可用的密钥为最小必需。

• 将 GitHub Actions 和其他 CI 插件固定到完整的提交 SHA，而不是可变的标签。

• 强制执行分支保护规则，要求在合并到发布分支之前进行代码审查和通过状态检查。

CISA 强调构建系统完整性是供应链保障的基础要素。如果你无法信任生成工件的系统，那么无论进行多少次构建后的扫描都无法弥补。

3. 部署前进行验证

持续生成和使用 SBOM

只有当软件物料清单（SBOM）准确、最新，并集成到你的决策过程中时，它才有用。在发布时生成一次 SBOM 并存档满足合规要求，但提供的安全价值非常有限。

更有效的做法是在每次构建时生成 SBOM，将其作为证明附加到镜像上，并在准入控制器、漏洞扫描器和许可证合规检查中下游使用。当一个新的 CVE 发布时，拥有最新 SBOM 的团队可以在几分钟内确定哪些正在运行的工作负载受到影响。没有 SBOM 的团队则需要开始多天的取证工作。

将 SBOM 与可利用性数据（VEX）配对，增加了另一层可操作性。VEX 文档表明，SBOM 中的漏洞在您的特定镜像上下文中是否确实可被利用，从而减少导致警报疲劳的噪音，帮助团队专注于真正重要的漏洞。

将漏洞分析集成到开发人员的工作流程中

当漏洞扫描结果在开发人员已经工作的环境中呈现时，其效果最佳，而不是在只在冲刺期间查看一次的安全仪表板中。将分析转移到内部开发循环中意味着在构建时、在拉取请求中以及在本地开发期间就标记问题，远早于镜像到达注册表之前。

这就是将持续漏洞分析集成到开发人员工作流程中变得至关重要的地方。与其将扫描结果批量汇总成每周报告，有效的程序会将发现结果与引入它们的代码更改一同呈现，并提供可操作的修复指导。

NIST 安全软件开发框架（SSDF）强化了这一模式。实践 PW.7 建议组织审查和分析可读代码，以识别漏洞并验证是否符合安全要求。将自动化分析集成到 CI/CD 中是该指导方针的可扩展实现。

4. 控制访问并实施策略

管理注册表访问和镜像策略

您的容器注册表是组织运行的每个镜像的分发点。如果开发人员可以不受限制地从任何公共注册表中拉取任何镜像，供应链将扩展到他们选择使用的每个镜像的每个维护者。

实施注册表访问控制，限制哪些镜像被批准使用，强制所有镜像都来自经过验证的发布者或内部构建，并在任何镜像进入生产环境之前要求签名验证。镜像访问管理策略确保团队可以在开发环境中自由实验，而生产环境仅使用经过审核并符合策略的镜像。

• 情景聚焦：Medplum 是一个帮助客户满足 HIPAA 和 HITRUST 要求的医疗开发平台，他们在代码库中仅添加了 54 行并删除了 52 行代码，就将他们的容器基础迁移到了 Docker 加固镜像。结果是显著减少了 CVE 数量，生产环境中默认非 root 执行，并且没有 shell 访问权限。他们还向审计人员提供了一个更清晰的故事。他们不再需要解释自定义加固脚本和每个 CVE 的例外文档，团队可以指向记录的加固方法和 SLSA 构建级别 3 的来源。

在整个管道中实施最小权限原则

供应链攻击经常利用权限过高的服务账户、范围广泛的 CI 令牌或提供比任何单个任务所需更多访问权限的共享凭据。在交付管道中实施最小权限原则意味着将每个凭据、令牌和 API 密钥的权限范围限制在特定任务所需的最低权限。

CISA 特别建议在所有开发人员和 CI/CD 账户上使用防钓鱼的多因素认证。除了认证之外，确保构建服务账户无法推送到生产注册表，部署令牌无法修改构建配置，并且没有任何单一凭据可以同时访问源代码和生产基础设施。

5. 监控、响应和改进

实施运行时监控

静态分析和构建时扫描可以发现你预期的威胁。运行时监控则能发现你未曾预料到的威胁。当供应链攻击绕过了你的预部署控制措施时，运行时异常检测是识别异常行为的关键层：一个不应进行外发通信的容器却建立了新的网络连接，一个不可变镜像中出现了文件系统修改，或者进程执行模式偏离了镜像的正常行为。

有效的运行时监控对于供应链安全来说，超越了传统的应用程序性能监控。它需要为容器工作负载建立行为基线，并在行为发生偏移时触发警报，而不仅仅是在发现已知恶意签名时触发警报。这对于检测那些在测试期间表现正常、但在特定运行时条件下激活恶意行为的被攻击依赖项尤为重要。

将事件响应构建到你的供应链计划中

当发生供应链事件时，响应速度取决于前期的准备。那些已经演练过如何应对依赖项被入侵、恶意基础镜像更新或构建系统被入侵的团队，可以在数小时内做出响应。而那些没有演练过这些场景的团队，可能需要数天时间才能应对。

你的事件响应计划应包括以下步骤：

• 确定哪些制品是使用被入侵组件生成的（这就是溯源和SBOM的价值所在）

• 撤销并轮换可能已被泄露的凭证

• 从经过验证的源重新构建受影响的镜像

• 与使用你软件的下游消费者进行沟通

一瞥最佳实践

软件供应链实践

生产环境中的表现

可信基础镜像

所有生产镜像都基于最小、已签名、已验证溯源的基础镜像构建，且几乎无CVE漏洞

依赖项锁定

容器镜像通过摘要进行锁定；语言依赖项锁定到精确版本，并通过哈希验证

构建溯源

每个制品都带有已签名的SLSA证明，链接到其源代码、构建者和构建配置

CI/CD强化

临时构建环境、锁定的CI插件、作用域限定的密钥、强制执行分支保护

持续SBOM

每次构建生成SBOM，作为证明附加，被准入和扫描工具使用

开发者集成扫描

在PR、本地构建和CI中进行漏洞分析，并提供可操作的修复指导

仓库访问管理

镜像拉取策略限制生产环境仅使用来自经过验证源的已批准、已签名验证的镜像

最小权限

每个作业限定的管道凭证；所有开发者和CI/CD账户都具备防钓鱼的多因素认证

运行时监控

为容器建立行为基线，并在检测到异常网络、文件系统和进程活动时发出警报

事件响应

针对供应链场景的文档化、演练过的响应方案，并结合溯源信息进行影响范围分析

入门

构建一个软件供应链安全计划是一项迭代性的工作。本指南中的实践代表了整体的图景，但实现路径是逐步推进的。从基础开始：可信的基础镜像和依赖项完整性。然后逐步加入构建溯源和SBOM。随着计划的成熟，再扩展到策略执行、开发者集成扫描和运行时监控。

Docker 加固镜像为实施这些实践的团队提供了一个现成的基础。数千个最小化、持续重建的镜像附带 SLSA 构建级别 3 的来源信息、已签名的 SBOM 和 OpenVEX 漏洞利用数据，使您能够获得一个值得信赖的起点，而无需维护自定义加固流程所带来的额外负担。SRLabs 的独立评估验证了 DHI 的来源链、签名模型和漏洞管理流程，以及持续加固实践。

结合 Docker Scout，它可以直接集成到您的开发流程中，实现持续的漏洞分析，您将拥有支持一个与工程组织规模相匹配的供应链安全计划的核心工具。

探索我们完整的加固镜像目录，立即开始替换您的基础镜像。

常见问题

最重要的软件供应链安全最佳实践是什么？

从受信任的最小基础镜像开始具有最大的杠杆效应，因为它减少了所有构建在其上的组件的攻击面。基础镜像中的一个易受攻击的组件可能会传播到数百个下游镜像和工作负载中。

SBOM 和构建来源信息是如何协同工作的？

SBOM 告诉你一个制品中包含什么内容。构建来源信息告诉你它是在哪里以及如何构建的。它们一起提供了所需的透明度，以评估一个制品是否可信，并在发现漏洞或入侵时迅速识别受影响的工作负载。

SLSA 框架如何与供应链最佳实践相关联？

SLSA（软件制品的供应链级别）为构建完整性提供了一个渐进的成熟度模型。它为团队提供了一条从基本的来源文档向加固、隔离的构建平台和不可伪造的来源信息的清晰路径。规范的未来版本预计会扩展到诸如密封性、可重复性和源完整性等其他领域。

漏洞扫描与运行时监控有什么区别？

漏洞扫描在部署之前识别代码和依赖项中的已知弱点。运行时监控则检测运行中工作负载的异常行为，捕捉扫描遗漏或仅在特定条件下激活的入侵。

如果团队目前没有供应链安全计划，应该从哪里开始？

从基础镜像选择和依赖项固定开始。这两个实践的实施相对容易，可以立即降低您对最常见的供应链攻击向量的暴露风险。从那里开始，添加 SBOM 生成和构建来源信息，以构建其他所有内容所需的可见性。

作者简介

Docker 高级首席产品市场经理

Aditya Tripathi 负责 Docker 安全产品组合的产品营销，专长包括安全默认值、供应链风险以及使安全对开发人员有用。

概念

Docker 加固镜像

安全

软件供应链安全

产品

目录

相关文章

• 2026 年 5 月 12 日 Docker AI 治理：安全地解锁代理自主性 介绍 Docker AI 治理：集中控制代理如何执行、它们在网络中可以访问哪些资源、可以使用哪些凭证以及可以调用哪些 MCP 工具，使公司中的每个开发人员都能在任何工作环境中安全地运行 AI 代理。您的笔记本电脑就是新的生产环境。代理是最大的生产力提升…… Srini Sekaran 立即阅读

• 2026年6月5日 什么是AI治理？框架、原则和最佳实践 了解AI治理的定义，它为何重要，以及如何安全且大规模地管理AI系统。Srini Sekaran 立即阅读

• 2026年6月4日 加固镜像解析：更少的CVE，更小的攻击面 了解什么是加固容器镜像，它们如何通过移除不必要的软件包来减少CVE暴露，并了解为何它们正成为安全容器部署的标准。Aditya Tripathi 立即阅读

• 2026年6月3日 什么是软件供应链安全？ 了解软件供应链安全的定义，它为何重要，以及如何通过基于容器的基础设施和可信内容来保护软件交付流程的每个阶段。Aditya Tripathi 立即阅读