Secure by default is your only way forward

默认安全是你唯一前进的方向 | Docker

默认安全是你唯一前进的方向

发布于 2026 年 8 月 31 日

Vishrut Iyengar

公司雇佣的每个员工，无论是人还是程序，都是建立在他人组装的基础之上，包括你团队中最新加入的成员。这个新成员在到达的那一刻就投入工作，使用公司已有的基础设施进行开发，其输出代码的速度远超你们的代码审查能力。此外，所有产出都会以你公司的名义发布。如果这是一个人类，他们会在第一周询问各种资源的位置和维护者信息。但这个新成员从不会提问。它将找到的一切视为可信，因此其构建的每个组件都继承了这种未经审视的信任。由于这个新成员是能以机器级吞吐量全天候工作的代理，过去逐渐浮现的基础性问题现在突然集中爆发。

无人审计的底层

供应链攻击与 AI 攻击的界限已不复存在。看看平均基础镜像中包含的内容吧，因为其中大部分都来自公司外部。长期以来，公共基础镜像中都包含着数百个你的应用程序从未使用过的软件包。每个额外的软件包都在扩大攻击面。几乎没有任何团队会去审查这些代码，因为没有哪个团队有时间去阅读那些未被选择且未被使用的代码。在大多数技术栈中，一个十年前的 Java 服务仍在支撑着业务运转，而其维护者早已停止提供补丁。平台团队一直在用各自的方式应对，通常是依赖多年前构建的黄金镜像计划，以及指向它的扫描器。由于底层镜像过于臃肿，这个扫描器每周会发出四百次误报。所有这些因素加在一起，就是为什么现在审计季会占据整个季度的大部分时间。

攻击者深知这一切，并且已经全年都在针对基础层进行渗透。他们污染了软件包和开发工具，并在大规模窃取代码助手凭证方面取得了实质性成果。大多数基础架构都是为一个早已消失的世界而构建的。

优质基础架构应具备的要素

好消息是，所有这些问题并非无解。基础架构可以通过强化来承载当前构建在其之上的内容。它需要满足几个关键要求，而每个要求都取决于谁来负责安全工作，因为当供应商不作为时，你的团队必须补位。一个可靠的基础架构需要每个组件都由能够签名并对其工作负责的开发者从源代码构建。不应包含任何应用程序不需要的内容，因为任何多余组件都会增加后续防御的表面积。补丁更新也需要同样严格的处理，因为新的漏洞会不断出现，无论镜像初始多么干净。修复方案应附带合同保障和明确时间表。你应在镜像发布当天就完全了解其内部组成。而且，所有这些都不应迫使你更换操作系统发行版才能获得更安全的镜像。这样的迁移本身就会成为耗时整个季度的独立项目，而基础架构在迁移完成前无法提供任何保护。

Docker 加固镜像正是为此而设计。它们与 Alpine 和 Debian 镜像团队当前运行的镜像保持兼容性，因此采用只需在 Dockerfile 的 FROM 行进行一行修改，无需任何迁移项目。这些镜像在设计上也保持精简，仅包含应用程序所需的内容，可将攻击面减少高达 95%，并且从第一天起关键和高风险 CVE 数量接近于零。这种差异在扫描时立即显现。扫描速度大幅提升且噪音极低，剩余的少量发现结果也值得团队重点关注。当出现 CVE 漏洞时，修复后的镜像在上游补丁发布后的七天内即可提供，原本需要耗费整个工程冲刺周期的工作现在只需一个拉取请求即可完成。相同的证据也适用于审计，而大多数组织最终都将面临审计。每个加固镜像都附带签名的 SBOM（软件物料清单）和构建来源证明，这是对镜像内容和构建过程的可验证记录。你向审计人员展示的证明已经存在，无需任何人花费数周时间重新构建。

此外，仅依靠加固的基础镜像可能仍不足以满足需求，因为最小化镜像几乎总是需要在适配生产工作流之前进行定制。团队会添加自己的 CA 证书和初始化脚本，通过 apt 和 apk 安装额外的系统包，或完全采用其他产品来弥补基础镜像无法覆盖的部分，导致其基础架构在不同供应商之间碎片化。通常正是在这一环节，加固基础架构会失效，因为对镜像进行自定义会破坏来源证明和 SBOM，进而破坏你为此支付的保障。但使用 Docker 则不会出现这种情况。

加固系统包为所有添加的内容提供相同的源代码构建处理，确保自定义内容通过相同的加固流水线，同时保持保障措施完整，SLA 依然有效。使用 Docker 时，整个基础架构始终处于单一生态系统内。

无论你如何出色地完成所有这些工作，有一件事始终不可避免。你依赖的软件最终将不再获得上游支持，缺乏支持后安全补丁将停止，合规性问题每个季度都会变得更加棘手。扩展生命周期支持通过商业支持的补丁将这一差距填补长达五年，因此向下一阶段的过渡将按照你的计划和条件进行，而非上游的安排。这就是坚实基础的体现，而如今这比以往任何时候都更加重要，因为你的新员工——代理——正在对之前所有人构建的内容进行压力测试。

新的层级

代理以与之前所有人类相同的方式构建在这一基础之上，而它所承载的信任也传递到他们构建的内容中。但现在出现了一个新的现实。代理在基础之上创建了一个新的层级，其重要性几乎与基础本身相当。他们从基础中拉取包并连接工具，一旦构建完成就会立即运行。它们也是非确定性和短暂的。相同的任务每次运行可能结果不同，而执行任务的代理会话在有人回来提问时已经不存在了。

标准堆栈中的每个控制都是为人类工人设计的，这些工人拥有永久身份和可预测的节奏，其工作在发布前可以被审查。而代理却不具备这些特性。市场最初的反应是要求每次代理操作前都获得人工许可，但当提示变得过于繁琐时，团队开始转向隔离代理。这又带来了新的问题，因为原本用于监控工作的终端工具运行在主机上，而代理越隔离，这些工具能观察到的内容就越少。从未有人为这种工作流构建过控制界面，而对旧组件进行改造使团队陷入提示疲劳和监控盲区的两难境地。

因此 Docker 构建了缺失的层级，这一层在不替换现有任何组件的前提下增强了纵深防御。在 Docker 中，每个代理会话都在基于 MicroVM 的 Docker Sandbox 中运行，该沙箱在操作系统层面将代理与主机隔离。凭证仅用于当前任务并通过代理进行代理，且不会存储在沙箱内部，您可自行决定哪些内容可以流入或流出沙箱。我们自己的安全团队已完全禁止在主机上运行代码代理，而是通过沙箱以完全自主的方式同时运行多个代理。落入这些沙箱的窃密程序将找不到任何可窃取的内容。可以称之为带有防护措施的 YOLO 模式。

代理使用的工具是下一层，同样基于相同的基础构建。代理通过 MCP（Model Context Protocol）服务器与外部世界交互，这些连接器使它们能够调用外部工具并访问数据。如果代理从开放互联网获取连接器，这又回到了之前包管理的问题。因此 Docker 通过与加固镜像相同的目录提供加固后的 MCP 服务器，采用相同的构建和签名方式。MCP 目录和工具包为团队提供了一个可信的统一位置来查找和运行这些工具。每个工具调用都会经过 MCP 网关，经过身份验证、授权和日志记录后才会到达外部系统。这将执行策略从建议性转变为强制性。

Docker Scout 在构建时强制执行策略，因此安全路径成为默认选项，无需人工手动监管。无论工作负载位于笔记本电脑还是云端，其位置都不再重要，因为边界始终随着工作负载移动，正如 Docker 容器一直所做的那样。

胜利的方案已经存在

Docker 在十年前就编写了这套方案。2010年代，软件依赖的组件往往不受其构建者控制，发布速度远超审查速度。由于减速从未被考虑过，Docker 将应用程序及其依赖项打包成一个可移植、隔离的单元，速度与安全性开始朝着相同方向发展。这一赌注在很大程度上塑造了现代软件供应链，如今我们正在为代理重新采用这一模式。同一基础和同一边界服务于同一供应链上的人员和代理，遵循相同策略。安全性变得更安静，开发速度变得更快。无需单独购买 AI 安全计划。从一开始，Docker 就主张安全性是开发者体验问题。

在圣何塞现场观看

我们将在 9 月 23 日至 25 日的 WeAreDevelopers 世界大会圣何塞现场展示所有内容。Docker 首席信息安全官 Mark Lechner 将登台演讲《面向代理时代的单一边界》，介绍他所在团队实际使用的边界，Docker 展区将在三天内进行实时演示。

不管怎样，新员工将在周一入职。您会为他们准备好什么来构建？

关于作者

Docker 首席产品市场经理

Vishrut Iyengar 是 Docker 的首席产品市场经理（PMM），专注于 Docker 加固镜像、供应链安全以及保障 AI 代理构建内容的安全性。

security

Community

Enterprise

Products

Solutions

目录

相关文章

• 2026年8月18日 17,600个操作：代理安全是一个系统问题 OpenAI/Hugging Face 事件暴露了 AI 代理安全的新挑战。17,600个攻击者操作展示了为何 AI 代理安全不能依赖人工审查。探索需要的控制措施，以在高速环境下约束、监控和治理代理。Mark Cavage 立即阅读

• 2026年9月3日 YOLO模式：无安全防护的代理自主性 YOLO模式允许AI代理在不请求许可的情况下运行。了解其定义、风险以及如何安全运行。Eric Jia 和 Srini Sekaran 立即阅读

• Docker Captain 2026年9月2日 使用 Docker 沙箱构建可复现的 AI 评估流程 学习 Docker 沙箱如何通过一致执行、结构化制品和运行时证据，使 AI 评估流程更加可复现。Karan Verma 立即阅读

• 2026年9月2日 沙箱之下：治理多模型、多沙箱世界 我们认为未来将是多模型、多沙箱的世界。我们认为这需要新的信任模型。1988年，Norm Hardy 描述了一个持续多年悄然破坏系统的难题：困惑副手问题。一个程序使用自己的权限而非你的权限采取行动。今天，每个 AI 代理都是那个副手。它…… Srini Sekaran 立即阅读