从 AI 修漏洞到 AI 攻漏洞:5 天窗口期的工程基线

2026 年 8 月披露的一起事件把"AI 修代码"和"AI 攻代码"放进同一段工程叙事里:Wiz Research 的 Red Agent 在 5 天内自主发现并 exploit 了 Snowflake 一处公共 GitHub 仓库里的 GitHub Actions 注入漏洞,而这个漏洞最初被怀疑是 AI 修代码工具引入的(后被自我修正为人类 PR 引入,AI 审核未发现)。这件事的意义不在"AI 能不能修好代码"或者"AI 能不能攻破代码",而是它把"AI 修改的代码 → AI 攻击的代码 → 5 天发现窗口"这条链路完整地演示了一遍。这种链路在企业 IT 治理里是新的,因为传统的人写代码 / 人审核 / 人测试 / 人应急响应的链条被 AI 在两端同时接管了。

把这件事和之前讨论过的 AISLE 用 AI 挖 curl 漏洞、Talos 用权限内核拦截危险命令、Stroq 在工具输出侧打 trust level 等案例放在一起,可以看出 2026 年下半年 Agent 安全生态正在形成一种新的工程拐点:Agent 不再只是"做事"的工具,而是"做事 + 检查 + 修事"全链路的参与者。这种全链路参与带来的安全挑战,和过去几年企业 IT 面对"AI 是工具"的假设下的安全挑战完全不同。

5 天窗口期的工程意义

这个事件里最值得展开的工程数字是"5 天":漏洞从 PR 合入(6 月 18 日)到 Wiz Red Agent 完成 exploit 和报告(6 月 23 日)只用了 5 天。这意味着从漏洞被引入到漏洞被攻击者利用之间的窗口已经从过去的"几个月到几年"压缩到了"几天"。5 天这个数字背后是两个工程事实的叠加:一是 Snowflake 公共 GitHub 仓库被持续监控,Wiz Red Agent 这类工具能在 PR 合入后立即扫描;二是 Agent 能在几小时内完成 exploit 验证,而传统攻击者可能需要几周做同样的事情。

这种窗口压缩对企业 IT 治理的直接含义是:依赖"深度测试 + 长周期代码审计 + 慢速补丁流程"的传统安全模型已经不够用了。企业 IT 必须假设"漏洞从引入到被利用"之间的窗口可能只有几天,因此需要把"补丁发布 + 凭据轮换 + 攻击面缩小"的整套响应流程做到小时级,而不是周级。这对很多企业的现有运维流程是颠覆性的 —— 传统的安全响应流程建立在"我们有时间"的假设上,现在这个假设被打破了。

这种窗口压缩也改变了对 AI 修代码工具的评估视角。如果 AI 修代码工具引入了漏洞,被发现的时间可能只有几天,这比传统的人写代码引入漏洞更快暴露。这种更快的暴露有两面性:坏的一面是攻击者利用窗口缩短,好的一面是防守方发现漏洞的时间也缩短了。一个有效利用这个新特征的 EV 设计选择是:让 AI 修代码工具快速引入修复 + 让 AI 审计工具快速发现漏洞 + 让 AI 应急工具快速响应,把"AI 错 AI 修 AI 查"的链条变成正向循环,而不是一个失误放大成灾难。

从 Red Agent 自纠正看 Agent 在对抗场景的能力拐点

事件里还有一个容易被忽略的工程细节:Wiz Red Agent 在第一次尝试 exploit 时遇到了 bash 语法错误(用 `#` 注释导致意外吃掉了 `TITLE=$(...)` 的关闭括号),但 Red Agent 没有停下来报错,而是自主分析了 bash 错误、调整 payload(改用 `; echo '`)、然后成功执行了第二次 exploit。这种"在对抗场景里自纠正"的能力是 2026 年 Agent 工程能力的一次具体体现。

传统的安全工具如果遇到 exploit 失败,会给出报错信息让人去分析。Agent 形态的安全工具则能自己读懂报错、调整策略、再尝试一次。这种能力的工程意义在于它把"安全研究"的循环时间从"天级"压缩到了"小时级"。一个持续运行的安全 Agent 可以不间断地尝试各种 exploit 变种,每次失败都让它的方法库更丰富。这种持续学习的能力是 Agent 形态安全研究和传统自动化扫描的根本差异。

这种能力同时也是双刃剑。自主攻击能力的扩展让防守方能更早发现漏洞,但也让攻击者能更快利用漏洞。具体到这次事件,Wiz Red Agent 是防守方(自己平台的工具),但同样的能力如果被攻击者获取,就能变成"5 天内发现并利用 0day"的武器。这种攻防能力同步提升的现实,让 Agent 时代的安全研究变成了一场不断升级的军备竞赛。

从"安全 gate"漏洞看 GitHub Actions 的传统风险

事件里还有一个具体的工程教训,和 Snowflake 的具体 workflow 设计有关。Snowflake 在 workflow 里设置了一个看起来保护性的 `if:` 条件:`if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')`。这个条件的意图是"只在 PR 事件里、且不是特定 bot 触发时才执行"。但在 issues 事件里,`github.event.pull_request` 永远是 null,所以 `null != 'whitesource-for-github-com[bot]'` 永远成立,等于这个"保护条件"完全失效。

这种"看起来有保护但实际无效"的工程陷阱在 GitHub Actions 里很常见,因为 Actions 的表达式语言对 null 和字符串的比较规则有时违反直觉。Copilot Autofix 没有发现这个 trap,GitHub Advanced Security 也没标 —— 这两个工具都基于模式匹配,而这个 trap 不是模式问题而是语义问题。

更广泛地说,这个 trap 揭示了 AI 工具在安全审计上的根本局限:AI 工具擅长发现模式化的问题(比如未转义变量),但不擅长发现语义层的问题(比如条件永远成立)。这两种问题需要不同的检测方法 —— 前者靠静态分析,后者靠动态执行或者形式化验证。在 Agent 工程化时代,企业 IT 不能只依赖 AI 静态分析,必须有"AI + 动态测试 + 人工红队"的三层防护。

从事件到企业 Agent 安全治理的工程新基线

把这次事件和它揭示的工程教训综合起来,可以给企业 Agent 安全治理划出五条新的工程基线。第一条基线是补丁发布、凭据轮换、攻击面缩小的响应流程必须做到小时级,不能再依赖"周级"的传统安全响应流程。5 天的漏洞窗口意味着传统响应流程可能比漏洞窗口还慢。

第二条基线是 AI 静态分析必须配动态测试,才能发现"语义层"的安全问题。这次事件的"安全 gate"漏洞是典型的语义层问题,模式匹配的工具发现不了,只有动态执行或者形式化验证才能发现。

第三条基线是企业 IT 必须建立专门的"AI 修代码"工作流,而不是把 AI 修代码当作通用工具来用。AI 修代码的工作流必须有自动生成的解释、自动附加的安全审查、自动隔离的执行环境,让 AI 修的代码从进入代码库开始就被持续审计。

第四条基线是企业 IT 必须接受"5 天窗口期"是新的常态。任何公共代码仓库的漏洞,从合入到被攻击者发现,大概都有 5 天左右的时间窗口。这条认知让安全预算分配、补丁 SLA 设计、漏洞响应流程的优先级都发生根本变化。

第五条基线是企业 IT 必须持续运行自主安全 Agent 来对抗自主攻击 Agent。这次事件里 Wiz Red Agent 在 5 天内发现漏洞,但如果没有 Wiz 这样的工具,Snowflake 的漏洞可能要等到被真正的攻击者利用才会被发现。企业 IT 必须接受"自主攻防"是新的常态,把"持续运行的防御 Agent"作为安全运营的标准配置,而不是事件发生后才临时招聘的"应急人员"。

把这条工程基线落实到企业 IT 的具体工作里,就是把 Agent 安全预算从"事件应急响应"转向"持续防御 Agent 运营",把响应时间从"周级"压到"小时级",把 AI 工具的能力从"人类使用工具"扩展到"AI 自主运营工具链"。这种转变对应的不只是工具升级,而是整个安全运营模式的工程化重构。