导语：Docker 镜像把操作系统组件、运行时、依赖库与业务代码封装在一起，提升了交付效率，也扩大了软件供应链的攻击面。镜像中可能存在已知漏洞、恶意依赖、泄露的密钥、不可信基础镜像以及构建过程被篡改等风险。因此，安全治理不能停留在上线前“扫一次”，而应覆盖代码提交、镜像构建、仓库准入、部署验证和运行监控全过程。🔐
一、先理解镜像扫描的能力边界
镜像漏洞扫描通常会解析镜像各层，识别操作系统软件包、语言依赖和组件版本，再与漏洞情报库进行匹配。以 Docker Scout 为例，它可以从镜像中提取软件物料清单，也就是 SBOM，并根据安全公告评估组件风险，具体机制可参考 Docker Scout 镜像分析文档。
需要注意的是，“发现 CVE”不等于“确认可利用”。扫描结果可能受到软件包识别方式、漏洞库更新时间、发行版补丁回移以及应用实际调用路径等因素影响。治理时不应只看漏洞总数，而要综合严重等级、是否存在修复版本、镜像是否已部署、组件是否暴露、利用条件和业务重要程度。
扫描解决的是风险可见性问题，供应链治理解决的是镜像从哪里来、由谁构建、是否被篡改，以及能否安全进入生产环境的问题。
二、在构建阶段减少漏洞来源
1. 管好基础镜像
优先选择来源明确、持续维护且版本策略清晰的基础镜像，避免直接使用来历不明的社区镜像。生产环境建议固定镜像摘要，而不是长期依赖可能被覆盖的 latest 标签。团队还应建立基础镜像白名单，由平台团队统一维护 Java、Node.js、Python 等公共运行环境。
2. 缩小镜像体积与攻击面
采用多阶段构建，把编译工具、测试文件和包管理缓存留在构建阶段，最终镜像只保留运行所需内容。删除无用软件包、调试工具和临时文件，不在镜像中安装 SSH 服务。对于不需要 shell 的应用，可评估精简型或无发行版基础镜像，但必须同时考虑排障、证书和兼容性需求。🧩
3. 防止敏感信息进入镜像层
不要通过 Dockerfile 的环境变量、复制命令或构建参数写入密码、令牌和私钥，因为删除文件并不代表历史镜像层中不存在该内容。构建时应使用 CI 平台的密钥管理能力或 BuildKit secret，并增加密钥扫描。如果发生泄露，应立即吊销凭据并重新构建，而不是仅删除最新层中的文件。
三、把扫描嵌入 CI/CD 流水线
安全检查应尽量前移。开发者提交代码后，可以先扫描依赖清单和 Dockerfile；镜像构建完成后，再对最终镜像执行漏洞、许可证及敏感信息检查；推送仓库前，根据组织策略决定是否放行。
- 开发阶段：提示高风险依赖、危险 Dockerfile 配置和明文凭据。
- 构建阶段：生成 SBOM，并记录源码版本、构建器、依赖材料和镜像摘要。
- 准入阶段：阻止不符合策略的镜像进入正式仓库或生产集群。
- 运行阶段：持续关联新披露漏洞，识别受影响工作负载并触发重建。
流水线不宜采用“发现任意漏洞就失败”的简单规则，否则容易造成告警疲劳。更实用的策略是：阻断存在可修复严重漏洞的新镜像；对暂无补丁但确需上线的问题建立限时例外；对互联网暴露、已知可利用或涉及关键业务的风险提高优先级。例外必须记录负责人、原因、补偿措施和到期时间。
四、用 SBOM、签名与来源证明建立可信链
SBOM 是镜像组件清单，可用于回答“某个新漏洞影响哪些镜像”。建议每次构建自动生成 SBOM，并与镜像摘要绑定后保存。SBOM 本身不能证明镜像可信，但能显著提升漏洞定位、许可证审查和事件响应效率。📦
镜像签名用于确认制品身份和完整性。使用 Cosign 等工具时，应在可信构建环境中完成签名，并在部署前验证签名者身份、证书颁发者及镜像摘要。Cosign 默认可校验签名载荷中的镜像摘要是否与目标镜像一致，具体方法可查看 Sigstore 签名验证文档。
来源证明则描述镜像在何处、何时、由哪个构建器以及使用哪些输入生成。SLSA 将 provenance 定义为可验证的制品来源信息，可参考 SLSA Provenance 规范。实际落地时，可将“SBOM 存在、签名有效、来源证明可信、构建来自受保护分支”组合为仓库或集群准入条件。
五、建立可持续的漏洞处置闭环
完成扫描只是开始。安全平台应把漏洞关联到镜像摘要、应用、环境和责任团队，并形成发现、研判、修复、验证和关闭的闭环。对于基础镜像中的漏洞，通常应升级基础镜像并重新构建，而不是直接进入运行中的容器手工打补丁，因为手工修改难以复现，也会造成镜像与运行实例不一致。
- 资产台账：记录镜像来源、摘要、部署位置、负责人和生命周期状态。
- 修复时限：根据严重程度、暴露范围和可利用性设定分级 SLA。
- 自动重建：基础镜像或锁定依赖更新后，自动触发测试、扫描和发布。
- 历史清理：删除过期标签、停止使用的镜像和无业务归属的仓库。
- 指标复盘：关注平均修复时间、逾期风险、例外数量和签名覆盖率。
六、避免常见治理误区
一是只扫描应用层而忽略基础镜像；二是只看 CVSS 分数，不结合生产暴露面；三是扫描报告没人认领；四是长期保留永不过期的豁免；五是签名后不在部署端验证；六是认为镜像没有高危漏洞就绝对安全。容器还可能面临权限过大、不安全挂载、宿主机隔离不足和运行时异常等问题，相关风险与建议可参考 NIST SP 800-190 容器安全指南。
总结
Docker 镜像安全的核心不是堆叠扫描工具，而是建立可执行的治理链路：可信基础镜像减少源头风险，CI/CD 扫描控制新增问题，SBOM 提供组件透明度，签名与来源证明保障制品可信，准入策略阻止高风险镜像部署，持续监控与自动重建负责应对新漏洞。✅ 当安全要求被固化为流水线和平台策略后，团队才能在不明显牺牲交付效率的前提下，实现可追踪、可验证、可度量的供应链安全治理。
