AI 补丁攻击重放
AI 自动修复进入合并前，产品重放真实攻击路径，证明漏洞已被堵住且没有打开新的越权入口。
安全工程师审查 AI 生成的修复代码时，最难回答的问题不是测试是否通过，而是原先那条入侵路径是否真的断了。一次与 AI 自动修复有关的攻陷事件提醒团队：功能测试绿了，认证、权限或第三方集成的边界仍可能被改坏。把补丁合进主干前，需要一份能重放的攻击结果，而不是一段“看起来合理”的代码解释。
开发者在安全 PR 中附上漏洞说明、受影响接口和复现条件。检查服务在隔离环境部署修复前后的两个版本，从调用链、权限配置和测试账号构造同一条攻击路径。它分别执行这条路径，记录请求在哪一步获得权限、读取数据或调用敏感接口，再把两边的行为差异挂回 PR。
评审页不会只显示一个风险分数，而会展示“旧版本在这里越权，补丁版在这里被拒绝”的可点击轨迹。若补丁堵住旧路径，却新开了高权限调用、绕开日志或扩大令牌范围，检查会标出新路径。无法稳定重放的情况进入人工安全审批，避免系统把不确定性伪装成已修复。
首版服务于 Web 应用中的身份认证、权限校验和第三方工单集成，使用团队提供的隔离账号与测试数据。它不扫描所有代码库，也不替代渗透测试；目标是让每一份 AI 安全补丁在合并前留下“攻击为何失效”的行为证据。
为什么是现在
8月17日，Wiz披露一项已被真实利用的漏洞：Copilot Autofix被列为合并提交共同作者，AI审查却未发现脚本注入。S1 截至8月18日，该帖在 Hacker News 排第5，记录为306分、123条评论，安全团队更容易追问补丁是否真正切断攻击链。S2
目标用户
核心用户是负责批准安全修复的应用安全工程师，以及承担合并责任的资深开发者。关键时点是 AI 或自动工具提交补丁后、保护分支放行前。此时单元测试只能证明功能没有明显损坏，却不能回答原攻击者身份是否仍能越权。遇到认证、权限或第三方令牌改动时，他们需要可重复的行为证据来签字。
最小切入点
入口做成 GitHub App，监听安全 PR 和检查请求。团队用声明式文件提交角色、种子请求、前置状态与成功断言。GitHub Actions 分别检出基线提交和补丁提交，并用 Docker Compose 启动隔离环境。HTTP 与浏览器链路可由 Playwright 重放，服务端则接入审计日志或 OpenTelemetry 轨迹。结果通过 Checks API 回写逐步差异，并附上脱敏请求证据。范围先收窄到认证、对象级授权和工单 API，不尝试自动生成任意漏洞利用。
以小博大
获客内容应直接来自可公开复现的安全补丁。为 GitHub Actions 注入、IDOR 和 OAuth 权限扩大制作开源重放样例，并发布对应的 GitHub Action。每个样例展示普通测试通过后，攻击仍能成功的具体步骤。安全顾问和应用安全工程师可把这些工件直接附进客户 PR，由实际评审流程带来首批私有仓库试用。
竞品与缝隙
怎么赚钱
按活跃私有代码库收取月费，包含基础重放额度。超出部分按隔离环境的执行用量计费。
反方视角
团队必须同时启动两个可测试版本，并提供最小权限账号和可重置数据。单点登录、短期令牌和第三方回调会让重放频繁失稳。攻击脚本本身可能外传密钥或破坏测试数据，因此隔离环境还要限制出网、托管凭据并自动清理。只比较状态码也会产生错误结论，漏洞可能换一条路径继续成功。加入审计日志和调用轨迹后，部署适配工作会明显增加。角色矩阵越复杂，执行时间和计算费用越难塞进 PR 流程。若证据偶尔把未修复标成已修复，安全团队很快会取消强制门禁。