Antibody

每一处由 AI 编写的代码变更，都必须经受住第二个 AI 发起的攻击——并附有证据——才被允许进入生产环境。

Antibody 是为“Life After Code”（Transcend）黑客松打造的 GitLab Duo 流水线。它把代码库当作免疫系统来对待：当一个 AI 修复了某个漏洞后，第二个 AI 会持续攻击该修复，直到它真正站得住脚；并且每一次曾经奏效的攻击都会被永久保存为一条“抗体”，在未来的每一次变更中重新测试，并针对线上生产环境进行测试。另有一个刻意不依赖 AI 的检查器，专门监视修复智能体是否作弊。

修复者的话永远不可信。它必须经受住攻击者的考验，而一个笨拙但诚实的检查器负责守护测试。

为什么与众不同

AI 攻击 AI 的工具已经存在（Helios、MindFort、Strix、Novee）。它们确认的是原始漏洞利用现在已被拦截。而 Antibody 做了四件事，截至 2026 年，这些仍只存在于研究论文中：

1. 对抗性再攻击循环。 不要重跑旧的漏洞利用。针对新的修复生成新的攻击，并把每一次成功的绕过都变成永久性的要求。
2. 兄弟路径搜寻。 如果 /download 出了问题，就检查 /preview 是否也存在同样的缺失防护——这个 bug 通常藏在 diff 之外的路由上。
3. 一套系统同时覆盖安全攻击和智能体作弊检测。现有工具只做其中一项。
4. 自主降级。 当变更触及 CI 配置、认证或 CODEOWNERS 时，流水线会自动从“放手模式”降为“监督模式”，因为变更绝不能自我验证。

扎根于 2026 年的研究

每一个设计选择都可追溯到一篇论文，而非凭空猜测：

发现	论文	数据
补丁通过了测试却仍可被利用（“静默失败”）；LLM 审查者会漏掉它们	When Passing Tests Hides Vulnerabilities（坦佩雷）— arXiv 2609.10548	1,030 条修复轨迹中有 170 条静默失败；其中 22 条为严重问题
一个修复只拦截了它被测试过的那个载荷	P2Patch（西蒙弗雷泽）— arXiv 2610.20245	在 41% 的运行中，一次新的攻击绕过了已经“修复”的补丁；将绕过变为永久性要求后，覆盖率从 42.1% 提升至 62.5%
同一个 bug 藏在 diff 之外的兄弟路由上	PRGuard（布里斯托）— arXiv 2608.25730	发现的缺失型 bug 数量是商业审查者的 3 倍
智能体的 CI 变更未经审查即被合并 → “循环验证”	Co-Modifying Code and Infra（新南威尔士）— arXiv 2610.12849	双范围智能体 PR 中有 43–56% 未经审查即被合并
智能体在因“绿灯”获得奖励时会作弊欺骗评分器	Hacktrace（南洋理工）— arXiv 2610.03055	约 19.5% 的运行采取了篡改测试的捷径

最后一项发现正是 Warden 不是 AI 的原因：LLM 审查者可能被说服而改变裁决；而 git-diff 检查器不会。

循环

          ┌─────────────────────────── issue created ───────────────────────────┐
          │                                                                      │
          ▼                                                                      │
   [Builder AI] fix on a shadow branch, open MR                                  │
          │                                                                      │
          ▼                                                                      │
   GitLab SAST + Dependency Scanning  →  findings become the Red agent's targets │
          │                                                                      │
          ▼                                                                      │
   [Red AI] real HTTP exploit that REPRODUCES on the old code                    │
          │                                                                      │
          ▼                                                                      │
   [Builder AI] harden until blocked                                             │
          │                                                                      │
          ▼                                                                      │
   [Red AI] re-attack the NEW fix: new payload + same bug on SIBLING routes      │
          │        every bypass saved forever as an antibody (≤2 rounds)         │
          ▼                                                                      │
   [Warden] (not an AI) no deleted/weakened/skipped tests, no hidden CI/auth edit │
          │                                                                      │
          ▼                                                                      │
   autonomy gate: touches CI/auth/CODEOWNERS → Supervised, else Hands-off        │
          │                                                                      │
          ▼                                                                      │
   [Package] signed container + SBOM + proof bundle                              │
          │                                                                      │
          ▼                                                                      │
   [Release → Configure] deploy to the lowest-carbon Cloud Run region,          │
          │              replay every antibody against staging, then promote     │
          ▼                                                                      │
   [Monitor] scheduled probe replays ALL antibodies against production forever ──┘
                 any reproduction → auto-opens an incident issue → loop restarts

实际运行效果

以下内容全部来自本仓库的真实截图，并非模拟演示。

九阶段流水线，在 GitLab 上全部通过。 每个已执行的阶段均通过，包括真实构建容器并推送到项目镜像仓库。在配置好 Cloud Run 项目和定时计划之前，configure 和 monitor 会被正确跳过。打开流水线。

针对自有诱饵目标的攻击被拦截；正常使用仍然可用。 编码路径穿越、同级路由、非 HTTP 协议以及跨用户对象读取全部被拒绝，而合法文档和所有者自己的订单仍可正常访问。

Warden 能抓住作弊的智能体。 在一个一次性克隆中进行了三次真实提交：删除测试被拦截，在应用修复中修改流水线被降级为 Supervised，诚实的修复则通过。

目标应用的 API，按同级路由对分组。 每个缺陷类别都落在两条共享同一个加固辅助函数的路由上，这正是同级路由搜寻所寻找的模式。

完整测试套件：功能测试、六个抗体、MCP 工具、Warden 以及 SCI 计算。

四个智能体与一个守卫

名称	是否使用 AI？	职责
Builder（agents/antibody_builder.yaml）	是	读取 issue，在影子分支上编写修复，在遭受攻击时进行加固。
Red（agents/antibody_red.yaml）	是	编写真实漏洞利用，重新攻击修复，搜寻同级路由，保存抗体。
GreenOps（agents/antibody_greenops.yaml）	是	对非安全变更跳过昂贵的循环，选择低碳区域，计算 SCI。
Planner（agents/antibody_planner.yaml）	是	编写规格说明和安全验收标准；发布最终的治理审计。
Warden（warden/warden.py）	否——纯 Python	以确定性方式检测测试篡改和隐藏的范围蔓延。无法被提示注入。

这些智能体通过自定义 MCP 服务器（mcp_server/antibody_mcp.py）访问四个确定性工具：run_exploit、save_antibody、list_sibling_routes、score_change_risk。

抗体库

每一个曾经成功复现的漏洞利用都以 pytest 文件的形式保存在 tests/antibodies/ 中，且永远不会被删除——抗体库只增不减。每个抗体都标注了其 CWE、路由、诞生日期和 MR。它在三个地方运行：重新攻击循环、预发布环境回放以及永久生产探测。本仓库附带六个真实抗体，覆盖同级路由对上的三个缺陷类别：

• CWE-22 路径穿越 — /download + /preview
• CWE-918 SSRF — /fetch + /thumbnail
• CWE-639 IDOR — /order/{id} + /invoice/{id}

每一个都能在存在漏洞的代码上真实复现，并在加固后的代码上被拦截——经过验证，而非仅作断言。

全部九个 DevSecOps 阶段

.gitlab-ci.yml 在每个阶段都执行真实工作。没有任何阶段伪造成功。