企业官网建设流程全解析

如何防止AI"编造漏洞"？security-audit-skill候选门槛7条规则解读

【免费下载链接】security-audit-skillA coding-agent skill for multi-phase security audits with independently verified, machine-readable findings项目地址: https://gitcode.com/GitHub_Trending/se/security-audit-skill

用AI做安全审计，最让人头疼的往往不是"找不到漏洞"，而是AI"编造漏洞"——把想象写成结论。security-audit-skill 是一个让编程 Agent 变身安全审计员的开源技能包：它将多阶段审计流程固化成可执行的规则，其中 HUNTING.md 里写死的"候选门槛"（Candidate gate）7条规则，正是压制AI幻觉误报的核心防线。本文逐条拆解它们如何拦截"编造"。

为什么AI安全审计容易"误报"？

AI审计员的幻觉通常有四种"惯犯"：

• 把检查清单偏差直接当漏洞（"没用加密算法X！"）；
• 把影响夸大（一个崩溃说成代码执行）；
• 看不见就编（猜测部署环境、代理、云配置的行为）；
• 把加固建议包装成"低危漏洞"凑数。

这些都不是猜测，而是项目作者在 SKILL.md "Anti-patterns" 一节中列出的 10 种反模式——等于把AI最容易犯的错写成了明牌。候选门槛7条规则，就是冲着这几种错设计的。

候选门槛7条规则一览

这7条规则位于 HUNTING.md 的 "Candidate gate" 小节，会被逐字复制进每一个"猎手"Agent的提示词中，任何候选漏洞必须全部通过才能进入后续验证：

规则1：漏洞必须自带"完整溯源+证据"

候选不能只是一句"这里可能有问题"，必须包含：

• 一条仓库相对路径的完整 trace：以entrypoint（入口）开始、sink（汇聚点）结束，中间用propagation标注；
• 每个断言都有file:line级证据；
• 还要附"最强的源码可见控制"——也就是你尽力找过防护的证据，防止挑完路径就下结论。

这套 trace/evidence 结构由 report-schema.json 严格约束（additionalProperties: false，多一个字段都不收）。

规则2：confirmed 是全场最硬的坎

想要打上confirmed标签，必须同时满足：

• 有界本地观测结果：在沙箱里真实跑出的最小结果，而不是"理论上会"；
• 有意义的跨边界影响：说清楚哪个低信任主体越过了哪条边界；
• 完整条件+无可见防护层。

SKILL.md 还规定：只有confirmed才能配严重度，且"总体严重度不得高于已证明的影响"——severity 由可能性 × 已证明影响决定，而不是由"偏离检查清单"决定。

规则3：禁止"影响通胀"

这是拦截幻觉最直白的一条：

不许把崩溃夸成代码执行、把普通工作夸成共享服务不可用、把同一主体内的操作夸成权限提升。

配合 SKILL.md 的严重度锚点（critical = 未认证者获得代码执行/全库数据；high = 完全打穿某个明确安全控制……），AI连"感觉很严重"这条路也被堵死了：说不出具体损害，严重度就得往下调。

规则4：看不见，就诚实说"待验证"

部署配置、代理行为、身份策略等仓库里看不到的事实，AI不许"两头猜"。规则4要求：缺失的关键事实必须落成needs_validation记录，并指名道姓写出具体 blocker 和安全的验证方案；同时禁止给这类记录配严重度、禁止"脑补完成"。

这对应 SKILL.md 的"Respect source visibility"原则——部署控制是真实存在的控制，源码里看不到时，既不能假设它存在，也不能假设它不存在。

规则5："缺失最佳实践"不是漏洞

"这里没做限流/没用XX方案"但没有受影响的主体和资源？那不是漏洞，是hardening（加固笔记）。更狠的后半句：一个被源码反驳的候选不能降级成needs_validation苟活，必须记为rejected——反例也要留痕，让以后的运行不再重复同一个错误主张。

💡 项目的设计原则同样明确："防御纵深缺口不是漏洞"（见 README.md）：如果 A 层已经挡住了攻击，缺 B 层只是加固笔记。

规则6：指纹一致，杜绝"分身报障"

同一根因无论处于哪种状态（候选、确认、驳回），都必须使用同一个源码派生的 fingerprint：

• 格式受正则约束（见 report-schema.json）；
• 不得包含行号、波次、Agent、严重度或结论——否则换个行号或换个验证者，同一个问题就会被当成"新漏洞"重复上报。

这是防止AI"编数量"的关键机制：指纹按根因去重，一份报告里同一根因只允许存在一条最终记录。

规则7：空数组也是合法答案

当没有任何候选通过门槛时，返回空的 candidates 数组。

再配合 VALIDATION-AND-REPORTING.md 的最后一句："干净的一轮运行可能确认漏洞数为零，如实报告即可，不要硬造 LOW 级发现。"——允许AI说"我没找到"，是从制度上消灭凑数式误报。

门槛之后：两道独立验证 + 机器校验

过了7条门槛还不算完，候选还要再闯三关：

1. Phase 3 独立验证：每个候选交给一个从未参与狩猎的全新验证者，任务不是确认，而是尝试证伪它（"检查发现的Agent，永远不是发现它的Agent"——README.md）；
2. Phase 4 结构化输出：所有confirmed/needs_validation/rejected记录写入findings.json，并由零依赖的 validate-findings.cjs 按 report-schema.json 做机器校验，结构错误一律打回；
3. Phase 5 终审：再上一批全新Agent逐条复核最终记录的每个路径、行号与影响；若替换会实质升级结论，还得换一个更独立的验证者再审（详见 VALIDATION-AND-REPORTING.md）。

也就是说，"候选门槛"是第一道筛，后面还有独立人格的复核和机器校验——三重拦截下，AI的"编造"很难活着走完整个流程。

如何上手 security-audit-skill？

使用非常简单（细节见 README.md）：

1. 通过 Skills CLI 把技能装到你的编程 Agent 中（支持--global用户级安装）；
2. 在目标代码库中启动 Agent，直接说security audit this codebase或find security vulnerabilities in ./src，技能会自动触发；
3. 等待六阶段流程跑完，在输出目录得到REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md三份报告。

⚙️ 前置要求：支持工具调用与并行子 Agent 的编程 Agent、Node.js（供校验脚本使用）、以及用于本地执行检查的操作系统级沙箱。

总结

security-audit-skill 用一句话回答了"如何防止AI编造漏洞"：不给AI留编造的空间，只给它留举证的路径。

• 门槛前：7条规则把"完整溯源、真实影响、不夸大、不猜测、不凑数、可去重、可为零"写进每个猎手Agent的提示词；
• 门槛后：独立验证者专职证伪、JSON Schema 机器校验、终审Agent换人再审。

这正是它能从单个仓库工具演化为云厂商级漏洞发现系统的原因——对AI安全审计而言，可信的前提不是"AI很强"，而是"每条结论都经得起一个陌生人重新证伪"。

【免费下载链接】security-audit-skillA coding-agent skill for multi-phase security audits with independently verified, machine-readable findings项目地址: https://gitcode.com/GitHub_Trending/se/security-audit-skill