Chainguard 容器构建里程碑：AI 驱动供应链平台突破 10 亿次构建

容器安全厂商 Chainguard 宣布突破 10 亿次构建，AI 驱动供应链进入“自愈”新阶段

发布时间：2026 年 9 月 5 日 | 来源：CyberPress | 领域：云原生安全 / 软件供应链安全

技王数据恢复

核心事件：容器构建规模与速度实现翻倍增长

根据 CyberPress 于 2026 年 9 月 5 日发布的报道，容器安全与供应链平台厂商 Chainguard 宣布其累计完成的容器构建（Build Manifests）数量已达到 10 亿次。这一数据标志着该平台在云原生软件交付领域的规模化应用取得了显著进展，其构建输出量在短短六个月内实现了翻倍，从 5 亿次跃升至 10 亿次。

www.sosit.com.cn

这一里程碑不仅代表了构建次数的增长，更涵盖了超过 3,000 个独特的容器镜像（Container Images）以及 675,000 个镜像版本。Chainguard 指出，这一庞大的数据量反映了云原生环境面临的严峻挑战：上游代码、依赖项、架构和安全策略的持续变化，要求云原生工件必须保持实时更新，否则将迅速过时。 www.sosit.com.cn

技术原理：从“事件驱动”向“状态驱动”的架构转型

为了支撑如此高频的构建需求并解决传统漏洞管理模式的滞后性，Chainguard 对其底层构建工厂（Factory）架构进行了重大升级，推出了 Factory 2.0 版本。该版本引入了开源的 DriftlessAF 智能体框架，将传统的“事件驱动”模式转变为“状态驱动”的持续重构模式。

www.sosit.com.cn

传统模式的局限： 原有的架构依赖工程师对每一个独立事件（如 CVE 披露、新包发布）进行响应，随着依赖关系网络的扩大，这种模式导致了重复工作、队列脆弱、任务失败以及高昂的运维开销。Chainguard 将这种因不断修补而陷入停滞的循环称为"CVE 死亡循环”（CVE doom loop）。 www.sosit.com.cn

新架构机制： Factory 2.0 不再被动等待事件触发，而是持续对比镜像仓库的“期望状态”（Desired State）与“实际状态”（Actual State）。当检测到差异——例如新披露的漏洞、上游依赖更新或新的加固要求——系统会自动启动工作流来弥合这一差距。这一机制由协调机器人（Reconciler bots）执行，它们从共享队列中拉取任务，并利用结构化、可验证的工具链进行构建、验证、签名和发布。 技王数据恢复

AI 在软件供应链中的具体应用场景

Chainguard 在 Factory 2.0 中集成了人工智能技术，主要用于处理那些难以完全通过传统规则自动化的复杂判断任务。根据报道，AI 智能体主要承担以下职责： www.sosit.com.cn

• 新组件评估： 对上游引入的新组件进行初步的安全性与兼容性评估。
• 补丁回溯： 将针对旧版本发布的安全修复补丁，自动回溯并应用到历史镜像版本中。
• 经验复用： 分析过往成功的修复案例，将其中的经验教训应用到当前的修复策略中。

这种设计允许智能体朝着预定义的目标状态工作。如果某个修复任务失败，系统可以自动重试，而不会导致整个构建流程中断。这旨在解决攻击者利用 AI 快速识别漏洞并开发利用代码（Exploit）的问题，从而缩短从上游补丁发布到容器镜像更新的“暴露窗口期”。

技王数据恢复

构建产物的可信度与合规性保障

Chainguard 强调，其构建工厂产出的所有工件均基于源代码构建，并内置了严格的可信度保障机制。每一个生成的容器镜像都包含：

• SLSA Level 3 溯源信息： 提供软件供应链的层级 3 级可验证溯源，确保构建过程的可重现性与可信度。
• Sigstore 签名： 使用 Sigstore 工具链对镜像进行签名，确保镜像在传输和运行过程中未被篡改。
• 完整的 SBOM： 自动生成并包含软件物料清单（Software Bill of Materials），清晰列出镜像中包含的所有依赖项及其版本。

这种“构建即安全”（Build-time Security）的理念，旨在确保容器镜像在其整个生命周期内始终保持安全、签名和更新状态，而非仅在首次拉取时进行一次性检查。

对中国企业用户的潜在影响与观察

虽然 Chainguard 目前主要面向全球市场，但其技术演进路径对中国企业的云原生安全建设具有参考意义。

1. 软件供应链安全的紧迫性： 报道中提到的"3,000 个镜像、67.5 万个版本”的数据表明，维护大规模云原生应用的合规性是一项巨大的工程。对于正在向云原生架构转型的中国企业而言，如何确保内部镜像仓库（如 Harbor、KubeEdge 等）中的镜像能够及时响应上游漏洞（CVE）并自动更新，是降低被勒索软件或 APT 组织利用风险的关键。

2. 自动化与 AI 的边界： 尽管 AI 被用于辅助判断，但 Chainguard 明确强调系统是基于“期望状态”进行自动化的。这意味着核心逻辑依然是确定性的状态比对，AI 仅作为处理模糊判断的辅助工具。对于国内开发者而言，这意味着在引入 AI 辅助的 DevSecOps 工具时，仍需建立明确的基线策略（Policy as Code），不能完全依赖 AI 进行关键的安全决策。

3. 数据合规与跨境传输： 由于 Chainguard 的构建工厂涉及对上游开源生态的实时同步与处理，其生成的镜像若用于国内生产环境，需关注数据跨境传输的合规性。特别是当镜像中包含中国本地化组件或涉及国内业务逻辑时，需确认其构建源与分发路径是否符合《数据安全法》及《个人信息保护法》的要求。

目前，公开资料尚未披露 Chainguard 针对中国大陆市场的本地化部署方案或具体的合规认证情况。国内企业在评估此类全球性容器安全平台时，建议优先咨询厂商关于数据驻留（Data Residency）和主权云（Sovereign Cloud）的具体承诺。

后续观察点

随着 Factory 2.0 的上线，Chainguard 计划进一步增加协调机器人数量，扩大工作队列的数据源，并推动更多容器目录迁移至“自愈”模式。未来值得关注的方向包括：

• AI 决策的可解释性： 随着 AI 在漏洞修复决策中扮演的角色加重，安全团队如何验证 AI 的判断逻辑，防止“幻觉”导致的安全误报或漏报。
• 跨云原生生态的互操作性： 该架构是否能与 Kubernetes、OpenShift 等主流编排平台无缝集成，实现真正的“零信任”镜像管理。
• 开源生态的反馈机制： 这种大规模构建与验证能力，是否反过来能推动上游开源社区提高代码质量与发布频率。

信息来源

本文基于 CyberPress 于 2026 年 9 月 5 日发布的新闻稿整理而成。文中关于构建数量、架构升级细节及 AI 应用范围的描述均源自该报道。关于 Chainguard 在中国大陆的具体服务支持情况，目前公开资料未提供明确信息，建议有相关需求的企业直接联系厂商或查阅其官方中文渠道。

技术审核：邓严军｜技王数据恢复实验室技术总监