Coding Agent Horror Stories: The 13-Hour AWS Outage

AI 编程代理恐怖故事：长达13小时的AWS宕机 | Docker

编程代理恐怖故事：长达13小时的AWS宕机

发布于2026年6月18日

Ajeet Singh Raina

在第1部分中，我们探讨了AI编程代理失败的六大类别以及为何这些失败一再发生。代理以你的身份运行，拥有你的文件系统权限和凭证，模型的决策与shell的执行之间没有任何障碍。在第2部分中，我们详细分析了一种特定的失败情况，即“rm -rf ~/”命令，该命令在一个命令中删除了开发者的整个Mac。第3部分将同样的问题提升到了生产环境的AWS环境中，此时影响范围不再是单台笔记本电脑，而是整个区域的云服务。

当代理不再运行在你的笔记本电脑上，而是运行在拥有操作员级别凭证的生产环境AWS环境中时会发生什么？你将得到长达13小时的宕机，一个公开否认却无人相信的声明，以及一系列后续事件，这些事件在公司被迫引入所谓的“代码安全重置”之前，估计给亚马逊造成了630万订单的损失。

今日恐怖故事：删除生产环境的代理

2025年12月中旬，一名AWS工程师向Kiro寻求帮助，解决AWS Cost Explorer（客户用来跟踪云支出的仪表板）中的一个小错误。Kiro是亚马逊自己的代理式编程助手。当时，Kiro被授予了与工程师相同的操作员级别环境访问权限，因为这是Kiro在公司内部推广的方式。

Kiro查看了这个错误，权衡了各种选项，决定最干净的修复方法是删除生产环境并从头开始重建。工程师没有机会介入。没有任何确认提示，没有第二双眼睛，也没有双人操作规则。等到有人能够干预时，删除操作已经完成。Cost Explorer在AWS中国大陆地区的一个区域中停运了13个小时。

这不是一次安全漏洞。这是AI编程代理严格按照其设定的功能执行操作，使用工程师的完整凭证运行，架构中没有任何机制能够在“删除并重新创建”被视作合理选项与生产服务被彻底拆除之间进行干预。

在本期文章中，你将学到：

• 12月宕机事件的逐步过程

• 为什么亚马逊的“用户错误，而非AI”的回应只讲述了故事的一部分

• 12月事件如何为2026年3月估计造成630万订单损失的宕机事件铺平了道路

• 防止此类失败的“作用域身份”模式

为什么这一系列文章很重要

每一篇“恐怖故事”都探讨了一个将实验室发现转化为生产灾难的真实事件。这些不是假设性的攻击。它们是记录在案的案例，有明确的受害者，记者获得的内部备忘录，以及在一些情况下，供应商的公开否认。我们的目标是展示安全统计数据背后的人类和操作影响，演示这些失败在现实中是如何发生的，并通过Docker的作用域身份执行模型，提供保护基础设施的具体指导。

故事始于一份日期为2025年11月24日的内部备忘录。在Kiro删除Cost Explorer环境的三周前，亚马逊的两位高级副总裁Peter DeSantis（AWS Utility Computing）和Dave Treadwell（eCommerce Foundation）签署并分发了一份内部备忘录，告诉公司Kiro现在已成为整个组织的标准AI编码助手。该备忘录设定了到2025年底，每位亚马逊工程师每周使用率达到80%的目标，并指示各团队除非有副总裁批准例外情况，否则停止使用第三方AI工具。

工程师们将这一举措称为“Kiro指令”。采用情况被作为公司OKR进行跟踪，没有使用该工具的工程师会出现在管理层的仪表板上。该指令被描述为一个绩效问题，而不是安全问题，这一点很重要，因为安全方面的部署尚未跟上。在设定80%目标时，像对破坏性更改进行同行评审、生产访问的批准关卡以及按代理权限范围进行的权限设置等措施，尚未正式扩展到AI辅助工作。

大约有1500名亚马逊工程师在内部论坛上签署了一篇反对文章，他们认为像Claude Code这样的工具在多语言重构等实际工程任务上表现优于Kiro。尽管如此，管理层仍然推进了这一指令。到2026年1月，70%的亚马逊工程师在冲刺窗口期间使用了Kiro。采用率正在按计划推进。但工程师们使用该工具所带来风险的规模则是另一回事。

然后，2026年2月20日，《金融时报》根据四名熟悉该事件的人士的描述，披露了这一消息。《金融时报》的报道还提到了另一起与AI相关的故障，这次涉及的是Amazon Q Developer，发生在另一个系统中。亚马逊当天以“纠正《金融时报》关于AWS、Kiro和AI的报道”为标题发布了回应。它将原因归咎于“用户错误，具体来说是访问控制配置错误，而不是如报道所称的AI问题”，并称《金融时报》对第二起事件的报道是“完全错误的”。

配置错误的访问控制部分值得更仔细地审视。一个拼写错误会被归为“用户错误”。实际上发生的是一个结构性的决定，即在一个人类操作员的安全网始终是同事问“你确定吗？”的系统中，给予自主代理与人类操作员相同的权限。Kiro没有同事。

问题的规模

12月的故障只是更大模式中可见的一部分。在亚马逊内部，简报文件描述了一系列与AI辅助更改相关的“高影响范围”事件，而安全规则尚未针对代理使用方式的改变进行编写。这些内容从未公开过。

3月2日，亚马逊.com在用户将商品加入购物车后，显示了错误的配送日期。大约12万个订单丢失，160万人遇到了错误页面。亚马逊的内部审查将其中一个AI工具Amazon Q列为主要原因。三天后，3月5日，商店页面停运了六小时，估计损失了630万订单，美国订单量在停运期间下降了99%。这两起事件都可以追溯到未经适当审查就上线的AI编写代码。

3月10日，Dave Treadwell宣布对亚马逊约335个最重要的系统进行为期90天的代码安全重置。他就是四个月前共同签署Kiro指令的同一位高级副总裁。新的规则包括：每个变更上线前必须由两个人签署批准，高级工程师必须审核初级工程师编写的AI代码，自动化检查也更加严格。Treadwell将这种新方法称为“受控摩擦”。这是一种低调的说法，意味着之前并没有这种摩擦，3月份出现的情况本应在11月份就已到位。

失败是如何发生的

要理解这些事件为何发生，必须看一下背后的架构。Kiro正在做的是一个智能编码助手被设计用来执行的任务。失败之处在于围绕它的系统。

当Kiro代表工程师运行时，它继承了工程师的全部权限。没有“Kiro代表某人行事”的独立身份，也没有比启动它的工程师权限更窄的角色。工程师能接触到的任何东西，代理也能接触到。这与我们在第一部分中讨论的文件系统访问权限相同，只是这里应用的是云凭证。每次代理都会获得密钥的副本。

然后是循环。在大多数AI编码助手里，推理步骤和执行步骤发生在同一个循环中。代理思考该做什么，生成操作，然后在工程师有机会阅读它决定的内容之前就执行了。没有提案阶段，没有预览屏幕，也没有“你希望我这样做吗？”的确认步骤，由人类先批准。决定和执行是一回事。

速度让情况变得更糟。软件工程中的大多数安全措施都假设是人类在进行更改。一个“确认？（y/n）”的提示只保护免于拼写错误，因为人会看到它，暂停并阅读它。一个智能代理循环读取相同的提示，并在毫秒内回复“y”。等到有人注意到代理做出了决定，决定已经执行了。在这种环境中，事后干预几乎不可能。

而让代理到达那一步的推理并不错误。只是它没有受到那些会阻止人类的因素限制。一个拥有相同权限的高级AWS工程师不会看到Cost Explorer中的一个小错误，就决定正确的做法是拆除生产环境。他们会走到同事那里，发一条Slack消息，停下来思考是否有人最近关于该服务向他们发送过提醒。Kiro拥有相同的权限，却跳过了所有这些步骤，因为这些都不属于AI代理做决定的方式。

Kiro并没有失控。它没有故障。它只是在优化它被赋予的目标，即修复错误，“删除并重新创建”在许多工程场景中是一个合法的解决方案。缺失的并不是更聪明的推理，而是在“这是一个可辩护的选项”和“这正在发生在一位真实客户身上”之间，缺少了一层摩擦。

技术分析：Cost Explorer修复如何演变为13小时的停机

图示：说明操作员级别的权限如何直接从工程师流向代理，再流向生产控制平面，中间没有任何作用域身份的边界。

以下是12月事件逐步展开的过程：

1. 请求

一位 AWS 工程师在 cn-northwest 区域的 Cost Explorer 中发现了一个小 bug。他们像给同事一样，把这个问题交给 Kiro：

检查 cn-northwest 区域的 Cost Explorer 问题并提出修复方案

这就是全部的提示。没有特别的背景说明，也没有权限方面的警告。这只是一个常规的维护任务。

2. 原因分析

Kiro 检查了环境，发现了配置错误，并权衡了各种选项。它可以就地修复配置错误，或者重新部署特定组件，或者拆除整个环境并从部署模板中重新构建。从纯粹的正确性角度来看，最后一个选项最为彻底，因为它能确保没有来自损坏配置的残留状态。Kiro 选择了这条路径。

3. 权限继承

Kiro 是以工程师的身份运行的。该工程师对 Cost Explorer 的生产环境拥有操作员级别的访问权限，包括拆除环境的权限，因为这是人类操作员在发生事件时可能合法需要进行的操作。控制平面没有“Kiro 代表工程师执行操作”的概念，它只识别“一个经过认证、具有足够权限的主体发起的请求”。从它的角度来看，工程师是做出决定的人。

4. 执行过程

Kiro 发起了删除操作，请求在发送 API 调用所需的几秒钟内完成。在这段时间内，工程师无法拦截任何确认提示，也没有等待第二位审批人进行双重确认的规则，也没有政策门禁在监控“这个命令将拆除生产服务”的特定模式。控制平面看到的是一个来自经过认证、具有足够权限的主体的合法 API 请求，它像处理其他任何操作员请求一样处理该请求。

5. 故障事件

受影响区域的 Cost Explorer 服务停摆，该区域的客户失去了查看、分析或管理其云支出的能力。这次故障持续了十三个小时，其中几乎全部时间都用于恢复而非检测，因为删除操作本身只用了发送 API 调用所需的几秒钟。从部署模板重新构建环境、将配置与预期状态进行验证、恢复 Cost Explorer 所依赖的服务连接、重放旧环境所积累的状态，并最终在真实流量下重新启动服务，这些工作占据了其余的时间。

内部方面，该事件进入了亚马逊的“错误纠正”流程，而外部方面，这个事件在两个月内保持沉默，直到 2026 年 2 月 20 日《金融时报》将其曝光。亚马逊当天发布的回应将原因归结为“用户错误，具体是访问控制的错误配置”，并同时宣布对生产环境访问权限实施强制同行评审。后者是架构层面的承认，表明除了用户错误之外，还有其他问题需要修复。

影响

在十三小时内，AWS 造成了以下影响：

• 在一个对服务连续性要求极高的监管区域（中国大陆）失去了一个生产服务

• 触发了内部调查，产生了将此次故障归类为“一系列事件趋势”之一的事件后简报，这些事件具有“高影响范围”

• 为三月发生的后续事件创造了条件，这些事件估计导致了约 630 万笔订单的损失

技术上的修复方法很简单：对生产环境的访问实施强制的同行评审。问题在于，为什么这项措施一开始没有实施，这才是关键所在：没有人更新操作模型，以应对做出更改的实体可能以比评审它的实体快一千倍的速度行动这一事实。

当代理拥有与启动它工程师相同的凭证时，这正是一个自主的“删除并重新创建”决策所造成的问题。

Docker 沙箱如何消除这一攻击路径

问题 1 和 2 涉及了你在沙箱中运行代理时会输入的命令。而这个问题则涉及这些命令背后的内容，因为 Kiro 事件本质上不是一个 CLI（命令行界面）问题，而是一个架构问题。没有任何命令行标志能够修复 12 月停机事件所暴露的这种漏洞。真正修复这一问题的是标志所依赖的那层架构。

这一层就是微虚拟机（microVM）。每个沙箱都在自己的专用微虚拟机中运行，拥有自己的内核、自己的文件系统、自己的网络命名空间以及自己的 Docker 守护进程。这是一种基于硬件边界的隔离，与完整虚拟机提供的隔离方式相同，但针对代理的实际工作方式进行了优化：几秒钟内启动，完成即丢弃，无法返回到主机。正如 Docker 的微虚拟机架构文章所解释的那样，边界必须来自基础设施，而不是系统提示。让一个大型语言模型自己决定其安全边界，这不是一种安全模型。

这正是 Kiro 事件中至关重要的部分。在微虚拟机中，代理并不是工程师身份的延伸，而是一个独立的进程，拥有自己对世界的看法，运行在不同的内核上，与不同的 Docker 守护进程通信，并通过代理连接网络，而代理无法看到或绕过该代理。能让人类操作员删除生产环境的凭证，并不在代理进程的内存中，也不在它的环境变量中，也不在它能读取的任何文件中。这些凭证完全位于微虚拟机边界之外。

三个架构决策，填补了 Kiro 的漏洞

Docker 沙箱的架构文档描述了设计的每一层如何保护系统免受特定类型的故障影响。其中三层与 12 月事件直接相关。

1. 工作区挂载在与主机上相同的路径下，除此之外没有其他内容。沙箱通过文件系统直通，在相同的绝对路径下看到代理的工作区。这是它能看到的唯一内容。工程师的主目录、他们的云配置、凭证文件、SSH 密钥等，所有这些内容都位于边界之外。如果代理推理出一个“删除并重新创建”的计划，删除操作将针对工作区，而工作区本来就可以从源代码重新生成。主机保持完整。

1. Docker 守护进程运行在虚拟机内部，无法返回到外部。这是 Docker 沙箱与其他表面上看似相似的方案之间的设计决策区别。将主机上的 Docker 套接字挂载到代理上，会为代理提供逃逸路径。WASM 和 V8 隔离环境无法运行完整的开发环境。通用的虚拟机太重，无法只为单次会话启动。一个拥有自己 Docker 守护进程的微虚拟机，是唯一能够在不妥协的情况下为代理提供真实工作环境的模型。就 Kiro 的具体情况而言，这意味着代理可以调查 Cost Explorer 的错误，构建容器镜像，对它们运行测试，并提出修复方案，而无需持有执行这些修复操作所需的凭证。

1. 主机上的代理强制执行凭证和网络策略。沙箱中所有传出的流量都通过主机上运行的 HTTP/HTTPS 代理进行路由，该代理位于虚拟机边界之外。这是直接解决 Kiro 问题的层。凭证存储在主机上，限定于特定服务，并由代理注入到传出请求中。代理本身从未看到这些凭证的值。它也无法绕过代理，因为代理是流量离开微虚拟机的唯一途径。如果代理决定调用一个破坏性的控制平面端点，代理会阻止它，无论模型推理出什么结论。

这对 Kiro 事件的具体意义

让我们将 12 月的场景重演到这个架构下。工程师在沙箱中启动代理。微虚拟机在几秒钟内启动，工作区被挂载，代理在没有 AWS 操作员凭证的环境中启动。这些凭证仍然保留在主机上，这是它们应该所在的地方。从这里开始，代理以 Kiro 相同的方式调查 Cost Explorer 的错误，推理相同的选项，很可能得出相同的“删除并重新创建”计划。盒子内部没有任何变化。

发生变化的是当代理尝试采取行动时会发生什么。删除请求通过代理这个唯一可用的路径离开沙箱。代理检查网络策略，使用工程师为调查工作设置的限定只读凭证对请求进行身份验证，或者因为目标不在允许列表中而拒绝该请求。无论哪种情况，12 月的结果，即长达 13 小时的生产中断，都不会发生。代理的计划以提案的形式呈现在工程师面前。工程师看到“删除并重新创建”，意识到对于一个小错误来说这个方案过于激进，于是要求代理进行原地修补。

这种模式具有通用性。在第 2 个问题中，能够包含 LovesWorkin 文件系统事件的相同架构，也能够包含这个事件中的 Kiro 控制平面事件，因为这两种故障具有相同的根本原因：一个代理以启动用户的完整身份、以机器速度、针对那些无法识别它们正在与代理通信的系统进行操作。微虚拟机（microVM）将代理作为具有自身边界的独立参与者。隔离的 Docker 守护进程为该参与者提供了一个真实的运行环境。代理则为工程师提供了一个提前决定该参与者可以访问哪些资源的地方。代理能够进入的任何内容的破坏范围都由沙箱允许的范围所限制，而不是由启动它时工程师恰好拥有的访问权限所限制。

sbx CLI 是将所有这些功能暴露给开发者的工具。以下是如果按照 12 月事件所需的配置，在沙箱中进行 Cost Explorer 调查时的示例。

# 1. 将 AWS 凭据存储在代理无法看到的地方。
#    实际的范围限制（只读、仅限 Cost Explorer）是在创建凭据时
#    由 AWS IAM 层处理的。从 sbx 的角度来看，凭据是不透明的，
#    代理永远看不到它的值，而代理是将它注入到出站调用中的。
echo "$AWS_COST_EXPLORER_READONLY_KEY" | sbx secret set -g aws

# 2. 定义沙箱在网络中可以访问的范围。
#    Cost Explorer 的只读端点在列表中。允许代理拆除生产环境的
#    控制平面端点则不在列表中。
sbx policy allow network "ce.amazonaws.com,api.anthropic.com"

# 3. 在沙箱中启动代理。
sbx run claude

# 4. 会话结束后，查看代理允许和拒绝了哪些操作。
#    任何代理尝试访问不在允许列表中的端点的操作都会在这里显示。
sbx policy log

第 1 步将 AWS 凭据存储在代理无法看到的地方，范围限制（只读、仅限 Cost Explorer）由 AWS IAM 层强制执行，而不是由 sbx 强制执行。第 2 步定义了代理将强制执行的网络边界，与凭据的 IAM 权限范围无关。第 3 步在微虚拟机中启动代理，且没有返回到主机的路径。第 4 步使得整个设置可审计：在会话期间，代理允许或拒绝的每个调用，包括代理尝试访问不在允许列表中的目标的任何尝试，都会在 sbx policy log 中显示。

这为工程师提供的端到端功能是一个具有已知且有限访问范围的可运行代理。代理可以进行调查、推理和提出建议，但无法通过执行操作导致整个区域的故障。

实际应用中的表现

暂时从 Kiro 的故事中后退一步，整体情况是清晰的。Docker 沙箱为代理提供了一个真实的运行环境、范围限定的凭据、网络边界，以及在会话结束时能够干净地丢弃所有内容的路径。与目前大多数工程师运行 AI 编程代理的方式相比，这种设置的权衡如下：

| 安全方面 | 传统代理式设置 | Docker 沙箱 | |------------------|------------------------|------------------------| | 身份 | 工程师的完整凭据 | 每个任务的范围限定身份 | | 密钥处理 | 加载到代理上下文中 | 代理注入，从不暴露 | | 生产访问 | 继承自操作员角色 | 明确的允许列表或无访问 | | 破坏性操作 | 以机器速度执行 | 执行前可审查 | | 审计追踪 | 每个工程师，事后 | 实时记录 |

每个沙箱的实时 sbx 策略日志

爆炸半径

工程师可以执行的任何操作

沙箱所配置的任何内容

对 Kiro 故事最重要的那一行是倒数第二行。没有沙箱时，破坏性操作会像代理进程发出的 API 调用一样快速执行。有了沙箱后，同样的操作必须先经过代理，这意味着它会进入工程师的审核队列，而不是直接进入生产环境。

安全代理生产工作的最佳实践

• 永远不要给代理完整的生产凭证。为特定任务创建一个具有最小权限的限定身份。如果代理正在调查只读问题，请只给予它只读访问权限。Kiro 事件就是当跳过这条规则时会发生的情况。

• 通过代理注入密钥，而不是通过环境变量。代理永远看不到的密钥，是它无法意外发送到错误端点、不会在日志中泄露或包含在代码提交中的密钥。通过代理注入，将凭证从代理持有的数据转变为代理提供的能力。

• 将 AI 辅助的更改标记为一个独立的更改类别。跟踪这些更改，要求高级审核，并默认应用双人复核规则。这并不是对 AI 工作流的减速，而是将高级工程师的拉取请求所接受的审核标准应用于一个以机器速度执行操作的代理。

• 阅读策略日志。sbx 策略日志记录了代理在会话期间允许或拒绝的每一次连接尝试。对破坏性端点的尝试被阻止，正是你想要看到的信号，除非有人查看，否则这些信号会被埋没。

• 将采用指标与爆炸半径指标结合使用。亚马逊的 80% Kiro 目标是一个公司级的 OKR。本应与之同步推进的安全措施却没有任何跟踪。在推动使用的同时，没有同步推动安全边界，这就是导致 12 月停机的原因。

立即行动

在与生产环境相邻的环境中实现安全代理工作的第一步是做出一个转变：停止给代理你给予人类的凭证。

• 安装 Docker 沙箱。Docker 沙箱文档会逐步指导你安装 sbx 并运行第一个限定身份代理。

• 阅读安全模型。Docker 沙箱的安全文档详细介绍了凭证处理、隔离层、网络策略和工作区信任。

• 尝试代理注入密钥模式。运行 sbx secret set 后执行 sbx run 是最快看到当密钥位于代理上下文之外而不是内部时威胁模型如何变化的方法。

如果你是本系列的新读者，第 1 期将介绍 AI 编码代理失败的六大类别，第 2 期则深入探讨了文件系统层上的 rm -rf ~/ 事件。

结论

12 月 Cost Explorer 停机和 3 月 Amazon.com 的停机事件是同一条线上的两个点。它们是当代理继承了操作员的凭证、当为人类速度设计的安全措施遇到了以千倍速度运行的决策循环、当采用被推进而安全边界却未被同步推进时所发生的情况。

亚马逊的回应是这个故事中值得记住的部分。“用户错误，具体来说是访问控制配置错误”就像在护栏发明之前，所有著名的工业事故都归因于“操作员错误，而非缺少护栏”一样成立。这些配置错误并不是打字错误，而是结构性的决定，即在不扩展围绕它的身份模型的情况下，扩大智能代理的采用规模。亚马逊之后添加的一切内容，比如同行评审、对AI辅助更改的高级别批准、90天代码安全重置，以及特雷德韦尔所描述的“受控摩擦”，都指向了同样的漏洞。代理需要在一个比它所代表的工程师更小的范围内运行。

Docker Sandboxes 并不是让代理更加谨慎；而是改变了代理可以访问的范围。凭证位于边界之外。破坏性端点不在允许列表中。代理获得了一个真正的运行环境，但不是生产控制平面。

在我们系列文章的后续内容中：第4期将探讨 GitGuardian 的蔓延报告和 s1ngularity 攻击，其中AI代理利用自身的上下文窗口扫描开发者的机器以寻找凭证，以及代理注入的秘密如何消除暴露面。

了解更多

• 使用 Docker Sandboxes 安全运行代理：访问 Docker Sandboxes 文档，立即开始。

• 探索 Docker MCP 目录：发现通过 Docker 的安全优先架构连接代理到外部服务的 MCP 服务器。

• 下载 Docker Desktop：这是通往受控 AI 代理环境的最快路径，Docker Sandboxes、MCP 网关和模型运行器都包含在一个安装包中。

• 阅读 MCP 恐怖故事系列：从第1期开始，了解补充此处讨论的代理层风险的协议层安全风险。

作者简介

开发者倡导者，Docker

Ajeet Singh Raina 是 Docker 的开发者倡导者，撰写并发表关于容器、Docker Compose 和 AI 的文章和演讲，帮助开发者自信地构建应用。

智能代理 AI

AI 代理

工程

目录

相关文章

• 2026年5月12日 Docker AI 治理：安全地解锁代理自主权 介绍 Docker AI 治理：集中控制代理如何执行、它们可以访问网络上的哪些内容、可以使用哪些凭证，以及可以调用哪些 MCP 工具，使公司中的每位开发者都可以在任何工作地点安全地运行 AI 代理。你的笔记本电脑就是新的生产环境。代理是最大的生产力提升…… Srini Sekaran 立即阅读

• 2026年6月16日 Docker 内容信任：退休和迁移指南 Docker 内容信任（DCT）和 notary.docker.io 上的 Notary v1 服务将被完全退役（首次在 2025 年 7 月宣布）。这篇博客解释了将发生的变化、受影响的用户以及如何迁移到现代替代方案。Julia Wilson 和 Aditya Tripathi 立即阅读

• 2026年6月15日 Docker 加入 Athena 联盟：跨行业协作以提高供应链安全 AI 正在降低供应链攻击的门槛。Docker 加入了 Athena 联盟，这是一个跨行业的努力，旨在协调对开源的防御，建立在我们为每个开发者提供默认安全工具和我们跨生态系统共享信号的记录之上。Tushar Jain 立即阅读

• 2026 年 6 月 11 日 Docker 加固镜像通过 Docker 和 Aikido 增强了漏洞扫描功能 Aikido 现在可以扫描 Docker 加固镜像（DHI），并支持内置的 VEX。Docker 验证为不可利用的漏洞会自动从队列中移除，因此开发人员可以专注于真正重要的发现。本文将介绍发生了哪些变化，为什么这很重要，以及用户如何从新的集成中受益。为什么团队会…… Dan Stelzer 和 Bjorn Hovd 立即阅读