本文将为你深度拆解这 5 项新要求，分析它们对现有工作流的实际影响，并提供清晰的行动指南。
为什么 Docker 和 CISA 此时联合发布安全基线？
这次合作并非偶然。随着容器在关键基础设施中的应用越来越广泛，针对容器化环境的攻击，尤其是供应链攻击，也变得更加频繁和复杂。过去，行业内虽然有 CIS Benchmarks 等安全标准，但缺乏一个由顶级厂商和国家级安全机构共同背书的、更具强制性的实践指南。
CISA 与 Docker 联合发布的这份基线，旨在为企业提供一个清晰、权威且可操作的容器安全起点。它整合了来自社区和官方的最佳实践，目的就是为了提升整个云原生生态系统的基础安全水平，降低因配置不当或镜像漏洞而导致的安全风险。
新增的 5 项强制性要求是什么？
这次更新的核心，在于将以往的“建议”升级为“强制”，强调了在容器生命周期的早期就融入安全措施。以下是对这 5 项要求的逐一解读。
1. 移除镜像中不必要的软件和库
这项要求直指容器镜像的精简性。其核心思想是，每个容器镜像都应只包含运行其主要应用所必需的组件，不多也不少。
为什么这很重要？因为镜像中每增加一个软件包或库，就意味着增加了一个潜在的攻击面。不必要的工具（如 curl、netcat）或开发依赖，都可能成为攻击者利用的跳板。
一个常见的实践是采用多阶段构建（multi-stage builds），在最终的生产镜像中只复制编译好的二进制文件和必要的运行时依赖，而不是整个构建环境。使用如 Distroless 或 Alpine 等极简基础镜像，也是满足这项要求的有效途径。
2. 强制实施软件物料清单（SBOM）
软件物料清单（SBOM）正迅速成为软件供应链安全的基石。这项要求规定，每个容器镜像都必须附带一份机器可读的 SBOM 文件。
这份清单详细列出了镜像中包含的所有组件，包括操作系统包、第三方库及其具体版本。它的价值在于提供了前所未有的透明度。当类似 Log4j 的高危漏洞爆发时，你不再需要逐个排查，而是能通过查询 SBOM 立即知道哪些镜像受到了影响，从而极大缩短应急响应时间。
3. 使用经过验证的镜像
“不要从不受信任的来源拉取镜像”是一条老生常谈的建议，现在它被列为强制要求。团队必须确保所有使用的容器镜像，无论是基础镜像还是第三方应用镜像，都来自可信的、经过验证的来源。
这通常意味着优先使用官方镜像、经过安全认证的商业镜像，或是在组织内部建立一个受信任的私有镜像仓库。对于引入的外部镜像，必须经过严格的镜像扫描和审查流程，才能被允许在生产环境中使用。利用镜像签名技术（如 Notary 或 Sigstore）来验证镜像的来源和完整性，是实现这一目标的进阶实践。
4. 持续扫描镜像漏洞
漏洞扫描不能是一次性的行为。这项要求强调了“持续性”。它要求将镜像漏洞扫描无缝集成到 CI/CD 流程中，并在镜像的整个生命周期内进行定期重新扫描。
其背后的逻辑很清晰：新的漏洞（CVE）每天都在被发现。一个今天看起来安全的镜像，明天可能就会因为新披露的漏洞而变得脆弱。因此，自动化扫描不仅要在构建时触发，还应该对存储在仓库中的镜像进行周期性扫描，一旦发现新的高危漏洞，应立即触发告警或更新流程。
5. 确保容器以非 root 用户运行
这是运行时安全中最基本也最关键的一条。强制要求容器内的应用程序必须以非 root 用户身份运行。
这遵循了“最小权限原则”。如果容器内的应用被成功利用，攻击者获得的也只是一个普通用户的权限，其破坏能力将受到极大限制。他们无法在容器内安装新软件、修改关键文件或轻易地尝试容器逃逸来攻击宿主机。在 Dockerfile 中使用 USER 指令来指定一个非特权用户，是实现这一要求的直接方法。
这 5 项要求对你的工作流意味着什么？
这些新规不仅仅是技术清单，它们将对团队的开发和运维模式产生深远影响，核心是推动安全左移（Shift Left）。
对开发人员： 编写 Dockerfile 不再只是“能跑就行”。需要更关注基础镜像的选择、多阶段构建的应用以及依赖项的清理。安全意识需要成为开发习惯的一部分。
对 CI/CD 流程： 自动化流水线必须加入强制性的安全检查关卡。例如，集成 SBOM 生成工具、漏洞扫描器，并设置明确的“失败”阈值——当发现高危漏洞时，构建过程应自动中止。
对运维和 SRE： 重点将转向镜像仓库的治理和运行时策略的执行。需要建立可信镜像的准入机制，并利用准入控制器（Admission Controller）等工具，强制执行“非 root 用户运行”等运行时安全策略。
如何着手，满足新的合规要求？
面对这些要求，团队可以从以下几个方面开始系统性地改进：
全面评估现状： 对现有的 Dockerfile、CI 流水线和镜像仓库进行一次盘点。识别出哪些地方与这 5 项要求存在差距，例如，有多少镜像仍在使用臃肿的基础镜像？是否集成了自动化扫描？
标准化镜像构建： 制定统一的 Dockerfile 最佳实践规范，并将其作为代码审查的一部分。鼓励并强制使用多阶段构建和最小化的基础镜像。
集成自动化工具： 在 CI/CD 流程中引入开源或商业工具，自动化地生成 SBOM、扫描漏洞。将安全检查变成和单元测试、集成测试同等重要的环节。
建立可信源： 部署私有镜像仓库（如 Harbor），并建立一套清晰的流程，用于管理和审批允许进入该仓库的基础镜像和第三方镜像。
合规不是终点，而是起点
Docker 与 CISA 联合发布的这份安全基线，为容器安全设定了一个新的标准。它清晰地表明，安全不再是部署后的附加项，而是必须内建于软件供应链每个环节的核心属性。
满足这些要求可能需要团队在工具链、流程和文化上做出调整。但这不仅仅是为了通过合规检查，更是为了构建一个更具韧性、更值得信赖的云原生应用体系。这 5 项要求，应被视为构建坚实容器安全基础的起点。