Docker Hardened Images 的构建方式

Table of contents

Docker Hardened Images (DHI) 是通过自动化管道构建的，该管道会监控上游源、应用安全更新并发布签名的制品。本页将解释基础 DHI 镜像和 DHI Enterprise 定制镜像的构建流程。

对于 DHI Enterprise 订阅用户，基础镜像和定制镜像的自动化安全更新管道均受 SLA 承诺保障，包括针对严重和高危漏洞的 7 天 SLA。只有 DHI Enterprise 包含 SLA。DHI Free 提供安全基线，但不保证修复时间表。

构建触发器

构建会自动开始，无需手动触发。系统会监控变更，并在以下两种情况下启动构建：

上游项目的新版本、软件包更新或 CVE 修复会触发基础镜像的重新构建。这些构建会经过质量检查，以确保安全性和可靠性。

Docker 持续监控上游项目的新版本、软件包更新和安全公告。当检测到变更时，系统会自动将受影响的镜像加入重新构建队列，使用符合 SLSA Build Level 3 标准的构建系统。

Docker 使用三种策略来跟踪更新：

GitHub releases：监控特定的 GitHub 仓库，当发布新版本时，自动更新镜像定义。
GitHub tags：跟踪 GitHub 仓库中的标签以检测新版本。
软件包仓库：通过 Docker Scout 的软件包数据库监控 Alpine Linux、Debian 和 Ubuntu 的软件包仓库，以检测已更新的软件包。

除了显式的上游跟踪外，Docker 还会监控传递依赖项。当检测到软件包更新（例如，某个库的安全补丁）时，Docker 会自动识别并重新构建支持窗口内所有使用该软件包的镜像。

Subscription: Docker Hardened Images Enterprise

对 OCI 制品定制的更新会触发定制镜像的重新构建。

当您使用 DHI Enterprise 定制 DHI 镜像时，您的变更会被打包为在基础镜像之上分层的 OCI 制品。Docker 会监控您的制品仓库，并在您推送更新时自动重新构建您的定制镜像。

重新构建过程会获取当前的基础镜像，应用您的 OCI 制品，对结果进行签名，并自动发布。您无需管理构建或维护定制镜像的 CI 管道。

当定制镜像所依赖的基础 DHI 镜像收到更新时，定制镜像也会自动重新构建，确保您的镜像始终包含最新的安全补丁。

以下部分描述了 Docker Hardened Images 的构建管道架构和工作流，基于：

每个 Docker Hardened Image 都通过自动化管道构建：

监控：Docker 监控上游源的更新（新版本、软件包更新、安全公告）。
重新构建触发器：当检测到变更时，自动开始重新构建。
AI 防护栏：AI 系统获取上游差异并使用语言感知检查进行扫描。防护栏专注于可能导致重大问题的高风险问题，例如颠倒的错误检查、被忽略的故障、资源处理不当或可疑的贡献者活动。当发现潜在风险时，它会阻止 PR 自动合并。
人工审查：如果 AI 以高置信度识别出风险，Docker 工程师会审查被标记的代码，重现问题，并决定适当的措施。工程师通常会将修复贡献回上游项目，为整个社区改进代码。当修复在上游被接受后，DHI 构建管道会立即应用补丁以保护客户，同时修复会在上游发布流程中推进。
测试：镜像会经过全面的兼容性和功能性测试。
签名和证明：Docker 对每个镜像进行签名并生成证明（SBOM、VEX 文档、构建来源）。
发布：签名的镜像和证明被发布到 Docker Hub。
级联重新构建：如果有任何定制镜像使用此基础镜像，它们的重新构建会被自动触发。

Docker 会快速响应关键漏洞。通过从源代码构建关键组件，而不是等待打包更新，DHI 可以在上游修复后的几天内修补严重和高危 CVE，并发布带有新证明的更新镜像。对于 DHI Enterprise 订阅，这种快速响应由针对严重和高危漏洞的 7 天 SLA 提供保障。

以下是基础镜像构建流程图：

Subscription: Docker Hardened Images Enterprise

当您使用 DHI Enterprise 定制 DHI 镜像时，构建过程会得到简化：

Docker 会自动处理整个过程，因此您无需管理定制镜像的构建。但是，您需要负责测试您的定制镜像，并管理由您的 OCI 制品引入的任何 CVE。

以下是定制镜像构建流程图：