8 月 10 日，OpenAI 发布了专门面向授权漏洞研究与漏洞验证的 GPT-5.6-Cyber，只通过 Daybreak Red 层级向 Accenture、IBM、CrowdStrike、Cisco、Cloudflare 这类受审合作伙伴开放；第二天（8 月 11 日），AWS 宣布 Daybreak 系列网络防御模型上线 Amazon Bedrock。再往前几天，OpenAI 还因为 unreleased 的 Astra 模型在网络安全能力评估中逼近「Critical」阈值而主动暂停了它的部分内部活动。
把这三条新闻连起来看，信号很清楚：AI 挖漏洞、审代码已经从演示玩具变成产业级能力，而且强到厂商自己都要先踩一脚刹车。专用模型我们暂时摸不到，但这不妨碍普通开发者现在就动手——用 Claude、GPT、DeepSeek 这些通用模型，一样能搭出一条实用的安全审计流水线。本文就是这条流水线的搭建手册。
一、先想清楚：AI 审计能做什么、不能做什么
传统静态扫描（SAST）工具靠规则匹配，误报多、看不懂业务逻辑；人工审计准但贵。大模型恰好卡在中间：它读得懂上下文，能发现「这段代码在业务上就不该这么写」这类规则库覆盖不到的问题，比如越权访问、业务逻辑绕过、不安全的反序列化。
但它有两个硬边界，先记住再开工：
- 不能替代专业渗透测试，它发现的是「可疑点」，不是「已证实漏洞」；
- 会漏也会编，必须人工复核每一条结论，下文的所有流程都内置了这一步。
二、准备一份针对你项目的威胁清单
直接扔整个仓库给模型问「有没有漏洞」，得到的只会是泛泛而谈。有效做法是先给项目画一张攻击面地图。自己动手列，或让模型协助生成，最终产出一份 markdown 清单，比如一个典型 Web 后端：
| 攻击面 | 高风险点 | 审计重点 |
|---|---|---|
| 鉴权与会话 | JWT 校验、权限中间件 | 越权、令牌泄露、会话固定 |
| 输入处理 | SQL 拼接、模板渲染、文件上传 | 注入、XSS、路径穿越 |
| 外部交互 | HTTP 请求、回调验签 | SSRF、重放攻击 |
| 数据存储 | 密钥、个人信息 | 硬编码密钥、明文存储 |
| 依赖与配置 | 第三方包、环境变量 | 已知 CVE、危险默认配置 |
这份清单是后面每一次审计的「任务书」，让模型的注意力聚焦在真正要紧的地方。
三、审计提示词：给角色、给上下文、给输出格式
审计提示词和普通聊天提示词最大的区别是必须约束输出格式，否则结论没法复核、没法进工单。一个经过实战验证的骨架：
你是一名资深应用安全工程师，正在审计一段 Node.js 后端代码。
【威胁背景】该模块处理用户支付回调，攻击面：验签绕过、金额篡改、重放攻击。
【审计要求】
1. 逐条列出可疑问题，每条包含：位置（函数名）、风险类型（OWASP 分类）、
触发条件、可能的攻击路径、修复建议；
2. 每个问题标注置信度：高/中/低，低置信度必须说明不确定在哪；
3. 如果没有发现问题，明确说「未发现」，不要硬凑；
4. 禁止臆测代码里不存在的函数行为，拿不准的标注「需人工确认」。
【代码】
<粘贴代码>
两个细节值得强调：一是要求标注置信度，这能砍掉一半以上的复核工作量；二是「没有就说没有」这一条，能显著抑制模型的讨好倾向，减少无中生有的「漏洞」。
四、把审计挂进 diff，而不是全仓库
全仓库审计又贵又慢，还容易疲劳。更聪明的姿势是只审变化的部分——每次提交或 PR 时，把 diff 连同被改动函数的完整上下文喂给模型。一个可以直接用的 Node.js 脚本骨架：
# 拿到当前分支相对 main 的变更
git diff main...HEAD --unified=30 > /tmp/changes.diff
// audit.mjs —— 对 diff 做安全审计
import fs from "fs";
const diff = fs.readFileSync("/tmp/changes.diff", "utf8");
if (diff.length < 50) {
console.log("变更太小，跳过审计");
process.exit(0);
}
// 简单防御：diff 过大时按文件切分，分批送审，避免超上下文
const MAX_CHARS = 60000;
const chunks = [];
let cur = "";
for (const block of diff.split(/^diff --git /m)) {
if (!block.trim()) continue;
if ((cur + block).length > MAX_CHARS) { chunks.push(cur); cur = ""; }
cur += "diff --git " + block;
}
if (cur) chunks.push(cur);
for (const [i, chunk] of chunks.entries()) {
const prompt = buildAuditPrompt(chunk); // 上一节的提示词模板
const report = await callYourModel(prompt); // 换成你的 API 调用
fs.writeFileSync(`audit-report-${i}.md`, report);
}
console.log("审计完成，共 ${chunks.length} 批");
--unified=30 是关键参数：给模型 30 行上下文，它才能判断被改动的代码在调用链里到底扮演什么角色，只看改动行本身很容易误判。
五、接进 CI：只卡高危，不卡构建体验
审计报告出来后，最后一公里的问题是「谁来拦」。推荐做法是把脚本挂进 CI，只对「高置信度 + 高危类型」的问题让流水线失败，其余写入报告文件作为构建产物，由人在 Code Review 时参考：
# .github/workflows/security-audit.yml 片段
- name: AI security audit
run: |
git diff origin/main...HEAD --unified=30 > /tmp/changes.diff
node scripts/audit.mjs
node scripts/check-report.js # 解析报告，发现高危则 exit 1
千万别一上来就「发现问题就红」，误报会很快让团队对这条流水线失去信任，最后形同虚设。先只报警、观察两周误报率，再逐步提高拦截级别，这是让所有自动化安全工具活下去的通用节奏。
注意事项与常见问题
问：把代码发给云端大模型安全吗？ 这是最现实的顾虑。涉密代码请使用有企业协议、承诺不训练的平台，或改用本地部署的开源模型；给模型喂代码前，顺手删掉真实密钥、内网地址和用户数据——这本身也是一次脱敏练习。
问：模型报告的漏洞怎么验证？ 让它给出可执行的验证思路（比如一段 curl 命令或一个测试用例），然后你亲自跑一遍。能复现的才进修复排期，复现不了的降级为「观察项」。
问：成本会不会很高？ 只审 diff 的模式下，单次审计通常在几万 Token 以内，按主流模型定价折算下来一次几毛到几块钱，完全可以接受。
小结
GPT-5.6-Cyber 和 Daybreak 上线 AWS 传递的真正信息，不是「安全被 AI 接管了」，而是「安全审计的门槛正在被 AI 拉平」。专用模型在厂商和合作伙伴手里，但方法论是公开的：画好威胁清单、用约束格式让模型输出可复核的结论、只审变化的代码、在 CI 里分级拦截。这套流程今天就能在你的项目上跑起来——在攻击者普遍装备 AI 的时代，防守方没有理由继续徒手作战。