备案站点的容器镜像供应链安全

服务器加固做得再好，也挡不住一个带毒的基础镜像

服务器权限收敛、端口最小化开放、补丁按时打——这些都是把"生产环境本身"守好。但容器化时代有一条新的攻击面：镜像本身可能在你构建之前就已经不干净了。基础镜像里预置的一个恶意包、构建过程中拉取的一个被投毒的依赖、CI 流水线里被篡改的构建脚本，都可能在服务器权限和网络隔离都做对的情况下，把风险直接带进生产环境。这就是容器镜像供应链安全要解决的问题。

关键要点

• 供应链信任链条从基础镜像开始，一路延伸到构建脚本、依赖包、最终产物，任何一环被污染都会影响下游全部环节。
• SBOM（软件物料清单）解决的是"这个镜像里到底装了什么"这个基本问题，没有它，出漏洞时连排查范围都定不了。
• 镜像签名验证的是"这个镜像确实是我们自己构建的、没有被篡改过"，和镜像内容是否有漏洞是两个独立的问题。
• 扫描卡点越靠近构建早期越好，等镜像已经跑在生产环境才发现漏洞，代价是最高的。

信任链：从基础镜像到最终产物

环节	风险点	防护方向
基础镜像	来源不明、内置后门或过期漏洞组件	只用官方或可信厂商维护的基础镜像，固定具体版本而非 latest
构建脚本	CI 配置被篡改，注入恶意步骤	构建脚本本身纳入代码审查和版本控制
依赖包	第三方包被投毒或存在已知漏洞	依赖锁定 + 漏洞扫描，见 依赖升级与供应链安全
构建产物	镜像在传输或存储过程中被替换	镜像签名与来源验证
运行环境	拉取到未经验证的镜像直接运行	部署前强制校验签名与扫描结果

这条链条上任何一环出问题，后面的环节即使做得再严密，防护也会失效——这也是"供应链"这个词的含义：攻击者不需要直接攻破你的生产环境，只需要污染你信任链上游的某一环。容器化部署本身的基础配置见 容器化部署要点。

SBOM：先搞清楚镜像里到底有什么

软件物料清单（SBOM）是一份镜像内所有组件、版本及其来源的清单，类似于食品的成分表。它解决的是一个基础但经常被忽视的问题：新漏洞爆出来的时候，你能不能在几分钟内说清楚"我们有多少个镜像受影响"。

没有 SBOM 的团队，遇到一个热门开源组件曝出严重漏洞时，往往要临时组织人手一个个镜像去排查是否用了这个组件、用的是哪个版本——这个排查过程本身可能就要花上大半天，而漏洞从公开到被利用的窗口期通常很短。有了 SBOM，这个问题变成一次简单的清单检索。

实用做法：

• 在构建阶段自动生成 SBOM，作为构建产物的一部分，而不是事后补录。
• SBOM 要和镜像版本一一对应，镜像更新后 SBOM 也要同步更新，两者脱节等于没有。
• 建立按组件反查镜像的能力，收到漏洞预警时能快速定位受影响范围。

镜像签名：证明"这确实是我们构建的"

扫描解决的是"镜像里有没有已知漏洞"，签名解决的是完全不同的另一个问题：这个镜像是不是真的由可信的构建流程产出的，有没有在中间环节被替换或篡改。没有签名验证机制时，即使构建流程本身很安全，也无法阻止别人伪造一个同名镜像推到仓库、或者中间人在传输过程中替换镜像内容。

签名机制的核心是：构建完成后用私钥对镜像签名，部署前用对应公钥验证签名，验证失败则拒绝部署。这和 HTTPS 证书验证服务端身份是同一个思路，密钥的保护方式同样适用密钥管理的通用原则，见 密钥与凭据管理。签名验证要做成部署流程里的强制卡点，而不是可选的额外步骤——可选的安全措施，在赶工期的时候几乎总是被跳过。

扫描卡点：越早发现，代价越低

卡点位置	发现时机	修复代价
开发者本地构建时	最早	最低，改一行依赖版本即可
CI 流水线构建阶段	提交后立即	较低，阻断合并即可
镜像仓库推送时	构建完成后	中等，需要重新构建
部署前准入检查	上线前最后一道	较高，可能已经耽误发布节奏
生产环境运行时扫描	最晚	最高，漏洞已经在线上暴露了一段时间

同一个漏洞，发现得越晚，处理成本越高——本地开发时改一个依赖版本几乎零成本，等到生产环境运行时才发现，往往意味着一次紧急热修复加上事后复盘。理想的防护是分层设卡：本地和 CI 阶段做快速扫描拦住大部分明显问题，部署前做一次更严格的准入检查作为最后防线，流水线整体设计见 CI/CD 自动化部署。

要注意的是扫描结果不能是"发现漏洞就无条件阻断"——大量已知漏洞实际风险很低或已有缓解措施，一刀切阻断会让团队疲于应付大量误报，最终导致扫描被绕过或忽略。合理做法是按漏洞严重级别设阈值，并允许对已评估过风险、暂时无法修复的漏洞做例外标记。

两类典型的供应链攻击

• 依赖投毒：攻击者在公共包仓库上传一个和知名包名字相似、或直接接管一个失去维护的旧包，注入恶意代码，等待毫无戒心的项目引入。防护上要求依赖来源可追溯、版本锁定，避免自动拉取未经审查的次要版本更新，具体做法见 依赖升级与供应链安全。
• 镜像层缓存投毒：容器镜像由多个层叠加构成，如果构建环境的层缓存被污染（例如共享的 CI 构建机被攻陷），后续所有复用该缓存层的镜像都会被污染，且往往不容易被发现，因为镜像扫描针对的是最终产物而非中间层的历史来源。防护上要求构建环境本身的隔离与加固，定期清理并重建缓存，而不是无限期复用同一份缓存。

常见坑

• 基础镜像用 latest 标签：版本不固定，今天扫描通过，明天基础镜像更新后可能就引入了新漏洞，且难以追溯是哪次更新导致的。
• 只在生产环境上线前扫描一次：漏洞发现得太晚，处理成本最高的那个阶段。
• 扫描发现漏洞但没有分级处理机制：要么全部阻断拖慢发布，要么干脆无视扫描结果。
• 没有 SBOM，新漏洞爆出来时无法快速定位影响范围：应急响应从"检索一份清单"变成"临时排查所有镜像"。
• 签名验证形同虚设：私钥保护不当，或验证步骤可以被跳过，签名机制失去意义。

常见问题

小团队有必要做到这么完整的供应链安全体系吗？

不需要一步到位。优先级建议是：先做基础镜像版本锁定和依赖扫描（成本最低、收益最直接），再逐步引入 SBOM 生成，最后视团队规模和合规要求决定是否上镜像签名。完整体系更适合团队规模较大、或对安全合规有明确要求的场景。

扫描出的漏洞太多，根本处理不完怎么办？

先按严重级别和是否有可用修复方案排序，优先处理高危且有补丁的漏洞。对暂时无法修复但风险可控的，建立例外清单并定期复查，而不是让海量漏洞列表劝退整个扫描机制。

SBOM 生成之后应该存在哪里？

应该和对应的镜像版本一起归档，并且要能被快速检索。常见做法是存进制品仓库或专门的 SBOM 管理系统，与镜像标签建立明确的对应关系，收到漏洞预警时能立刻按组件反查。

镜像签名验证失败了，应该怎么处理？

默认应该拒绝部署，而不是记录告警后放行。签名验证失败通常意味着镜像来源存疑，这类情况下"先上线再排查"的风险远高于短暂的发布延迟带来的影响。

资料来源

容器镜像构建与签名验证的公开技术文档，SBOM 相关公开标准与实践资料，以及软件供应链安全领域关于依赖投毒等攻击模式的公开研究。本文为通用运维说明，仅供参考，具体方案请结合团队规模与安全合规要求设计。