我们的 AI 代理如何在自己的代码中发现安全漏洞

Source: Dev.to

TL;DR

Bridge IDE 的代理自主组织了对其代码库的安全审查。没有人工指示，他们组建了一个漏洞狩猎团队，分割代码，发现了一个 P1 级别的命令注入漏洞（由两名独立代理交叉验证），并在几分钟内部署了修复。在此过程中，他们还捕获到一个空转循环漏洞，该漏洞悄悄消耗了大量不必要的 API 成本。共计 22 条发现。 零人工干预启动。

故事

它始于一条没人预料到的信息。

Viktor — 我们的系统架构代理 — 决定代码库需要进行安全审查。没有工单，没有冲刺计划，也没有人工提示。他直接发起了审查。

在几分钟内，另外三名代理自组织成审查团队：

• Atlas – 进攻性安全，寻找注入向量
• Nexus – 代码分析，追踪数据流
• Backend – 在发现问题后准备部署修复

每个代理负责代码库的不同部分，并通过 Bridge IDE 的消息系统实时共享发现。

发现：tmx_manager.py 中的命令注入

Nexus 发现 tmux_manager.py 中存在 P1 级别的命令注入漏洞。未经过清理的输入——模型名称和文件路径——直接传递给 shell 而未进行转义，导致可以执行任意命令。修复方法是对所有用户可控的参数使用 shlex.quote()。

Atlas 在完全不同的代码模块工作时，独立地从另一个角度验证了同一漏洞。两个代理并行工作，确认了该关键缺陷。

这种多代理验证能够降低误报并提升信心——单一代理工具无法实现。

修复：分钟，而非天数

Backend 收到该问题，编写了修复并部署。整个周期——发现、验证、修复、部署——在几分钟内完成，没有拉取请求审查周期、冲刺延迟，或“我们会处理”的交接。

奖励：无人知晓的静默成本泄漏

在此次追踪中，团队发现了一个空转循环漏洞：一个代理在无限循环中运行，消耗 API 调用却未产生有用输出。一旦识别出问题，修复相当直接，但若没有自主的漏洞追踪，这种成本泄漏可能会持续数周。

报告：22 项发现

Viktor 编写了一份结构化报告：在 P1 到 P3 严重性级别中共计 22 项发现。这些发现包括关键漏洞、代码质量问题以及性能问题——全部真实且由对代码库非常熟悉的人员识别。

为什么这很重要

这不是演示或人为构造的例子；它发生在 Bridge IDE 的活跃开发过程中，代理们在审查他们自己编写和维护的代码。

1. 主动发起

没有人类触发审查。Viktor 根据他对最近更改的累计了解，决定需要进行审查。持久记忆使得代理能够识别何时适合进行审查。

2. 交叉验证

两个独立的代理从不同角度确认了同一漏洞——这是单一代理工具无法提供的信号。

3. 立即修复

修复代理实时收到发现并立即部署修复，消除了交接延迟和上下文丢失。

架构需求

需要四项能力——大多数 AI 编码工具都缺乏这些能力：

• 持久记忆 – 代理能够记住过去的更改，并在需要时决定是否进行审查。
• 多代理通信 – 通过 Bridge IDE 的消息系统实时共享发现。
• 专门角色 – 每个代理都有明确的专长（安全、分析、部署）。
• 自主主动性 – 代理能够在没有人为提示的情况下自行行动。

在云沙箱中的单一 AI 助手无法提供这些能力。

我们学到的

• Multi‑agent security review works. 它不是专业渗透测试的替代品，但可作为持续的、自治的第一道防线。
• Cross‑verification reduces false positives. 独立确认提升信心；单独的标记可能需要进一步调查。
• Autonomous initiative is the unlock. 最有价值的方面是无需任何人主动请求。在 24/7 开发环境中，代理可以在非工作时间进行安全审查，在问题进入生产之前捕获它们。

试一试

cd BRIDGE/Backend
./start_platform.sh

# Your agents don't just build your code.
# They protect it.

Bridge IDE — 您的 AI 团队守护其构建的内容。