前阵子在给项目做代码审计的时候我突然意识到一个问题现在AI编程助手已经能帮我们写大部分业务代码了但在代码安全这块它们的能力其实相当不均衡——很多模型默认生成的代码SQL拼接、反序列化、越权接口一抓一个准。而安全审计这个工作又恰恰是知识密度极高、检查项相对固定、适合标准化的场景。于是我花了几天时间照着现在主流AI编程助手比如Codex、Claude这一类的Skill机制把整套安全审计流程打磨成了一个可复用的Skill效果比我手动写提示词稳定得多。这篇文章我就把这个security-audit-skill的构建思路、目录结构、核心检查清单、输出模板和实测效果完整拆开来讲。如果你正在用AI写代码审代码或者想在团队里把人工Code Review的很多重复工作交给AI去做这篇文章应该能让你少踩几个坑。1. 为什么要做安全审计专用SkillAI编程助手时代的代码安全困局先说一个背景现在很多团队已经默认让AI写代码了但AI生成代码的安全问题并不是偶发的而是系统性的。我见过不少AI生成的登录模块直接把用户输入拼进SQL也见过前端把内部接口的鉴权逻辑去掉以为隐藏起来就安全。这种问题在人工Review的时候容易被经验丰富的工程师拦下来但问题是——大部分团队的Code Review并不会有专职的安全工程师参与。让AI自己去审自己写的代码又往往会出现自己检查自己作业的盲区所以把安全审计从日常Review里独立出来做成一个专门让AI执行的Skill是我认为在这个阶段最靠谱的解法。Skill这个概念最近在AI编程工具圈子里特别火它的本质其实没有那么玄乎——就是你把一套完整的专业知识、操作步骤和输出规范打包成一个AI能直接读取的结构化指令包。和普通提示词最大的区别在于Skill不是一段临时粘贴的prompt而是一个有目录、有引用文件、有可复用的检查清单的最小知识系统。当你需要AI执行某项专业任务时只需要触发这个Skill它就会按照你预设的流程去思考而不是依赖模型临场发挥。为什么安全审计特别适合做成Skill因为安全审计有几个天然特点第一安全检查项是有行业标准的OWASP Top 10之类的规范大家基本都有共识第二安全检查的流程是固定可重复的先看输入校验、再看鉴权、再查依赖漏洞这个顺序本身就可以标准化第三审计结果的输出形式也是固定的无非是风险等级、问题位置、修复建议这一套。这三个特点叠加在一起恰好就是Skill最擅长的场景。你想想如果每次都要靠人肉回忆该查哪些点很容易漏但如果你把这些检查点全部沉淀成一个Skill让AI每次按清单走一遍漏检的概率就会小很多。我设计这个Skill的另一个动机是想解决AI审计结果不稳定的问题。以前直接对AI说帮我检查一下这个项目的安全漏洞不同模型、不同上下文长度甚至同一句话换个说法结果都会差很多。而真正的Skill应该像一个线下老师傅带徒弟一样不仅告诉徒弟要查什么还告诉徒弟怎么查、按什么顺序查、查完怎么出报告。只要把怎么查的流程拆得足够细AI的输出质量就能被拉到一个比较稳的下限这是我实践下来最重要的心得。2. Skill机制解构Agent Skill与普通提示词的本质区别在动手写security-audit-skill之前我先把Skill的机制彻底梳理了一遍。简单来说一个标准的Agent Skill由两部分组成一个是入口文件通常是SKILL.md负责说明这个技能是什么、在什么情况下触发、按什么流程工作另一个是挂在入口下面的资源文件包括详细检查清单、代码示例、模板、甚至可执行的脚本。AI在运行时会先读取SKILL.md根据里面的指引去加载对应的资源然后按步骤执行。这个设计其实很像程序里的入口函数工具库入口负责调度工具库负责干活。理解了这个机制之后你就能明白Skill和普通提示词的差距在哪。普通提示词是一次性的你写多长、AI能记住多少、上下文窗口够不够全看运气而且你很难在里面塞进大量参考知识因为太长的prompt本身就会挤占其他任务的上下文空间。Skill则是复用型的它平时只加载SKILL.md这个轻量入口等到真正执行审计任务时才按需把检查清单、漏洞特征表这些资源加载进来这样既不会浪费日常对话的上下文又能保证专业任务执行的深度。另一个关键差别是确定性。普通提示词里你写请检查常见漏洞AI可能就会按它训练数据里的印象来发挥但Skill里你可以写依次执行第1步到第5步每一步都要输出对应结果第3步必须调用references/checklist.md中的清单逐项核对这种强制流程能让AI的思维路径稳定下来。我在实测中发现同一个安全审计任务用普通提示词执行10次能给出合格报告的不到一半但触发Skill后执行10次每次都能稳定地输出覆盖主要检查项的报告这就是流程约束的价值。不过这里也要泼一盆冷水Skill并不是万能的它本质上还是在约束和引导AI的推理而不是让AI真的变成安全专家。所以设计Skill的时候不要指望它能把所有0day都挖出来更合理的定位是常见漏洞的第一道筛查器——把重复性高的、有规律可循的已知问题交给Skill让人工专注于那些需要业务上下文判断的复杂逻辑漏洞。想要让AI做到这一点你必须在Skill里明确写出它的边界否则AI会自作主张地告诉你这个项目很安全那才是真正危险的事。3. 实战构建security-audit-skill的完整流程说实话我在GitHub上翻过不少开源的安全审计Skill项目各有千秋但很多都存在同一个问题要么检查清单过于笼统要么输出格式不适合直接落到工程流程里。所以这次我干脆自己动手按照目录结构—核心工作流—检查清单—分语言规则—输出模板这条线把整个Skill从零搭了一遍。3.1 Skill的目录结构设计先看最终我落地的目录结构security-audit-skill/ ├── SKILL.md # 技能入口文件描述触发条件与核心流程 ├── assets/ │ ├── owasp_top10.yaml # OWASP Top 102021版检查项配置 │ ├── supply_chain.yaml # 供应链安全专项检查项 │ └── ai_code_risks.yaml # AI生成代码常见缺陷模式 ├── checklists/ │ ├── python.md # Python专项检查清单 │ ├── javascript.md # JavaScript/TypeScript专项检查清单 │ ├── go.md # Go专项检查清单 │ ├── java.md # Java专项检查清单 │ └── web_api.md # 通用Web/API安全审计清单 ├── templates/ │ ├── audit_report.md # 审计报告模板 │ └── issue_card.md # 单条问题卡片模板 └── scripts/ ├── scan_dependencies.py # 依赖漏洞快速扫描脚本 └── sast_quick.py # 轻量静态规则匹配脚本这个结构不是随便拍的每一层都有它的用途。SKILL.md负责让AI快速理解这是一个安全审计技能触发条件是用户要求做安全审查同时告诉它先全局了解项目结构再按清单逐项审计最后输出报告这条主链路。checklists/目录是核心资产按语言和场景拆分这样AI在审计Python项目的时候只需要加载Python的清单而不必背上Java的规则能显著省上下文。templates/则保证了每次输出的报告格式一致方便团队直接做归档和跟踪。scripts/里我放了一些辅助脚本不过这部分是可选的后面我会单独说脚本的边界。3.2 SKILL.md主文件核心工作流与角色定义SKILL.md是整个技能的大脑。我在写它的时候最注意的一点是不能只写你是一个安全审计专家这种空话必须写清楚具体的执行步骤和每一步要交付什么。以下是我精简后的主文件核心逻辑# Security Audit Skill ## 技能定义 你是网络安全审计专家擅长对代码进行白盒安全审计。你的任务是发现代码中的安全漏洞、设计缺陷和风险隐患并输出结构化审计报告。 ## 触发条件 - 用户要求对代码/项目进行安全审计、漏洞扫描、Code Review安全专项等。 - 用户上传了待审计文件或指出待审计代码位置。 ## 执行流程 1. 理解项目目标先浏览项目整体结构确定技术栈、关键入口、数据流。 2. 加载检查清单根据项目语言加载 checklists/ 下的对应文件若为Web/API项目额外加载 web_api.md。 3. 逐项审计按检查清单逐项遍历代码记录每一个可疑点。 4. 验证与优先级排序对可疑点进行交叉验证排除误报按风险等级排序。 5. 输出报告按 templates/audit_report.md 生成审计报告单条问题按 templates/issue_card.md 输出。 ## 核心原则 - 不输出模糊结论每个问题必须给出文件路径、行号、问题描述、风险等级和修复建议。 - 不确定是否可利用时标注需人工确认不得简单定性为安全。 - 无法确认的部分必须明确说明不得编造审计结论。这套流程看起来简单但有个很关键的细节我给了AI一个**先理解再审计的步骤**。如果不加这一步AI经常会在还没搞清项目是干什么的、数据从哪里进来、哪里是信任边界的情况下就凭局部代码片段乱报漏洞。实测下来加了这一步之后误报率能下降三四成。另外我特别写了核心原则这块很多人会忽略它。你可能觉得AI别乱说这种话写不写无所谓但实际上AI在没有明确约束时真的会为了显得专业而编造一些不存在的漏洞或者反过来把所有问题都轻描淡写。把边界写进原则里不是为了提升AI能力而是为了控制它的输出下限这是我这几次打磨里觉得最值的一笔。3.3 核心检查清单覆盖OWASP Top 10与供应链风险检查清单是Skill的内功也是决定审计质量的核心。我把检查项分成了三大类通用Web/API风险、供应链风险、AI生成代码特有风险。下面是我在checklists/web_api.md里沉淀的一部分内容基本对标OWASP Top 102021版做了工程化改写检查项风险等级审计要点典型缺陷示例注入类漏洞SQL/LDAP/命令Critical查找字符串拼接SQL、动态命令执行、eval/exec类函数SELECT * FROM users WHERE name userInput 失效访问控制High检查接口是否校验身份、资源ID是否可越权访问未校验登录态的对象查询接口加密失败与敏感数据泄露High查找硬编码密钥、明文传输凭据、弱Hash算法password 123456硬编码在代码里不安全设计Medium缺少速率限制、缺少输入白名单校验登录接口无失败次数限制安全配置错误Medium默认密码、调试模式开启、错误信息泄露堆栈DEBUG True上线未关已知漏洞与过期依赖High检查依赖库是否过期、是否有CVE记录低版本Log4Shell身份识别与会话管理缺陷HighCookie/Session/Token的生成与有效期是否安全Session固定攻击、Token硬编码在URL软件和数据完整性失败High反序列化是否可信、更新链路是否校验签名pickle.loads(userInput)日志与监控不足Medium关键安全事件是否记录日志登录失败无日志、越权操作无审计SSRFHigh服务端是否请求了用户可控的URL图片代理接口直接请求用户传入的地址这张表之所以值得放在Skill里而不是靠AI自己知道是因为AI对OWASP的记忆往往是概念性的不是条目化的。你让它检查OWASP Top10它可能会漏掉其中两三个因为它在逐行看代码的时候注意力分配不均。但你把表格喂给它让它按表逐项核对它的执行完整性会高很多。这就是把隐性知识显性化带来的收益。供应链风险这一块我在supply_chain.yaml里专门做了配置核心检查点包括锁定依赖版本而不是用模糊版本范围、检查锁文件是否提交、对npm install/pip install执行源的可信度评估、识别被恶意投毒的高危包。前阵子开源社区就出现过多起依赖包投毒事件这已经不是理论风险了而是每天都在发生的真实威胁。很多开发者只看功能不看来源觉得能装上就是好的这个习惯必须靠自动化审计去打破。至于ai_code_risks.yaml这是我自己加的私货专门针对AI生成代码的通病AI特别喜欢把校验逻辑放在前端、把管理员接口和普通接口写在同一套代码里不加角色区分、注释里写这里待补充鉴权然后真的就没做。这部分检查项不是行业标准但在AI编程普及的今天你会发现它甚至比某些传统检查项更实用。3.4 分语言检查规则设计不同语言的漏洞模式差异很大所以我专门为几种主流语言做了独立的检查清单。拿checklists/python.md举例我重点标记了这些坑eval/exec的动态执行、f-string的SQL拼接、pickle.loads处理不可信数据、subprocess拼接命令、Django/Flask的ORM使用不当导致注入、Debug模式上线、SECRET_KEY泄露。每一条我都会在清单里写一个负面示例和一个修复后的正面示例因为AI对规则描述的理解远不如对正反例对比的理解来得精准。前端JavaScript/TypeScript的检查重点就完全不一样了innerHTML直接注入不可信内容、eval动态执行、localStorage存放敏感Token、前端硬编码加密密钥、第三方SDK的权限滥用、npm install时的脚本执行风险。Node.js后端还要额外注意原型链污染、child_process.exec命令注入、不安全的redirect目标校验。Go和Java我也各写了清单但说句实话它们在安全检查上的模式比Python和JS要少一些严重问题因为语言本身对类型和内存安全做了不少限制。Go主要看os/exec命令注入、解序列化特别是encoding/gob、DSL表达式注入Java则重点看反射滥用、JNDI注入、反序列化链、Spring框架的SpEL表达式注入。这个按语言裁剪检查粒度的思路能让AI在审计特定项目时更快命中要害而不是拿一套通用规则去硬套。为了避免检查清单本身变成看着很美但AI懒得逐条照做的死文档我给每条清单都加了可验证的动作描述。比如不写检查是否有SQL注入风险而是写搜索代码中所有与数据库交互的位置检查是否存在字符串拼接SQL的模式若存在则尝试找出可控输入源并验证其是否经过过滤。动作描述越具体AI的执行就越像流程而非想象这一点强烈建议大家在自己写Skill时试验一下。3.5 风险定级与输出模板设计审计报告的输出质量决定了这个Skill能不能真正落到工程流程里。我设计的templates/audit_report.md包含五块项目概览审计对象、技术栈、范围、审计方法加载了哪些清单、执行了哪些步骤、风险统计Critical/High/Medium/Low数量、问题明细逐条列出、整改建议按优先级排序的修复路线。单条问题则用templates/issue_card.md来规范化## 问题 #1 - **风险等级:** High - **文件路径:** src/api/user.py - **行号:** 42-48 - **问题类型:** SQL注入 - **问题描述:** 用户输入的 username 参数未经参数化查询处理直接拼接进 SQL 语句攻击者可通过构造特殊输入实现注入。 - **修复建议:** 改用数据库驱动提供的参数化查询或ORM的绑定参数机制禁止使用字符串拼接方式构造SQL。 - **修复示例:** python # 修复前 cursor.execute(fSELECT * FROM users WHERE name {username}) # 修复后 cursor.execute(SELECT * FROM users WHERE name %s, (username,))是否需人工确认:否是否需人工确认这个字段是我踩坑踩出来的。AI判断漏洞时经常会有两种极端一种是漏报把真问题说成没问题另一种是过度报告把无害代码当成严重漏洞。加了这个字段之后AI反而会更诚实因为它不需要为了显得严谨而把所有问题都定成Critical它可以光明正大地写这条需要人工确认把人和AI的能力做了合理分工。我实测下来**加了需人工确认选项后AI把低风险问题误报成高风险的次数明显减少了**。 ## 4. 让Skill真正生效触发方式、审计工作流与CI集成思路 一个Skill写得好不好最终要看它能不能顺畅地在实际工作中被用起来。很多人把Skill往目录一丢然后对着AI喊帮我审计结果AI根本没加载这个技能出来的报告和普通问答没什么区别。问题多半出在触发链路没设计好。 ### 4.1 Skill的加载与触发策略 目前主流的Agent Skill机制触发方式大概有三种自动加载、关键词触发、用户手动指定。**自动加载**适合那些你希望Agent在每个项目里都默认具备的能力但我建议不要把安全审计设成自动加载因为它有明确的专业边界平时挂在上下文里会挤压其他任务空间**关键词触发**是通过在对话中提到安全审计Code Review安全专项检查漏洞等词来唤起Skill这个策略适合绝大多数场景**手动指定**则适合你把审计作为独立任务来跑的时候直接对AI说使用security-audit-skill对当前项目做一次全面安全审计。 如果你用的是Codex这类可以在对话里直接点选/引用技能工具的产品那就更简单了——直接把security-audit-skill目录挂进去然后下达审计指令。这里有一个细节值得注意**审计时最好给AI一个明确的审计范围**。你是想看整个仓库还是只看某个模块是全语言通用审计还是只看Python后端范围越明确AI的执行效率越高误报也越少。如果什么都不说AI经常会先全项目扫一遍不仅慢而且会把一些无关文件里的无害代码也当成问题报出来。 ### 4.2 把Skill嵌入Code Review主流程 我在团队里推广这个Skill的时候没有一上来就让大家用AI做全量审计而是把它先嵌到Code Review的流程里**每次Pull Request合并之前AI先自动跑一遍Sast-Lite级别的安全审计只在PR描述里贴出新增或变更代码段的安全风险人工Reviewer重点看这些被标记的问题以及那些需要业务上下文判断的改动**。这个流程的微妙之处在于它不是让AI取代Reviewer而是让AI帮Reviewer把怎么都该拦下来的问题先拦下来让人的精力集中在更高层次的架构和逻辑判断上。 实际操作中我会在Skill里额外加一个--diff模式的指令只针对git diff出来的增量代码做审计。这个模式对AI来说其实更容易因为增量越少上下文越干净AI能抓住的细节就越多。相比之下全量审计对长上下文的要求很高AI跑到后面容易遗忘早期看到的代码导致前后结论不一致。所以我的建议是**日常Review用diff模式发版前或大型重构后再跑全量审计**分工明确才能在效率和质量之间找到平衡点。 ### 4.3 与CI/CD流水线的集成思路 很多人问这个Skill能不能在CI/CD里跑起来答案是可以但要想清楚跑的是什么。如果你用的是Codex CLI、Claude Code这类支持命令行调用的Agent工具完全可以把security-audit-skill配置成一个CI步骤在push或merge时自动执行把报告输出成Markdown或JSON文件再由机器人把风险摘要贴到合并请求上。脚本部分我在scripts/里放了一个轻量级的依赖漏洞扫描器核心逻辑就是读取项目的依赖清单然后到已知漏洞库里做比对这部分逻辑简单、确定性高很适合交给脚本而不是大模型去执行。 但我必须提醒一件事**大模型在CI里自动化执行审计最大的风险不是性能而是幻觉式安全**。AI可能在某个很罕见的角度上把一段写得不错的代码误判为有漏洞也可能放过一个有问题的代码。所以对于CI阶段我强烈建议只让Skill输出风险线索Lead级别的结果并且标记为需人工复核而不是直接输出通过/不通过的阻断结论。**让AI做筛查让规则和人工做定案**这条原则我认为是落地这类Agent Skill时最重要、也最容易被忽视的一条。 ## 5. 实测效果与常见问题排查实录 文件写完了信心满满的但真拿项目去实测的时候还是踩了一堆坑。这一节我把自己调试security-audit-skill时遇到的典型问题、定位思路和解决办法整理出来应该能帮你少走不少弯路。 ### 5.1 实测场景与效果数据 我拿了一个内部的中型Python后端项目做了全量审计代码量大概6万行依赖一百多个。接入Skill之前我让AI直接检查安全漏洞结果它只输出了一些泛泛而谈的建议比如注意使用强密码哈希不要硬编码密钥几乎没有定位到具体的文件和行号。接入Skill之后同样一个项目AI不仅定位到了12个具体风险点还按模板输出了带修复示例的报告。虽然经过人工复核12个里有3个是误报或低风险但剩下的9个里有两个确实是被之前的Code Review漏掉的真实问题——一个是不安全的反序列化入口一个是SSRF风险。**从说了等于没说到能挖出被人工漏掉的问题这就是结构化Skill和裸提示词的差距**。 不过我也得说实话这套Skill目前对**业务逻辑漏洞**的覆盖能力还是比较弱的比如优惠券可以重复使用转错账之后没有冲正流程这类需要深度业务理解的问题AI基本发现不了。这倒不是Skill写得不细而是大模型本身的推理局限它很难像资深工程师那样对着需求文档去反向推导这个逻辑在异常分支下会发生什么。所以如果你期望这个Skill能替代安全工程师那现阶段还是别抱这个指望但如果你只是想有个**不知疲倦的实习生**帮你把已知漏洞模式过一遍那它完全能胜任。 ### 5.2 高频问题速查表 | 问题现象 | 可能原因 | 排查与解决思路 | |---|---|---| | AI没触发Skill输出和普通问答一样 | SKILL.md里的触发条件太模糊 | 检查触发关键词是否与日常提问方式匹配必要时在SKILL.md里增加更宽泛的触发短语或在命令中显式要求使用security-audit-skill | | 报告里全是建议使用参数化查询这类空话 | 缺少动作性描述AI在泛泛而谈 | 把清单里的每一条改成在指定目录中搜索某类模式这种动作性描述 | | 误报率特别高 | 检查清单过严或AI没理解项目上下文 | 先让AI在第1步理解项目时输出项目技术栈与信任边界判断再进入逐项审计添加需人工确认选项 | | 审计长项目时后半段结论失真 | 长上下文导致AI遗忘早期信息 | 改用diff模式做增量审计或手动指定关键目录让AI在阶段性检查后输出中间结论再继续后续步骤 | | 依赖扫描脚本跑得很慢 | 把大模型用作确定性任务执行器 | 把依赖比对这类确定逻辑从AI里拆出来交给scripts/scan_dependencies.py这类脚本完成AI只负责解读结果 | | 不同语言项目共用一份清单检查项错位 | 没有按技术栈切换清单 | 在SKILL.md流程里明确根据语言加载对应checklists目录文件缺失语言时默认加载web_api.md | | AI在报告里把低危问题标成Critical | 缺少风险定级校准规则 | 在SKILL.md里补充定级标准高危必须满足外部可控输入无有效防御可达否则降级并标注需人工确认 | ### 5.3 避坑经验与优化建议 整个调试过程中最让我花时间的其实是**怎么防止AI把报告写成八股文**。第一个版本我过度强调输出格式的完备性结果AI为了凑字段把每个文件里所有带引号的字符串都说成疑似硬编码密钥报告又厚又没价值。后来我加了一条原则——**无法判断的问题宁可少报但必须在疑点清单里给出提示**并且要求每个问题必须同时满足找到问题特征和找到触发路径才算成立误报率才真正降了下来。 还有就是**Skill的迭代方式**不要想着一次写完美。我现在的做法是每次实际使用后就把那些AI频繁误报的检查项单独拎出来降权或者加更具体的排除条件把那些AI漏掉的真实漏洞模式提权并补充正反例。也就是说**这个Skill就是一个越用越准的知识库**它的价值会在持续迭代中慢慢积累而不是写出来就固定不变了。 另外如果你打算在团队里共享这个Skill我建议在SKILL.md里加一个独立的团队规范小节把你们团队的严重程度定义、哪些漏洞必须阻断发布、哪些可以遗留为技术债全部写进去。这样一来AI在出具报告时就不会只按通用行业标准来而是会结合你们团队的实际情况给出更有落地意义的建议。这个看起来很小的设计在组织内部落地时的价值甚至比技术本身还要大。 最后再分享一个我后来加进去的小功能在审计完一个项目后Skill会自动追加一个复盘清单环节让AI基于本次审计中发现的薄弱环节建议一个接下来最值得做的三项加固动作。这个设计其实是在实践中发现很多开发者在收到一堆漏洞报告后根本不知道先修什么、后修什么容易直接麻了。有了这个优先级建议报告就不是单纯的问题列表而是一个可执行的行动指引。建议你也在自己的Skill里加上类似的收尾设计它能让整个审计结果真正推动代码质量的改进而不只是停在报了一堆问题这一步。 构建安全审计Skill：AI编程助手时代的代码安全自动化实践
前阵子在给项目做代码审计的时候我突然意识到一个问题现在AI编程助手已经能帮我们写大部分业务代码了但在代码安全这块它们的能力其实相当不均衡——很多模型默认生成的代码SQL拼接、反序列化、越权接口一抓一个准。而安全审计这个工作又恰恰是知识密度极高、检查项相对固定、适合标准化的场景。于是我花了几天时间照着现在主流AI编程助手比如Codex、Claude这一类的Skill机制把整套安全审计流程打磨成了一个可复用的Skill效果比我手动写提示词稳定得多。这篇文章我就把这个security-audit-skill的构建思路、目录结构、核心检查清单、输出模板和实测效果完整拆开来讲。如果你正在用AI写代码审代码或者想在团队里把人工Code Review的很多重复工作交给AI去做这篇文章应该能让你少踩几个坑。1. 为什么要做安全审计专用SkillAI编程助手时代的代码安全困局先说一个背景现在很多团队已经默认让AI写代码了但AI生成代码的安全问题并不是偶发的而是系统性的。我见过不少AI生成的登录模块直接把用户输入拼进SQL也见过前端把内部接口的鉴权逻辑去掉以为隐藏起来就安全。这种问题在人工Review的时候容易被经验丰富的工程师拦下来但问题是——大部分团队的Code Review并不会有专职的安全工程师参与。让AI自己去审自己写的代码又往往会出现自己检查自己作业的盲区所以把安全审计从日常Review里独立出来做成一个专门让AI执行的Skill是我认为在这个阶段最靠谱的解法。Skill这个概念最近在AI编程工具圈子里特别火它的本质其实没有那么玄乎——就是你把一套完整的专业知识、操作步骤和输出规范打包成一个AI能直接读取的结构化指令包。和普通提示词最大的区别在于Skill不是一段临时粘贴的prompt而是一个有目录、有引用文件、有可复用的检查清单的最小知识系统。当你需要AI执行某项专业任务时只需要触发这个Skill它就会按照你预设的流程去思考而不是依赖模型临场发挥。为什么安全审计特别适合做成Skill因为安全审计有几个天然特点第一安全检查项是有行业标准的OWASP Top 10之类的规范大家基本都有共识第二安全检查的流程是固定可重复的先看输入校验、再看鉴权、再查依赖漏洞这个顺序本身就可以标准化第三审计结果的输出形式也是固定的无非是风险等级、问题位置、修复建议这一套。这三个特点叠加在一起恰好就是Skill最擅长的场景。你想想如果每次都要靠人肉回忆该查哪些点很容易漏但如果你把这些检查点全部沉淀成一个Skill让AI每次按清单走一遍漏检的概率就会小很多。我设计这个Skill的另一个动机是想解决AI审计结果不稳定的问题。以前直接对AI说帮我检查一下这个项目的安全漏洞不同模型、不同上下文长度甚至同一句话换个说法结果都会差很多。而真正的Skill应该像一个线下老师傅带徒弟一样不仅告诉徒弟要查什么还告诉徒弟怎么查、按什么顺序查、查完怎么出报告。只要把怎么查的流程拆得足够细AI的输出质量就能被拉到一个比较稳的下限这是我实践下来最重要的心得。2. Skill机制解构Agent Skill与普通提示词的本质区别在动手写security-audit-skill之前我先把Skill的机制彻底梳理了一遍。简单来说一个标准的Agent Skill由两部分组成一个是入口文件通常是SKILL.md负责说明这个技能是什么、在什么情况下触发、按什么流程工作另一个是挂在入口下面的资源文件包括详细检查清单、代码示例、模板、甚至可执行的脚本。AI在运行时会先读取SKILL.md根据里面的指引去加载对应的资源然后按步骤执行。这个设计其实很像程序里的入口函数工具库入口负责调度工具库负责干活。理解了这个机制之后你就能明白Skill和普通提示词的差距在哪。普通提示词是一次性的你写多长、AI能记住多少、上下文窗口够不够全看运气而且你很难在里面塞进大量参考知识因为太长的prompt本身就会挤占其他任务的上下文空间。Skill则是复用型的它平时只加载SKILL.md这个轻量入口等到真正执行审计任务时才按需把检查清单、漏洞特征表这些资源加载进来这样既不会浪费日常对话的上下文又能保证专业任务执行的深度。另一个关键差别是确定性。普通提示词里你写请检查常见漏洞AI可能就会按它训练数据里的印象来发挥但Skill里你可以写依次执行第1步到第5步每一步都要输出对应结果第3步必须调用references/checklist.md中的清单逐项核对这种强制流程能让AI的思维路径稳定下来。我在实测中发现同一个安全审计任务用普通提示词执行10次能给出合格报告的不到一半但触发Skill后执行10次每次都能稳定地输出覆盖主要检查项的报告这就是流程约束的价值。不过这里也要泼一盆冷水Skill并不是万能的它本质上还是在约束和引导AI的推理而不是让AI真的变成安全专家。所以设计Skill的时候不要指望它能把所有0day都挖出来更合理的定位是常见漏洞的第一道筛查器——把重复性高的、有规律可循的已知问题交给Skill让人工专注于那些需要业务上下文判断的复杂逻辑漏洞。想要让AI做到这一点你必须在Skill里明确写出它的边界否则AI会自作主张地告诉你这个项目很安全那才是真正危险的事。3. 实战构建security-audit-skill的完整流程说实话我在GitHub上翻过不少开源的安全审计Skill项目各有千秋但很多都存在同一个问题要么检查清单过于笼统要么输出格式不适合直接落到工程流程里。所以这次我干脆自己动手按照目录结构—核心工作流—检查清单—分语言规则—输出模板这条线把整个Skill从零搭了一遍。3.1 Skill的目录结构设计先看最终我落地的目录结构security-audit-skill/ ├── SKILL.md # 技能入口文件描述触发条件与核心流程 ├── assets/ │ ├── owasp_top10.yaml # OWASP Top 102021版检查项配置 │ ├── supply_chain.yaml # 供应链安全专项检查项 │ └── ai_code_risks.yaml # AI生成代码常见缺陷模式 ├── checklists/ │ ├── python.md # Python专项检查清单 │ ├── javascript.md # JavaScript/TypeScript专项检查清单 │ ├── go.md # Go专项检查清单 │ ├── java.md # Java专项检查清单 │ └── web_api.md # 通用Web/API安全审计清单 ├── templates/ │ ├── audit_report.md # 审计报告模板 │ └── issue_card.md # 单条问题卡片模板 └── scripts/ ├── scan_dependencies.py # 依赖漏洞快速扫描脚本 └── sast_quick.py # 轻量静态规则匹配脚本这个结构不是随便拍的每一层都有它的用途。SKILL.md负责让AI快速理解这是一个安全审计技能触发条件是用户要求做安全审查同时告诉它先全局了解项目结构再按清单逐项审计最后输出报告这条主链路。checklists/目录是核心资产按语言和场景拆分这样AI在审计Python项目的时候只需要加载Python的清单而不必背上Java的规则能显著省上下文。templates/则保证了每次输出的报告格式一致方便团队直接做归档和跟踪。scripts/里我放了一些辅助脚本不过这部分是可选的后面我会单独说脚本的边界。3.2 SKILL.md主文件核心工作流与角色定义SKILL.md是整个技能的大脑。我在写它的时候最注意的一点是不能只写你是一个安全审计专家这种空话必须写清楚具体的执行步骤和每一步要交付什么。以下是我精简后的主文件核心逻辑# Security Audit Skill ## 技能定义 你是网络安全审计专家擅长对代码进行白盒安全审计。你的任务是发现代码中的安全漏洞、设计缺陷和风险隐患并输出结构化审计报告。 ## 触发条件 - 用户要求对代码/项目进行安全审计、漏洞扫描、Code Review安全专项等。 - 用户上传了待审计文件或指出待审计代码位置。 ## 执行流程 1. 理解项目目标先浏览项目整体结构确定技术栈、关键入口、数据流。 2. 加载检查清单根据项目语言加载 checklists/ 下的对应文件若为Web/API项目额外加载 web_api.md。 3. 逐项审计按检查清单逐项遍历代码记录每一个可疑点。 4. 验证与优先级排序对可疑点进行交叉验证排除误报按风险等级排序。 5. 输出报告按 templates/audit_report.md 生成审计报告单条问题按 templates/issue_card.md 输出。 ## 核心原则 - 不输出模糊结论每个问题必须给出文件路径、行号、问题描述、风险等级和修复建议。 - 不确定是否可利用时标注需人工确认不得简单定性为安全。 - 无法确认的部分必须明确说明不得编造审计结论。这套流程看起来简单但有个很关键的细节我给了AI一个**先理解再审计的步骤**。如果不加这一步AI经常会在还没搞清项目是干什么的、数据从哪里进来、哪里是信任边界的情况下就凭局部代码片段乱报漏洞。实测下来加了这一步之后误报率能下降三四成。另外我特别写了核心原则这块很多人会忽略它。你可能觉得AI别乱说这种话写不写无所谓但实际上AI在没有明确约束时真的会为了显得专业而编造一些不存在的漏洞或者反过来把所有问题都轻描淡写。把边界写进原则里不是为了提升AI能力而是为了控制它的输出下限这是我这几次打磨里觉得最值的一笔。3.3 核心检查清单覆盖OWASP Top 10与供应链风险检查清单是Skill的内功也是决定审计质量的核心。我把检查项分成了三大类通用Web/API风险、供应链风险、AI生成代码特有风险。下面是我在checklists/web_api.md里沉淀的一部分内容基本对标OWASP Top 102021版做了工程化改写检查项风险等级审计要点典型缺陷示例注入类漏洞SQL/LDAP/命令Critical查找字符串拼接SQL、动态命令执行、eval/exec类函数SELECT * FROM users WHERE name userInput 失效访问控制High检查接口是否校验身份、资源ID是否可越权访问未校验登录态的对象查询接口加密失败与敏感数据泄露High查找硬编码密钥、明文传输凭据、弱Hash算法password 123456硬编码在代码里不安全设计Medium缺少速率限制、缺少输入白名单校验登录接口无失败次数限制安全配置错误Medium默认密码、调试模式开启、错误信息泄露堆栈DEBUG True上线未关已知漏洞与过期依赖High检查依赖库是否过期、是否有CVE记录低版本Log4Shell身份识别与会话管理缺陷HighCookie/Session/Token的生成与有效期是否安全Session固定攻击、Token硬编码在URL软件和数据完整性失败High反序列化是否可信、更新链路是否校验签名pickle.loads(userInput)日志与监控不足Medium关键安全事件是否记录日志登录失败无日志、越权操作无审计SSRFHigh服务端是否请求了用户可控的URL图片代理接口直接请求用户传入的地址这张表之所以值得放在Skill里而不是靠AI自己知道是因为AI对OWASP的记忆往往是概念性的不是条目化的。你让它检查OWASP Top10它可能会漏掉其中两三个因为它在逐行看代码的时候注意力分配不均。但你把表格喂给它让它按表逐项核对它的执行完整性会高很多。这就是把隐性知识显性化带来的收益。供应链风险这一块我在supply_chain.yaml里专门做了配置核心检查点包括锁定依赖版本而不是用模糊版本范围、检查锁文件是否提交、对npm install/pip install执行源的可信度评估、识别被恶意投毒的高危包。前阵子开源社区就出现过多起依赖包投毒事件这已经不是理论风险了而是每天都在发生的真实威胁。很多开发者只看功能不看来源觉得能装上就是好的这个习惯必须靠自动化审计去打破。至于ai_code_risks.yaml这是我自己加的私货专门针对AI生成代码的通病AI特别喜欢把校验逻辑放在前端、把管理员接口和普通接口写在同一套代码里不加角色区分、注释里写这里待补充鉴权然后真的就没做。这部分检查项不是行业标准但在AI编程普及的今天你会发现它甚至比某些传统检查项更实用。3.4 分语言检查规则设计不同语言的漏洞模式差异很大所以我专门为几种主流语言做了独立的检查清单。拿checklists/python.md举例我重点标记了这些坑eval/exec的动态执行、f-string的SQL拼接、pickle.loads处理不可信数据、subprocess拼接命令、Django/Flask的ORM使用不当导致注入、Debug模式上线、SECRET_KEY泄露。每一条我都会在清单里写一个负面示例和一个修复后的正面示例因为AI对规则描述的理解远不如对正反例对比的理解来得精准。前端JavaScript/TypeScript的检查重点就完全不一样了innerHTML直接注入不可信内容、eval动态执行、localStorage存放敏感Token、前端硬编码加密密钥、第三方SDK的权限滥用、npm install时的脚本执行风险。Node.js后端还要额外注意原型链污染、child_process.exec命令注入、不安全的redirect目标校验。Go和Java我也各写了清单但说句实话它们在安全检查上的模式比Python和JS要少一些严重问题因为语言本身对类型和内存安全做了不少限制。Go主要看os/exec命令注入、解序列化特别是encoding/gob、DSL表达式注入Java则重点看反射滥用、JNDI注入、反序列化链、Spring框架的SpEL表达式注入。这个按语言裁剪检查粒度的思路能让AI在审计特定项目时更快命中要害而不是拿一套通用规则去硬套。为了避免检查清单本身变成看着很美但AI懒得逐条照做的死文档我给每条清单都加了可验证的动作描述。比如不写检查是否有SQL注入风险而是写搜索代码中所有与数据库交互的位置检查是否存在字符串拼接SQL的模式若存在则尝试找出可控输入源并验证其是否经过过滤。动作描述越具体AI的执行就越像流程而非想象这一点强烈建议大家在自己写Skill时试验一下。3.5 风险定级与输出模板设计审计报告的输出质量决定了这个Skill能不能真正落到工程流程里。我设计的templates/audit_report.md包含五块项目概览审计对象、技术栈、范围、审计方法加载了哪些清单、执行了哪些步骤、风险统计Critical/High/Medium/Low数量、问题明细逐条列出、整改建议按优先级排序的修复路线。单条问题则用templates/issue_card.md来规范化## 问题 #1 - **风险等级:** High - **文件路径:** src/api/user.py - **行号:** 42-48 - **问题类型:** SQL注入 - **问题描述:** 用户输入的 username 参数未经参数化查询处理直接拼接进 SQL 语句攻击者可通过构造特殊输入实现注入。 - **修复建议:** 改用数据库驱动提供的参数化查询或ORM的绑定参数机制禁止使用字符串拼接方式构造SQL。 - **修复示例:** python # 修复前 cursor.execute(fSELECT * FROM users WHERE name {username}) # 修复后 cursor.execute(SELECT * FROM users WHERE name %s, (username,))是否需人工确认:否是否需人工确认这个字段是我踩坑踩出来的。AI判断漏洞时经常会有两种极端一种是漏报把真问题说成没问题另一种是过度报告把无害代码当成严重漏洞。加了这个字段之后AI反而会更诚实因为它不需要为了显得严谨而把所有问题都定成Critical它可以光明正大地写这条需要人工确认把人和AI的能力做了合理分工。我实测下来**加了需人工确认选项后AI把低风险问题误报成高风险的次数明显减少了**。 ## 4. 让Skill真正生效触发方式、审计工作流与CI集成思路 一个Skill写得好不好最终要看它能不能顺畅地在实际工作中被用起来。很多人把Skill往目录一丢然后对着AI喊帮我审计结果AI根本没加载这个技能出来的报告和普通问答没什么区别。问题多半出在触发链路没设计好。 ### 4.1 Skill的加载与触发策略 目前主流的Agent Skill机制触发方式大概有三种自动加载、关键词触发、用户手动指定。**自动加载**适合那些你希望Agent在每个项目里都默认具备的能力但我建议不要把安全审计设成自动加载因为它有明确的专业边界平时挂在上下文里会挤压其他任务空间**关键词触发**是通过在对话中提到安全审计Code Review安全专项检查漏洞等词来唤起Skill这个策略适合绝大多数场景**手动指定**则适合你把审计作为独立任务来跑的时候直接对AI说使用security-audit-skill对当前项目做一次全面安全审计。 如果你用的是Codex这类可以在对话里直接点选/引用技能工具的产品那就更简单了——直接把security-audit-skill目录挂进去然后下达审计指令。这里有一个细节值得注意**审计时最好给AI一个明确的审计范围**。你是想看整个仓库还是只看某个模块是全语言通用审计还是只看Python后端范围越明确AI的执行效率越高误报也越少。如果什么都不说AI经常会先全项目扫一遍不仅慢而且会把一些无关文件里的无害代码也当成问题报出来。 ### 4.2 把Skill嵌入Code Review主流程 我在团队里推广这个Skill的时候没有一上来就让大家用AI做全量审计而是把它先嵌到Code Review的流程里**每次Pull Request合并之前AI先自动跑一遍Sast-Lite级别的安全审计只在PR描述里贴出新增或变更代码段的安全风险人工Reviewer重点看这些被标记的问题以及那些需要业务上下文判断的改动**。这个流程的微妙之处在于它不是让AI取代Reviewer而是让AI帮Reviewer把怎么都该拦下来的问题先拦下来让人的精力集中在更高层次的架构和逻辑判断上。 实际操作中我会在Skill里额外加一个--diff模式的指令只针对git diff出来的增量代码做审计。这个模式对AI来说其实更容易因为增量越少上下文越干净AI能抓住的细节就越多。相比之下全量审计对长上下文的要求很高AI跑到后面容易遗忘早期看到的代码导致前后结论不一致。所以我的建议是**日常Review用diff模式发版前或大型重构后再跑全量审计**分工明确才能在效率和质量之间找到平衡点。 ### 4.3 与CI/CD流水线的集成思路 很多人问这个Skill能不能在CI/CD里跑起来答案是可以但要想清楚跑的是什么。如果你用的是Codex CLI、Claude Code这类支持命令行调用的Agent工具完全可以把security-audit-skill配置成一个CI步骤在push或merge时自动执行把报告输出成Markdown或JSON文件再由机器人把风险摘要贴到合并请求上。脚本部分我在scripts/里放了一个轻量级的依赖漏洞扫描器核心逻辑就是读取项目的依赖清单然后到已知漏洞库里做比对这部分逻辑简单、确定性高很适合交给脚本而不是大模型去执行。 但我必须提醒一件事**大模型在CI里自动化执行审计最大的风险不是性能而是幻觉式安全**。AI可能在某个很罕见的角度上把一段写得不错的代码误判为有漏洞也可能放过一个有问题的代码。所以对于CI阶段我强烈建议只让Skill输出风险线索Lead级别的结果并且标记为需人工复核而不是直接输出通过/不通过的阻断结论。**让AI做筛查让规则和人工做定案**这条原则我认为是落地这类Agent Skill时最重要、也最容易被忽视的一条。 ## 5. 实测效果与常见问题排查实录 文件写完了信心满满的但真拿项目去实测的时候还是踩了一堆坑。这一节我把自己调试security-audit-skill时遇到的典型问题、定位思路和解决办法整理出来应该能帮你少走不少弯路。 ### 5.1 实测场景与效果数据 我拿了一个内部的中型Python后端项目做了全量审计代码量大概6万行依赖一百多个。接入Skill之前我让AI直接检查安全漏洞结果它只输出了一些泛泛而谈的建议比如注意使用强密码哈希不要硬编码密钥几乎没有定位到具体的文件和行号。接入Skill之后同样一个项目AI不仅定位到了12个具体风险点还按模板输出了带修复示例的报告。虽然经过人工复核12个里有3个是误报或低风险但剩下的9个里有两个确实是被之前的Code Review漏掉的真实问题——一个是不安全的反序列化入口一个是SSRF风险。**从说了等于没说到能挖出被人工漏掉的问题这就是结构化Skill和裸提示词的差距**。 不过我也得说实话这套Skill目前对**业务逻辑漏洞**的覆盖能力还是比较弱的比如优惠券可以重复使用转错账之后没有冲正流程这类需要深度业务理解的问题AI基本发现不了。这倒不是Skill写得不细而是大模型本身的推理局限它很难像资深工程师那样对着需求文档去反向推导这个逻辑在异常分支下会发生什么。所以如果你期望这个Skill能替代安全工程师那现阶段还是别抱这个指望但如果你只是想有个**不知疲倦的实习生**帮你把已知漏洞模式过一遍那它完全能胜任。 ### 5.2 高频问题速查表 | 问题现象 | 可能原因 | 排查与解决思路 | |---|---|---| | AI没触发Skill输出和普通问答一样 | SKILL.md里的触发条件太模糊 | 检查触发关键词是否与日常提问方式匹配必要时在SKILL.md里增加更宽泛的触发短语或在命令中显式要求使用security-audit-skill | | 报告里全是建议使用参数化查询这类空话 | 缺少动作性描述AI在泛泛而谈 | 把清单里的每一条改成在指定目录中搜索某类模式这种动作性描述 | | 误报率特别高 | 检查清单过严或AI没理解项目上下文 | 先让AI在第1步理解项目时输出项目技术栈与信任边界判断再进入逐项审计添加需人工确认选项 | | 审计长项目时后半段结论失真 | 长上下文导致AI遗忘早期信息 | 改用diff模式做增量审计或手动指定关键目录让AI在阶段性检查后输出中间结论再继续后续步骤 | | 依赖扫描脚本跑得很慢 | 把大模型用作确定性任务执行器 | 把依赖比对这类确定逻辑从AI里拆出来交给scripts/scan_dependencies.py这类脚本完成AI只负责解读结果 | | 不同语言项目共用一份清单检查项错位 | 没有按技术栈切换清单 | 在SKILL.md流程里明确根据语言加载对应checklists目录文件缺失语言时默认加载web_api.md | | AI在报告里把低危问题标成Critical | 缺少风险定级校准规则 | 在SKILL.md里补充定级标准高危必须满足外部可控输入无有效防御可达否则降级并标注需人工确认 | ### 5.3 避坑经验与优化建议 整个调试过程中最让我花时间的其实是**怎么防止AI把报告写成八股文**。第一个版本我过度强调输出格式的完备性结果AI为了凑字段把每个文件里所有带引号的字符串都说成疑似硬编码密钥报告又厚又没价值。后来我加了一条原则——**无法判断的问题宁可少报但必须在疑点清单里给出提示**并且要求每个问题必须同时满足找到问题特征和找到触发路径才算成立误报率才真正降了下来。 还有就是**Skill的迭代方式**不要想着一次写完美。我现在的做法是每次实际使用后就把那些AI频繁误报的检查项单独拎出来降权或者加更具体的排除条件把那些AI漏掉的真实漏洞模式提权并补充正反例。也就是说**这个Skill就是一个越用越准的知识库**它的价值会在持续迭代中慢慢积累而不是写出来就固定不变了。 另外如果你打算在团队里共享这个Skill我建议在SKILL.md里加一个独立的团队规范小节把你们团队的严重程度定义、哪些漏洞必须阻断发布、哪些可以遗留为技术债全部写进去。这样一来AI在出具报告时就不会只按通用行业标准来而是会结合你们团队的实际情况给出更有落地意义的建议。这个看起来很小的设计在组织内部落地时的价值甚至比技术本身还要大。 最后再分享一个我后来加进去的小功能在审计完一个项目后Skill会自动追加一个复盘清单环节让AI基于本次审计中发现的薄弱环节建议一个接下来最值得做的三项加固动作。这个设计其实是在实践中发现很多开发者在收到一堆漏洞报告后根本不知道先修什么、后修什么容易直接麻了。有了这个优先级建议报告就不是单纯的问题列表而是一个可执行的行动指引。建议你也在自己的Skill里加上类似的收尾设计它能让整个审计结果真正推动代码质量的改进而不只是停在报了一堆问题这一步。