截至 2026 年 9 月 21 日，security-audit-skill 官方仓库已经明确采用 6 个审计阶段：侦察、覆盖驱动排查、候选验证、结构化输出、独立记录复核和报告生成。(官方 GitHub 仓库)
症状： AI Coding Agent 能扫描代码，却无法说明哪些路径真正覆盖、哪些问题已经验证，甚至可能在本机直接执行不可信构建脚本。
最快解法： 把 security-audit-skill 当作代码库的初步审计与重复性漏洞排查工具，先准备隔离沙箱、最小权限和可追溯输出，再由人工复核确认结果。
这篇文章适合需要统一审计流程的安全工程师、后端开发者和技术负责人。你可以据此判断安装是否成功、审计是否漏扫、误报如何分级，以及本地设备不足时是否应该迁移到远程云端 Mac 或独立开发环境。
最后更新于 2026 年 9 月 21 日，数据核实自 security-audit-skill 官方 GitHub 仓库的 README、SKILL.md、验证脚本和相关审计流程文件。发布前仍应重新检查仓库的安装命令、输出结构和 Agent 兼容要求。
先确定适用边界
security-audit-skill 不是独立的漏洞扫描器，也不是可以替你完成上线前签字的自动渗透测试平台。它加载到 AI Coding Agent 后，负责协调源码侦察、多个隔离 Agent、候选复核、机器可读结果和报告文件；最终责任仍在审计人员和项目负责人。
官方流程首先要求识别架构、信任边界、输入面和已有证据，然后用 coverage ledger 记录检查范围。它的价值不只是“多找几个可疑字符串”，而是让你知道哪些目录、接口、边界和攻击类别已经检查，哪些仍然没有足够证据。
你可以把实际任务分成三类：
- 全量代码库审计： 明确要求完整审计或生成正式报告时，运行六阶段流程。
- 定向漏洞排查： 只检查某个认证流程、解析器、权限边界或数据导出路径时，优先使用聚焦审查。
- 安全问答： 询问某段代码是否存在风险时，不应自动创建完整审计目录，也不应让 Agent 擅自执行目标代码。
这种区分很重要。官方 SKILL.md 把指导模式和完整审计模式分开：加载技能本身并不授权完整流程、文件创建或目标代码执行。(官方 SKILL.md)
安装与触发失败
安装命令
官方 README 给出的安装方式是：
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
如果希望安装到用户级目录，可以使用：
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit \
--global
命令完成后，不要立即把“安装成功”当作“代理可用”。你还需要确认 4 个条件：
- 当前 AI Coding Agent 能加载
SKILL.md或等价技能文件。 - 代理支持工具调用和并行子 Agent。
- 本机存在 Node.js，用于运行 findings 和 coverage ledger 验证脚本。
- 代理可以读取目标代码库，但不能默认读取宿主机凭据、其他项目目录或共享服务。
Node.js 官方下载页当前列出的 LTS 版本为 v24.21.0，同时提供 Current 分支。对于这类验证脚本，优先使用受支持的 LTS 版本，而不是为了追新版本把运行环境变成新的不确定因素。(Node.js 官方下载页)
首次触发
把 Agent 启动在目标仓库根目录，或者显式指定代码库路径，然后使用清晰的触发语句：
security audit this codebase
也可以指定范围：
find security vulnerabilities in ./src
如果需要生成交付物，应直接写明输出目录：
do a security review and write report artifacts to ~/audits/demo-project
官方说明中，明确的代码库审计、渗透测试请求或报告产物请求会进入完整审计模式；安全问题咨询和聚焦调查则默认进入指导模式。完整模式下，如果你没有指定输出目录，默认路径为 ~/security-audit-skill/<repo-name>/run-<N>。
安装成功但没有触发
遇到“Agent 仍然像普通编程助手一样回答”的情况，按下面顺序排查：
- 先检查 skill 实际安装路径，确认目录中存在
SKILL.md。 - 再确认当前代理是否支持 Skills CLI 生成的安装布局。
- 将提示词改为明确的“对整个代码库执行安全审计并生成报告”，不要只说“帮我看看代码”。
- 确认当前目录确实是目标仓库，而不是父目录、空目录或只包含压缩包的目录。
- 检查 Node.js 是否能执行
.cjs验证脚本。 - 若平台不支持并行子 Agent，只能使用等价的委派机制；不能假设单 Agent 顺序执行会自动保留原有的独立性边界。
官方仓库将该技能描述为 agent-neutral，也就是说它提供流程、角色和文件约束，但不会替你解决每个 Agent 平台的加载、权限和沙箱实现。Claude Code、Codex 或其他平台能否完整运行，应以实际试跑结果为准，而不是把社区兼容列表当成官方承诺。
审计覆盖与误报控制
Reconnaissance 与 coverage ledger
第一阶段不是“直接扫描所有文件”，而是先建立项目地图。你应要求 Agent 记录：
- 服务、模块、CLI、后台任务和外部依赖；
- 信任边界及其两侧的主体、资源和权限；
- HTTP、RPC、消息队列、文件解析、Webhook 等输入面；
- 已有测试、历史修复、威胁模型和已知限制；
- 每个覆盖单元的状态、证据和未解决问题。
官方仓库把 architecture.md 和 coverage-ledger.json 作为侦察与覆盖记录的重要产物，并要求后续猎手根据 ledger 分配任务，而不是只围绕热门目录反复搜索。
脱敏覆盖示例
假设一个后端项目有以下路径：
/api/login
/api/import
/admin/export
worker/process-job
parser/read-config
脱敏后的覆盖记录可以这样表达：
{
"unit": "api-import-to-storage",
"surface": "POST /api/import",
"boundary": "untrusted-upload-to-server-filesystem",
"attack_classes": ["path-traversal", "archive-processing"],
"status": "candidate",
"evidence": ["src/import-handler.ts:42-88"],
"next_action": "verify with inert archive fixture inside sandbox"
}
这个记录会直接改变后续审计方向。Agent 不应因为 /api/login 更常见，就跳过文件写入、后台任务和配置解析；也不应把“已经读取过源码”误写成“已经验证过边界”。
官方仓库还强调，多次审计是增量关系：后续运行会参考已有 ledger 和 findings，重新检查变更路径，并把未解决或过期证据继续保留为待验证状态。
三种结果状态
审计报告至少要区分：
| 状态 | 代表什么 | 你可以如何处理 |
|---|---|---|
confirmed |
有完整源代码路径，并在受控环境中得到边界结果 | 进入正式报告，安排修复和人工复核 |
needs_validation |
有具体候选和未解决事实，但缺少安全验证条件 | 补充部署、权限或沙箱证据，不直接评级 |
rejected |
候选已经被源码或受控测试推翻 | 保留驳回理由，避免下次重复误报 |
confirmed 不是“模型觉得很严重”，而是源代码证据、受影响主体、实际结果和验证过程已经连起来。needs_validation 也不是低危漏洞，它表示目前还不能确认。官方 README 对三种 verdict 的定义，正是为了避免把可疑线索直接升级为安全问题。
降低误报的重点不是让模型输出更多规则，而是让发现者和验证者分离。发现候选的 Agent 不应再次充当唯一验证者；验证者要尝试推翻候选，确认是否真的跨越了信任边界，而不是仅仅发现了缺少某个防御纵深。
沙箱与最小权限
不能在普通开发目录里直接执行
security-audit-skill 的官方要求包括操作系统级沙箱、禁用外部网络、显式允许的环境变量、资源限制，以及只允许写入指定 scratch 路径。没有这些控制时，流程应把候选保留为 needs_validation，而不是为了“跑出结果”直接执行目标代码。
需要进入沙箱的对象包括：
- 目标代码控制的构建脚本和测试脚本；
- 浏览器、模拟器、模糊测试器和解析器；
- 可能读取配置、创建文件或启动进程的 fixture；
- 由仓库依赖触发的安装后脚本或生成步骤。
你至少要检查以下权限边界：
- 网络： 默认禁止外部网络，只允许必要的隔离回环通信。
- 凭据： 使用虚拟 Token、虚拟用户和虚拟密钥，不传入真实环境变量。
- 写入： 目标程序只能写入分配的 scratch 目录。
- 读取： 不暴露宿主机 Home、SSH 密钥、云凭据、浏览器配置和其他项目。
- 资源： 限制 CPU、内存、进程数、文件大小、磁盘空间和最长执行时间。
- 依赖： 不允许构建阶段自行访问网络安装依赖，优先使用已经准备好的依赖缓存。
官方规则还要求将审计输出目录与 Agent 的 scratch 目录隔离，并由可信的父进程把允许的结果逐文件提升到 retained artifacts。这样做是为了防止目标代码通过符号链接、路径穿越或递归复制污染正式报告目录。
如果你的本地设备没有稳定的隔离环境、内存不足以同时运行多个子 Agent，或者企业策略不允许在开发机保存审计日志，远程云端 Mac 或独立开发环境会比直接改造个人电脑更容易控制。你可以先参考 Kvmzen 帮助中心 了解远程开发环境的准备事项，再决定是否把长任务迁移出去。
findings.json 到安全报告
机器可读结果
官方仓库提供 report-schema.json、validate-findings.cjs 和相应测试文件，用于检查 findings.json 是否符合预期结构。(官方报告 Schema) 验证脚本会在候选输出阶段和后续独立记录复核后再次运行。(官方验证脚本)
建议每条 finding 至少保留以下信息：
- 唯一标识和当前 verdict；
- 受影响文件、函数、行号或源代码范围；
- 低信任主体、输入或动作；
- 预期控制、跨越的边界和受影响资源；
- 证据链与验证命令；
- 可安全复现的输入和观察结果；
- 影响范围、修复建议和残余不确定性。
不要把“缺少最佳实践”直接写成漏洞。例如，第二层防御没有配置，但第一层已经可靠阻断攻击时，更准确的结论可能是加固建议，而不是 confirmed finding。官方设计原则明确要求严重性同时考虑可能性和影响，不能只因为偏离检查清单就提高等级。
从 JSON 生成 Markdown
机器结果进入团队审阅前，可以按下面的顺序转换：
- 读取
confirmed，为每条问题补齐标题、影响边界和源代码证据。 - 读取
needs_validation，保留未解决事实，不填入未经证实的严重性。 - 读取
rejected，只保留必要的驳回原因，避免它们再次进入待修复清单。 - 将验证命令、沙箱限制和脱敏输入放入复现步骤。
- 把修复建议写成最小有效改动，而不是泛泛要求“加强安全”。
- 在报告开头注明代码版本、工作区是否有未提交修改、审计范围和未覆盖区域。
一个适合团队审阅的 Markdown 结构可以是：
## AUD-001：导入文件路径未经过边界校验
- 状态：confirmed
- 影响边界：不可信上传输入 → 服务端临时目录
- 证据：src/import-handler.ts:42-88
- 观察结果：沙箱中的虚拟主体可写入未分配路径
- 复现条件：仅使用脱敏归档 fixture
- 修复建议：在归档展开前固定目标目录并拒绝越界路径
- 未覆盖事项：真实生产挂载策略需要部署侧复核
这类报告比单纯输出“高危漏洞”更适合进入 DevSecOps 流程，因为开发者能看到源代码位置、验证边界和下一步动作。官方仓库列出的目标文件包括 REPORT.md、FINDINGS-DETAIL.md 和 NEEDS-VALIDATION.md，正好对应汇总、证据详情和未完成验证三种阅读需求。(官方测试文件)
落地执行顺序
你可以按以下顺序完成首次试跑：
- 固定代码版本。 记录 Git 提交、工作区是否干净、审计范围和排除目录。
- 安装技能。 执行官方
npx skills add命令，确认SKILL.md与验证脚本存在。 - 准备运行时。 使用受支持的 Node.js LTS，并提前准备不含真实凭据的依赖和测试 fixture。
- 建立隔离环境。 关闭外部网络，限制环境变量、写入目录、进程、内存和执行时间。
- 先运行侦察。 让 Agent 输出架构、信任边界、输入面和 coverage ledger，不要一开始就执行构建或模糊测试。
- 执行覆盖驱动排查。 按 ledger 分配不同目录、边界和攻击类别，避免多个 Agent 重复扫描同一热门路径。
- 独立验证候选。 要求新验证者尝试推翻 finding；无法满足沙箱条件时保留
needs_validation。 - 验证结构化输出。 运行 findings 和 coverage ledger 的验证脚本，确认 JSON 可被后续流程读取。
- 人工审阅报告。 检查严重性、影响主体、复现证据、修复建议和未覆盖范围。
- 决定是否重复运行。 代码变化、权限变化或新增输入面后，应基于新的提交重新审计，而不是把旧报告当作永久结论。
如果你需要长时间保持 Agent 会话、保存日志并让多个成员审阅结果，可以进一步了解 Kvmzen 的云端 Mac 租用方案。但对于长期稳定重负载、需要物理接口或必须接入企业内部专用网络的审计任务，本地专用主机或企业隔离集群仍可能更合适。
常见问题
如何把 security-audit-skill 安装到 AI Coding Agent？
使用官方 Skills CLI 安装：
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
安装后还要确认 Agent 能加载技能、支持工具调用和并行子 Agent，并且 Node.js 验证脚本能够执行。安装命令成功只说明文件已下载，不代表当前代理已经进入完整审计模式。
security-audit-skill 能否用于 Claude Code 和 Codex？
官方仓库采用 agent-neutral 表述，要求平台提供等价的工具调用、任务委派、写入隔离和沙箱能力。Claude Code 的系统要求包括 Node.js、网络认证和终端环境；至于 security-audit-skill 是否能在你的具体配置中完整运行，仍应通过一次无敏感代码的试跑确认。(Claude Code 官方入门文档)
怎样让自动审计结果更少误报？
把发现和验证拆给不同 Agent，要求每个候选说明低信任主体、输入、控制、跨越的边界和具体结果。没有足够运行条件时，不要强行执行目标代码，也不要给 needs_validation 填入严重性；这比单纯增加扫描规则更能减少误报。
security-audit-skill 需要什么沙箱和权限？
需要操作系统级沙箱，禁用外部网络，使用清理后的 allowlist 环境，限制 CPU、内存、进程、文件和时间，并把写入限制在 scratch 目录。真实密钥、SSH 配置、宿主机 Home、共享服务和生产身份都不应暴露给目标代码。
confirmed 和 needs_validation 有什么区别？
confirmed 必须具备完整源代码证据和受控环境中的有限结果；needs_validation 则表示候选存在，但某个决定性事实仍未解决，例如部署权限、运行时配置或沙箱条件。前者可以进入正式报告，后者应进入待验证清单，不能直接当作已确认漏洞。
security-audit-skill 适合减少重复审计工作、整理覆盖范围和生成可追溯证据，但它不能替代人工复核，也不能自动证明生产环境一定存在漏洞。尤其当你的当前方案是在个人电脑上直接运行 Agent 时，常见缺点是宿主机权限边界不清、长任务容易中断、日志与代码混放，且多个验证 Agent 难以保持独立隔离。等你完成本地无敏感代码试跑，并确认需要稳定会话、独立目录和持续日志后，再考虑使用 Kvmzen 的远程云端 Mac 作为隔离开发环境，会比继续把高风险审计任务堆在日常开发机上更稳妥。
常见问题
security-audit-skill 如何安装到 AI Coding Agent？
先准备支持工具调用和并行子 Agent 的编码代理，再在终端执行官方 Skills CLI 命令安装。安装后必须从目标代码库根目录启动代理，明确要求执行完整安全审计，并确认代理能读取 skill 目录、调用 Node.js 验证脚本和写入独立输出目录。只看到安装成功，不代表当前代理已经加载技能。
security-audit-skill 是否支持 Claude Code 和 Codex？
官方仓库将它定义为 agent-neutral skill，并要求平台提供工具调用、并行子 Agent 和等价的任务委派能力。因此，Claude Code 或 Codex 能否完整运行，取决于各自的 skill 加载方式、工具权限和沙箱实现；不能仅凭仓库存在就承诺所有功能在每个平台上完全一致。
AI Coding Agent 自动安全审计怎样减少误报？
不要把静态规则命中直接写成漏洞。应先建立覆盖台账，再让独立验证者尝试推翻候选，确认真实信任边界、受影响资源和可观察结果；无法在受控环境中复现的项目，保留为 needs_validation，不给出未经证实的严重性评级。
security-audit-skill 运行需要什么沙箱和权限？
运行目标代码时，应使用操作系统级沙箱，禁用外部网络，仅允许显式环境变量，限制 CPU、内存、进程、磁盘和执行时间，并把写入范围限制在指定 scratch 目录。目标代码不应接触宿主机凭据、共享服务、其他 Agent 的目录或长期保存的报告目录。
安全审计报告中的 confirmed 和 needs_validation 有什么区别？
confirmed 表示已经具备完整源代码证据和受控环境下的有限结果，足以进入正式报告；needs_validation 表示仍存在明确但未解决的事实，例如部署配置、运行时权限或沙箱能力不足。后者不能直接标记严重性，也不应被当成已确认漏洞对外发布。