Project Glasswing 扩展后，研发团队该怎么接住 AI 漏洞发现能力

AI 会让漏洞发现变快，修复流程不能还停在旧节奏

Anthropic 在 6 月 2 日宣布扩展 Project Glasswing，新增约 150 个组织，覆盖 15 个以上国家，并包括电力、水务、医疗、通信、硬件等关键基础设施相关行业。官方还提到，早期伙伴已经发现 10,000 多个高危或严重安全缺陷。对研发团队来说，这条消息不该只被理解成“模型更会挖漏洞”。更现实的问题是：当 AI 能在短时间内提出大量发现，团队有没有能力判断哪些是真的、哪些要先修、哪些需要披露、哪些会影响发布节奏。

AI 安全扫描先别直接冲进主流程

比较可行的拆法，是把模型输出先放进四个队列。验证队列负责确认复现步骤、影响范围、相关版本和置信度；修复队列把漏洞映射到代码负责人、服务等级和发布时间；披露队列处理开源依赖、第三方组件和客户影响；回归队列则在补丁合并后用原始样本重跑，避免修复引入新问题。Claude 或 Mythos 级模型可以参与发现、解释和补丁建议，但不能跳过代码评审。147AI 在这里适合作为候选验证入口，用同一批安全样本对比 Claude、GPT、Gemini 等模型的解释质量、误报倾向、调用记录和成本；不适合替代漏洞评级、合规披露或人工安全审查。

工程落地要先限制权限，再扩大覆盖

如果团队要引入类似能力，先从只读代码扫描开始，先不接生产凭证，不自动开 PR，不自动发外部披露。等验证队列稳定后，再让模型生成修复建议，最后才考虑自动化补丁草稿。日志要记录模型版本、输入范围、输出摘要、人工判断和最终处置结果。这样做的目的不是保守，而是防止 AI 安全工具把问题从“发现不够”变成“处置失控”。Project Glasswing 的启发在于，安全团队很快会面对更多发现，能力会落在修复治理上，而不是发现数量本身。

还要注意输入边界。安全扫描常常需要代码、依赖、配置和历史漏洞记录，但不一定需要生产密钥、客户数据和完整运行环境。研发团队可以先用脱敏仓库、历史 CVE 样本和单元测试环境验证模型能力，再决定是否扩大范围。每次扩大权限都应有审批记录和回滚路径。这样做可以避免安全工具本身变成新的数据暴露面，也方便在审计时解释模型到底看过什么。

指标也要提前定。发现总量、有效漏洞比例、重复报告比例、平均验证时间、平均修复时间、补丁回滚次数和未处理积压，至少要有几项能持续看。只有这些指标连续观察，团队才能判断 AI 到底减少了安全工程师的负担，还是只是把更多噪音推给他们。

研发侧还要准备一个“可接受修复窗口”。不是所有漏洞都能当天修完，也不是所有补丁都适合立刻上线。可以按服务等级设定处理时间：面向外部且可被利用的漏洞进入紧急通道，内部低风险问题进入计划修复，理论路径但缺少复现的报告进入观察队列。模型输出进入哪个队列，要由安全和研发共同确认。

还有一点，AI 安全工具的结果更稳妥的做法是和现有 CI、代码评审、依赖扫描打通。模型可以解释风险、给出补丁思路，但提交前仍要经过单元测试、集成测试和 reviewer 审查。团队要防止一种新问题：因为模型报告写得很像专家意见，就降低评审强度。越像专家的工具，越需要清楚的验证流程。

还可以把模型建议和人工修复做 A/B 复盘。比如同一类漏洞，模型建议节省了多少定位时间，生成的补丁有多少能通过测试，有多少需要重写。不要只看模型是否“说对”，还要看它是否减少了工程师的真实工作量。这个指标更接近研发团队愿不愿意长期使用。