1. 引入cloudflare开源了一套security-audit-skill详见参考1。看了一下发现能检测的漏洞类型还挺多思路也比较全面所以对他做一个全面的分析并记录在此。2. 用法根据参考3可知 Claude Code, Cursor, Codex 下都能使用security-audit-skill。比如Claude Code下使用时将其从参考1下载后放到.claude/skills文件夹下即可。$ ll .claude/skills/ total12drwxrwxr-x3root root4096Sep1920:16 ./ drwxrwxr-x3root root4096Sep1920:15../ drwxrwxr-x2root root4096Sep1503:28 security-audit/3. 漏洞检测原理它能把Agent变成一支安全审计团队通过侦察、猎杀、验证、复核、报告六个阶段对代码仓库做白盒源码审计。根据参考1它的六阶段工作流如下1. 侦察阶段——在architecture.md和coverage-ledger.json中梳理架构、信任边界、输入面、已有证据以及确定性覆盖范围。2. 基于覆盖的探查——从台账单元中分配独立探查人员记录其检查结果并通过覆盖评审器寻找遗漏点。3. 候选项验证将每一个唯一候选结果交给全新核验者由其尝试证伪该候选项。4. 结构化输出把已确认、待验证、已驳回的记录写入findings.json并对照report-schema.json完成校验。5. 独立记录核验全新智能代理对最终的原始断言进行复核涉及素材替换的内容额外安排另一组独立核验者复核。6. 与目标无关的报告生成——基于核验后的记录与覆盖台账生成REPORT.md、FINDINGS-DETAIL.md和NEEDS-VALIDATION.md。4. 能检测哪些漏洞skill仓库的每一个md文件中都描述了不同类型漏洞的检测能力大致包括如下类别的漏洞都能检测检测的类型还是挺全面的4.1. 注入类漏洞覆盖范围SQL 注入、命令注入、HTML/XSS、模板注入、路径穿越、反序列化、日志注入、LDAP/XPath 注入。检测原理污点路径追踪。从不可信输入的入口点开始逐行跟随数据流经解析、校验、转换直到最终的危险汇聚点查询构造器、命令执行器、模板引擎。它的独到之处是不满足于直接路径——重点找间接注入数据被安全地存储后被另一段代码取出用于危险上下文通过字段名、键名、Header、元数据而非值进行的注入以及注入到日志、缓存、搜索索引等二级系统。4.2. 访问控制缺陷覆盖范围越权访问水平/垂直、权限绕过、批量操作漏检。检测原理不只是检查“权限校验代码存不存在”而是验证“对的资源、对的权限、对的机制”。典型猎杀手法包括寻找绕过严格权限的另一条弱校验路径检查请求体中的字段能否覆盖权限系统本想限制的值找出只做了认证、忘了授权的端点对比同一资源的多条访问路径校验是否一致追查批量、导出、导入操作是否逐项执行了权限检查。4.3. 内存安全与内核漏洞覆盖范围越界读写、整数溢出、类型混淆、释放后使用UAF、双重释放、数据竞争、TOCTOU、FFI 边界错误、二进制加载劫持、内核驱动漏洞。适用于 C/C、Rust unsafe 代码、内核模块、固件、解析器、JIT。检测原理边界与生命周期的重新推导。对每个攻击者可控输入重新计算所有缓冲区余量考虑前缀、对齐、填充、终止符、检查每个算术运算的表示宽度、追踪每条错误与取消路径上对象的所有权。验证手段是沙箱内的最小化本地复现用 sanitizer 编译的测试 harness、现有 fuzz 目标、确定性并发调度来触发缺陷并在触发后立即停止不深入利用。一类特别扎实的检查是内核的“用户拷贝双读”模式——系统调用从用户内存读取一个值作为信任依据后再次读取同一地址而用户可在两次读取之间篡改它。4.4. Web 协议与认证漏洞覆盖范围HTTP 请求走私、缓存投毒、会话固定、OAuth/OIDC 流程绕过、MFA/Passkey 缺陷、账号恢复劫持、API Key 与 mTLS 误配。检测原理协议状态机比对。把认证流程当作状态机检查能否跳步、回退、重放已完成的流程、在部分失败时回滚是否完整。对 OAuth 类联合身份重点检查 state 绑定、重定向 URI 匹配、令牌交换中每一方的身份校验。请求走私则源于前端代理与后端服务器对请求边界的解析分歧——通过阅读两端的解析逻辑对比其差异。4.5. AI 与 LLM 漏洞覆盖范围提示注入、上下文/检索/记忆投毒、代理工具调用滥用、MCP 服务器信任链缺陷、模型输出处理不当导致的信息泄露。检测原理把 LLM 的上下文窗口当作新的攻击面。追踪不可信文档内容如何进入上下文、检索管道能否被投毒改变记忆、工具调用的参数绑定能否被注入内容操纵、MCP 客户端如何验证服务器声明的身份。这是 OWASP 清单之外的全新领域也是这套 skill 领先于传统扫描器的地方。4.6. 供应链与发布漏洞覆盖范围依赖混淆与投毒、构建输入篡改、CI/CD 劫持如 GitHub Actions 工作流注入、发布签名缺失、更新机制劫持、插件扩展滥用。检测原理沿“代码从哪来、如何被构建、如何到达用户”的链条逐环审计。检查依赖解析规则是否可被劫持、CI 中不可信输入如 PR 标题能否流入可执行上下文、签名校验的对象与实际映射的对象是否同一份产物。4.7. 云与部署漏洞覆盖范围IAM 过度授权、IaC 错误配置、容器逃逸、Kubernetes 配置缺陷、Serverless 边界、密钥生命周期。检测原理把基础设施代码当作源码审计——本地渲染 Terraform/Kubernetes 清单为策略对象用虚构身份评估其实际权限检查身份提供者到工作负载的信任链是否有多余授权。4.8. 其余专项领域RPC 与消息协议序列化边界、Broker 隔离、消息重放与乱序。原理是帧解析一致性比对。资源耗尽算法复杂度放大小输入触发大计算、资源累积泄漏、配额绕过。原理是核算“一单位攻击者输入消耗多少共享资源”。数据隔离跨租户读写、导出/备份/恢复中的隔离失效、删除不彻底软删除数据仍可搜索到。原理是按租户对象图逐条追踪。客户端与浏览器DOM XSS、原型链污染、postMessage 信任、点击劫持。原理是按 frame 来源逐次校验。桌面/移动/本地 IPCUnix socket/Binder/D-Bus 对等认证、特权助手的混淆代理、Deep Link 劫持。原理是 OS 级凭证与通道身份的绑定验证。5. 如何提高检测结果可信度找到漏洞只是第一步这套体系真正的护城河在验证流程。覆盖台账驱动猎杀侦察阶段生成确定性的覆盖台账把攻击面拆成“攻击面 × 边界 × 攻击类”的最小单元每个单元必须被明确分配——没有被预算覆盖的单元要显式标记为 deferred绝不允许静默遗漏。每轮猎杀后还有一个独立的“覆盖批评家”代理专门找遗漏。猎手与验证者分离找到漏洞的代理永远不负责确认它。每个候选发现交给一个全新的验证代理其指令只有一句话“你没有提出这个发现请尽力反驳它。”验证者必须重新阅读每一处引用的源码位置、独立复现关键本地检查才能维持确认。三种判决泾渭分明confirmed 拥有完整源码路径和有界本地复现证据才能授予严重级别needs_validation 是被某个仓库外事实如部署配置阻塞的线索必须写明缺失的具体事实和安全的验证方案永不授予严重级别rejected 记录被推翻的候选防止未来的运行重复这个错误主张。所有发现写入 findings.json 后还要通过零依赖的 JSON schema 校验器再由新一轮独立代理逐条复核重大替换需要再找一个全新的验证者仲裁。一切执行都在沙箱内目标代码只在 OS 强制隔离的沙箱中运行无外部网络、空环境变量、只读目标、写权限仅限临时目录、严格的 CPU/内存/时间限制。用虚构的账号、租户和密钥绝不触碰真实端点、生产身份或共享基础设施。复现记录只保存允许列表内的变量名防止凭据意外入档。6. 边界与局限它是白盒源码审计工具拿到的是代码而非二进制。凡是仓库里看不到的部署事实——代理行为、运行时配置、浏览器策略——它不臆断存在或缺失只记录为待验证线索。它不做硬件探针、故障注入、侧信道这类物理层分析拿到固件二进制时它无能为力但拿到固件源码就能直接开工。它承认单次运行的不完整性官方测试数据显示单次运行大约能找到重复运行才能发现的全部漏洞的一半参考1的readme中Multiple runs improve coverage部分提及。所以它支持多轮累积——后续运行会读取此前的台账和发现定向补盲、复核已变更的代码、沿用仍然有效的证据。参考https://github.com/cloudflare/security-audit-skillhttps://blog.cloudflare.com/build-your-own-vulnerability-harness/https://www.skills.sh/reason-machines/security-skills/cloudflare-security-audit-skill