大概半年前我们团队的上线流水线第一次被安全检测卡住原因是一个AI生成的接口里直接把用户传进来的文件名拼进了系统命令中。最让我后背发凉的不是那个漏洞本身而是那条代码写得相当漂亮注释齐全、命名规范代码审查环节大家都扫了一眼就放过去了。从那之后我一直在琢磨一个问题既然AI写代码已经快到这个地步能不能让AI也承担同等强度的安全审计答案就是今天要聊的项目——security-audit-skill一个专门给AI编程助手用的安全审计技能包。如果你平时在用Claude Code、Codex、OpenCode这类AI coding agent并且需要经常把关代码质量这篇文章会很适合你。我会从skill本身是什么、为什么不能靠临时对话来做审计、SKILL.md怎么写、检测规则怎么定一路讲到实测效果和踩坑经验。整个过程我尽量按自己能复现的路径来写你把目录结构和代码拿过去稍微改改路径就能用起来。1. 从一次CI卡住的经历说起AI写代码太快出事也快1.1 那天的合并请求上周三下午同事小林提交了一个400多行的重构分支改动集中在一个订单查询模块。改动量不算大代码风格也挺统一我照惯例在代码审查里走了个过场正准备点Approve的时候CI上的安全扫描脚本突然报了个高危——函数入口附近有一行subprocess.call执行的命令直接用os.path.join拼了用户可控的文件名。如果深入一点完全可以构造一个; rm -rf之类的payload骗过文件名校验。这个bug说实话不是小林水平不行而是他用了AI补全来写这部分逻辑。AI给出的代码语义上完全正确——它确实在“拼接命令”而且为了安全还特意用了列表传参的方式只是漏了最关键的一环参数在进入拼接逻辑前没有做任何白名单校验。这种“差一点就安全了”的代码恰恰是当下AI编程助手产生得最多的安全隐患。1.2 我们需要的不只是“代码审查”是可复用的审计能力当时我脑子里冒出来一个想法如果AI能在一分钟内生成几百行代码那它应该也可以在几分钟内把同样规模的代码从头到尾审一遍。问题是普通对话式的AI安全审计根本靠不住一来它每次回复的质量波动很大二来它在长上下文里很容易“后面忘了前面”。我需要的是一个能被固定下来、反复调用、输出格式稳定、带着明确检测规则的审计流程。于是就有了security-audit-skill。它的定位很简单给AI编程助手装上一个“安全审计员”的职业身份和操作手册让AI在收到指令后不是凭感觉泛泛而谈而是按我预先定义的规则清单、检测级别、报告模板去执行。这个思路跟人差不多——你不能指望一个实习生靠天赋完成审计但你可以给他一份检查表和一套标准化流程让他按表办事。skill完成的就是这件事。2. 为什么通用对话式审计不靠谱skill才是正解2.1 临时prompt的三个致命伤很多人一上来就说安全审计这事我直接在大模型对话框里输入“帮我看看这些代码有没有安全问题”不就行了我一开始也这么干试了大概两周总结出三个让人相当头疼的问题。第一标准不一致。同一个函数今天让AI审它可能只提了一句“注意输入校验”明天换个模型版本再问它却能给你列出一条完整的注入链还附上攻击示例。不是模型变聪明了而是它对“安全”这件事的理解受上下文影响太大。第二规则记不住。对话一长AI就倾向于被你后来说的内容带走你前面交代的“重点关注SQL注入和反序列化”到后面可能就剩“重点关注”三个字还留着。第三结果没法自动化。对话式输出的格式千奇百怪有的是表格有的是废话段落有的是带[严重]标号的长文本你想接到流水线里做判断对不起得先写解析器去适配它每次的“随机发挥”。2.2 skill机制解决的是“一致性”问题后来我开始研究各家AI编程助手的skill机制发现它解决的核心问题就是“一致性”——把一套流程、规则、参考样例固化到一个目录里模型每次调用时按固定的SKILL.md文件加载再根据指令区定义的步骤逐项执行。这跟你给新人发一本《岗位SOP手册》是完全一样的逻辑。skill的一致性体现在三个层面。加载层面模型的指令遵循机制决定了它会优先按SKILL.md里的要求办事而不是临场发挥内容层面检测规则写在一个或多个独立的知识文件里需要时逐条引用不会被对话历史冲淡输出层面模板规定了风险等级、描述格式、修复建议AI按模板输出下游怎么接都方便。正因如此我才敢把安全审计这种容不得“发挥”的严肃任务交给skill来做。它虽然不会比一个专业安全工程师更聪明但它能做到每次都用同一套标准来审代码不疲劳、不跳步、不耍小聪明。2.3 与agent的区别skill是能力包agent是决策者这段时间“agent skill”两个词热度都很高经常看到有人搞混。如果拿现实世界打比方agent是一个能自己做决策、自己规划步骤的“自由职业者”而skill是这个职业者手里的“工具箱”或者“标准作业流程”。agent决定先去哪个目录、哪些文件值得审、审计结果出来后要不要阻塞合并这些是agent的事而怎么判断一个函数是不是存在命令注入、什么样的密钥格式算硬编码、报告怎么写成固定结构这些全部归skill管。所以在实际配置里我建议把skill和agent的制度分开来理解。比如在Claude Code里你可能先定义一个“安全评审员agent”它的职责是自动开启审计、读取diff、发起block然后security-audit-skill作为它的能力包被加载提供具体的审计方法和输出模板。反过来skill完全可以脱离agent单独被某个普通会话调用只要你用对了触发描述。3. SECURITY-AUDIT开搞skill目录结构与SKILL.md核心写法3.1 先认识skill的目录结构一个标准的skill实际上就是一个有固定结构的文件夹。我的security-audit-skill布置在用户目录下结构大概是这样security-audit-skill/ ├── SKILL.md ├── rules/ │ ├── sql-injection.md │ ├── command-injection.md │ ├── path-traversal.md │ ├── secret-hardcode.md │ ├── dangerous-functions.md │ ├── deserialization-risk.md │ └── dependency-vulnerability.md ├── examples/ │ ├── demo-flask-login.py │ ├── demo-django-api.py │ └── review-report-sample.md └── scripts/ ├── secret_regex_scan.py └── dangerous_calls_scan.py这个结构不是随手拍的它遵循了skill设计里“指令尽量短、知识尽量外置”的原则。SKILL.md负责指挥rules目录负责存放专业规则examples目录为模型提供“标准答案”式的样例scripts目录则让确定性高的检查交给脚本去做而不是让模型靠蒙。3.2 SKILL.md的frontmatter最容易被忽略的部分SKILL.md的顶部是YAML格式的frontmatter很多人写skill时只在意正文里怎么描述流程 frontmatter随手一写就完事。但其实这里面的description字段是模型判断“什么时候该加载这个skill”的关键写得好不好直接影响你的skill能不能在关键时刻被主动调用。--- name: security-audit description: 对代码目录、单个文件或Git diff中的变更内容执行安全审计。检测SQL注入、命令注入、路径穿越、硬编码密钥、危险函数调用、反序列化风险、依赖安全问题并按统一模板输出风险报告。适用于代码合并前审查、依赖升级后检查、代码片段投喂前的自检。 metadata: version: 0.3.2 tags: [code-security, owasp, code-review, audit] ---你看这里我写得很具体把能在哪些场景使用都点明了。模型在接受到用户自然语言指令时会拿着这句话跟用户的意图做语义匹配。如果写得过于宽泛比如只写“用于安全审计”那么用户说“帮我看看这段代码”的时候模型可能根本不会触发这个skill因为它不确定这段代码跟“安全审计”强相关。把触发场景显式写清楚是我踩了几次“技能不生效”的坑之后总结出来的。3.3 指令区从“泛泛而谈”到“按流程执行”frontmatter下面就是指令正文。这里最忌讳的是写得像论文摘要——一堆形容词但没有任何可执行的动作。我早期版本写的是“全面、深入、多层次地分析代码安全风险”结果模型每次给的报告都很“全面”但全在讲废话。改成“按固定步骤执行”之后效果立刻不一样了。核心指令我分为几个阶段# security-audit 执行指令 你是一个拥有OSCP和CISSP背景的代码安全审计员。请严格按以下流程执行不要自行添加无关分析不要省略任何步骤。 ## 第一步确认审计范围 - 如果用户未指定范围默认查看当前工作目录下所有源代码文件排除node_modules、venv、dist等目录。 - 如果提供了文件或目录则只审计指定范围内的内容。 ## 第二步读取审计规则 - 依次读取rules/目录下的规则文件逐条对照当前代码。 - 规则文件中的每一种漏洞类型都要在报告中单独体现。 ## 第三步逐文件审查 - 对每个目标文件按“数据入口 → 数据流转 → 危险操作”的链路来分析。 - 关注外部输入HTTP参数、环境变量、文件内容、网络请求是否未经验证就进入危险函数。 ## 第四步输出结构化报告 - 严格按照报告模板输出风险等级分为严重/高危/中危/低危/提示五级。 - 每项发现必须包含文件位置、风险描述、漏洞依据、攻击场景、修复建议。 - 如果未发现问题报告开头直接写“未发现明确的安全风险”。这里有一个关键设计思想把审计路径显式化。模型擅长的是模式匹配和链路分析但它不会主动给自己规划“先看入口、再看流转、最后看危险操作”的专业步骤。你要替它把思考路径定义好它才能真正像安全工程师一样去查问题。3.4 参考文件与示例的分工rules目录下的文件本质上就是“知识点外置”。为什么要外置因为大模型的知识虽然庞大但对特定检测项的细节记忆并不稳定。比如问“哪些函数容易产生命令注入”它可能记得exec和system但容易漏掉ProcessBuilder、child_process.execSync、os.popen这些。把完整清单写到规则文件里模型在调用skill时会主动去文件里查这比靠它记忆靠谱得多。examples目录则是给模型做few-shot演示的。这里我放了三类示例一个是有明确type的Flask登录代码一个是Django API里存在的IDOR越权问题另外是一份审计报告范例。报告范例特别重要因为模型输出格式的“模仿能力”非常强——你给它一篇结构整齐的报告它大概率会照葫芦画瓢。反过来只给它一段“请按模板输出”它还是会输出出一堆格式飘忽的东西。3.5 配套扫描脚本为什么skill里需要代码前面说到有些检查让模型来做就像让文科生做算术题不是不行而是又慢又不精确。典型的就是硬编码密钥检测和危险函数枚举。所以我额外写了secret_regex_scan.py和dangerous_calls_scan.py两个脚本放在scripts目录下。secret_regex_scan.py做的事情比较机械用一组经过打磨的正则去匹配AWS Access Key、GitHub Token、私钥块、常见云厂商密钥等。比如匹配GitHub Token的正则是ghp_[A-Za-z0-9]{36}匹配AWS Access Key的是AKIA[0-9A-Z]{16}。这类匹配规则固定、误报率低脚本比模型从语义上猜要可靠得多。dangerous_calls_scan.py则维护了一个危险函数黑名单用AST解析的方式扫出目标代码里所有被调用的黑名单函数并标出文件行号。这样模型拿到结果后只负责判断“这处危险调用是否被外部输入触达”而不需要自己满文件找eval(,exec(,shellTrue这些词。两件事分开后各自都变得又快又准。4. 审计规则怎么定哪些漏洞必须抓哪些宁可放过4.1 高危检测项的优先级排序确定检测规则之前我专门统计了内部项目和开源社区里AI生成代码的典型漏洞样本发现风险分布高度集中。排在最前面的四类分别是注入类漏洞、硬编码密钥、危险函数滥用、不安全的依赖使用。这四类加起来占了问题总数的八成以上所以我决定把有限的审计“带宽”全部押在这四类上其余的比如业务逻辑漏洞、复杂度问题宁可先放过。优先级上我按“可利用性”和“影响范围”排了序。只要能构成外部输入到危险函数的完整链路不管是SQL注入还是命令注入一律先定为严重或高危需要立即修复硬编码密钥看具体类型云厂商密钥和数据库密码算高危普通内部测试token算中危危险函数调用如果没有外部输入链路只算低危依赖问题则视漏洞库里有没有披露漏洞而定。4.2 硬编码密钥的检测策略硬编码密钥是AI生成的代码里出现频率最高的“低级错误”原因很简单——AI训练数据里确实充满了getenv和placeholder混淆着用。它很多时候会生成一个“先写死后面再改”的密钥。针对这个我在规则文件里搭配了三层策略。第一层是正则扫描交给secret_regex_scan.py识别带特定前缀的密钥格式。第二层是上下文启发式交给模型判断如果一个变量名是password、secret、token、api_key而赋值是一个超过12位的高熵字符串就要怀疑硬编码。第三层是历史比对如果某条硬编码密钥在Git历史里被提交过还要额外注明“需要立即轮换”因为一旦提交到版本库它就该被认为是泄露状态。4.3 注入类漏洞怎么让模型“真的找到”而不是瞎猜注入检测是安全审计里技术含量最高的部分也是最容易让模型“表演性发现”的部分。早期我在测试时模型经常在报告里写“该处可能存在SQL注入风险”但我追查代码时发现那条SQL根本没有任何用户输入参与——这就是典型的瞎猜。为了让模型拒绝瞎猜我在指令里专门加入了“链路举证”要求任何注入类发现必须同时列出数据入口、流转路径、危险函数三个环节的具体代码行号和片段。缺少任何一环该条发现不得标为严重或高危。实际上跑下来这条约束非常管用。模型为了满足“链路举证”会真的去追踪参数从request.args.get到execute()的完整路径而不是看着有个execute()就乱报。4.4 依赖与配置问题用最小成本覆盖最大风险面依赖漏洞检测如果要求模型在每一次审计中都去完整分析lock文件成本会非常高而且模型记忆中的CVE信息也可能过时。我的方案是分层处理常规审计时只要求模型指出requirements.txt、package.json、pom.xml里明显过时的关键依赖并建议执行pip-audit或npm audit这类确定性工具如果用户显式要求完整依赖审计再通过脚本调用OSV的API去比对。配置层面的检查我也给了明确的清单是否开启了调试模式、CORS是否配成*、数据库连接是否强制TLS、是否缺少鉴权中间件、Session配置是否安全。这些检查不需要复杂的推理有就是有没有就是没有属于规则明确型判断。模型做这类判断时的准确率相当高因为它不需要猜测只需要检索配置项。4.5 结果模板方便人读更要对接CI报告模板我设计成了风险等级逐行排列的结构化列表每个条目都包含六个字段。风险等级文件位置风险类型漏洞依据攻击场景修复建议高危app/routes/order.py:42SQL注入用户输入直接拼接进SQL语句攻击者可通过order_id参数注入恶意SQL拖出全表数据改用参数化查询严重app/config.py:7硬编码密钥AWS Access Key明文出现在配置文件中若仓库被公开云资源将被完全控制移除密钥并使用Secrets Manager这个模板的用意有两个。一是给人看风险等级、位置、依据一目了然开发人员不需要成为安全专家也能照着修二是给机器接我写了个小脚本会把输出解析成JSON供CI流水线判断要不要阻塞合并。你没看错安全审计的真正价值不在于“发现问题”而在于“以可靠格式把问题带到该被处理的地方”。5. 实战验收用故意埋雷的代码测试skill的真实水平5.1 构造三组“带雷”测试用例写完了不能光在文档里吹我专门造了三组测试用例来验收skill的实际效果。第一组是一个Flask登录接口里面有标准的SQL注入模板把request.form.get(username)直接拼进SQL查询。第二组是一个文件下载接口用send_file结合os.path.join拼接用户传入的filename参数同时还在另一个模块里硬编码了一个GitHub Token。第三组模拟跨文件问题入口函数接收参数传给工具函数工具函数再调用eval()。每组测试我都跑了两遍一遍让模型直接用普通对话审另一遍挂载security-audit-skill审对比两者输出的质量和准确度。第一遍的结果基本印证了我之前的判断——普通对话版确实能找到一处明显的SQL注入但大概率漏掉硬编码密钥而且报告格式是散文体非常难粘接到后续流程。而挂载skill后三组用例里的雷被全部排查了出来且每条都带链路举证格式也完全统一。5.2 实际输出skill版报告长这样拿第三组跨文件用例来说skill版输出的关键条目是这样严重 | utils/helpers.py:17 | 危险函数滥用(Eval) - 漏洞依据entry_func→sanitize_input→helpers.eval()data参数从外部HTTP请求流入sanitize_input只做了类型转换未阻止可执行代码。 - 攻击场景攻击者传入__import__(os).system(whoami)eval将执行恶意系统命令。 - 修复建议移除eval改用ast.literal_eval或在入口处做基于正则的白名单格式校验。最让我满意的是“攻击场景”这一行。模型不仅指出了问题还构造了一个可执行的payload而payload完全基于代码自身的信息推出来的不是套话。这说明当流程、规则、举证要求三者齐备的时候模型是能把“安全审计”这个任务做好的只是需要给它一个足够明确的工作框架。5.3 评测维度和通过标准我给自己定了一个评分标准每次迭代都要跑一遍检出率要能100%覆盖测试用例里人工埋的雷误报率低于20%允许存在“提示级”的误导但不允许把无外部输入的普通代码标成严重平均耗时控制在90秒内因为审计如果慢到让人不想跑那再准也没用。按照这个标准目前skill的v0.3.2版本已经稳定通过而且横向对比普通对话模式同样任务普通对话耗时约3-5倍而且输出格式还需要手动二次整理。6. 用测试中踩过的坑说几个安全审计skill的保命经验6.1 上下文窗口是有上限的审计要“分片”第一版skill跑真实项目时我直接把整个中型仓库的几千个文件一口气丢给模型审计结果不到一分钟上下文就爆了。后来我把审计范围分成两层如果目标是单一文件或单次diff直接全量加载如果是整个项目就让模型先读取文件清单再按模块或目录分批审计最后汇总。这个“分批审计、汇总合并”的模式既保住了上下文又能让每一批文件得到足够深度的分析。现在我的指令里默认写了这个逻辑“当发现文件数超过50个时自动拆分为不超过10个文件的批次逐批执行”。6.2 误报比漏报更消耗信任做安全审计最怕的一件事不是漏报而是误报——尤其当误报带着“严重”的等级出现时开发人员会对整个审计机制产生不信任之后真的告警出现他们反而可能选择忽略。为了控制误报我采取了两个措施一是在规则文件里给“外部输入”和“危险函数”做严格定义二是引入了“置信度标记”机制每项发现除风险等级外还会标注“确定程度”确认有完整链路、可疑链路有断点、存疑依赖模型推测。凡是存疑级别的发现默认都不允许标记为高危以上。6.3 跨文件数据流别全靠模型脚本先行跨文件数据流追踪是最消耗模型精力的任务也最容易出错。模型在追踪时往往会“脑补”出一些本来不存在的调用关系尤其是当函数名比较相似的时候。后来我改为“脚本先扫、模型后判”的协作模式先让dangerous_calls_scan.py把所有危险调用的文件和行号扫出来再让模型带着这些问题去追数据链路而不是从头到尾自己找。这样既减少了模型的自由发挥空间又大幅提升了追踪准确率。6.4 token开销控制思路每次全项目审计烧掉的token量换算成成本是一笔不能忽视的账。为了压成本我调高了脚本的自动化比例把所有能正则化判断的检查全部挪到脚本里做模型只承接那些真正需要语义理解的部分比如链路分析、攻击场景构造和修复建议生成。另外对重复审计过的目录我会缓存基线版本二次审计只对比diff部分不看全量文件。这个“只审变化”的策略让日常审计成本下降了70%左右效果却比之前审全量还要好。6.5 规则要随实战演化这就是skill蒸馏最后说一个概念很多人最近在讨论的“skill蒸馏”其实就是把实践中沉淀出来的判断不断浓缩回skill文件里。比如我写第一版时规则里没有“不安全的Nginx配置”这一项但有一次实测发现AI生成的配置文件里proxy_pass参数竟然允许用户控制URL于是我把这条新增进规则库。每跑一次真实项目就把新发现的漏洞类型抽象成一条规则写回rules目录每两到三个版本做一次规则去重和整理。这套持续演化的机制才是最值得投入时间的地方——因为漏洞不是静态的AI写代码的风格也在变规则不跟着变迟早会被绕过。从最初那次CI被卡住的合并请求到现在这套能稳定输出的security-audit-skill我最大的感受是AI写代码已经不可逆了但安全防线完全可以通过给AI配备同样先进的能力来对冲。别指望一个临时提示词能管住安全真正可靠的是把流程、知识、脚本和输出模板固化成一个可版本化、可持续演化的skill。如果你也在用AI编程助手写代码非常建议花一个下午把这套目录搭起来用几段自己项目里的真实代码验证一下。审计可能不会让代码瞬间变得无懈可击但至少它能在漏洞合并进主干之前把那个“差一点就安全了”的瞬间揪出来。
