AI编程助手Skill实战：打造安全审计技能包

最近AI编程助手圈子里的高频词就是“Skill”几乎每天都能看到有人晒自己写的codex skill、claude skill、opencode skill。我在给自己的AI编码环境做安全能力的时候也照着这套思路折腾了一个security-audit-skill说白了就是把我平时做代码安全审计的那套检查方法固化成一个AI能直接读、直接跑、直接出报告的技能包。一套流程跑下来最大的感受是安全审计这件事特别适合做成Skill因为它有固定的检查项、固定的流程、固定要输出的结果比让对方“凭感觉帮我看看代码有没有问题”要靠谱太多。这篇文章就把我搭建security-audit-skill的全过程拆开讲清楚包括Skill到底是什么、一个审计型技能包该怎么设计目录结构、SKILL.md怎么写才不会被AI选择性忽略、代码/依赖/配置三类检查规则怎么固化、接入Codex、Claude Code这类工具后怎么跑通一次真实审计以及我踩过的坑和排查方法。适合正在用AI编程助手、又对代码安全有要求的开发者也适合团队里想给AI加一道安全底线的同学参考。1. 先搞清楚Skill是什么为什么安全审计天生适合做成Skill1.1 从“临时交代”到“技能包”AI协作方式的转变我先用大白话解释一下Skill到底是什么。以前我们让AI助手干一件专业的事比如“审查一下这段代码有没有安全问题”得在对话里临时塞上一大堆背景信息项目用的什么框架、我们要关注哪些漏洞类型、报告按什么格式输出、哪些误报可以忽略。等换个新项目、新会话又得重新交代一遍。这就好比你每次请一个临时工来干活都要从头培训一遍成本高效果还不稳定。Skill做的事情就是把这一套“培训材料”打包成一个文件包放在AI工具能识别的位置。AI加载技能包后会主动按照里面的说明来执行任务。一个Skill通常包含一个主说明文件一般是SKILL.md里面写清楚触发条件、执行步骤、输出格式、行动边界还可以带上规则文档、辅助脚本、参考资料。AI不是把Skill当普通对话内容来“参考参考”而是把它当成“作业指导书”来执行。这个变化的本质是从“提示词”到“可复用工程资产”的升级。提示词是一次性的换个会话就没了Skill是持久化的放进仓库里还能被团队共享、被版本管理谁拉下来都能用。对安全审计这种高度流程化的活儿来说这个特性太关键了。1.2 security-audit-skill 到底负责哪些事我给自己做的security-audit-skill最初划定的职责范围是四块源代码静态审计、依赖与供应链安全、敏感信息检测、配置与权限检查。源代码静态审计检查常见漏洞模式比如注入、反序列化、危险函数调用、不安全的加密算法等。依赖与供应链安全检查依赖是否锁定版本、是否存在已知漏洞、lock文件是否缺失等。敏感信息检测扫描代码库里的API密钥、数据库口令、私钥等硬编码凭证。配置与权限检查查看云厂商配置、Docker配置、IAM权限声明找出过度授权或暴露面过大的问题。这里要特别说清楚边界。安全审计技能不等于渗透测试也不等于漏洞利用。它是一道“体检”负责发现问题、给出修复建议但不负责“动刀”。我在SKILL.md里明确写了禁止行为不主动调用攻击性工具、不尝试利用漏洞提权、不修改任何源代码文件整个审计过程只读所有修复动作都交给人工确认。这个边界既是合规要求也是安全底线。AI自己执行攻击性操作的风险太大任何人都应该把它锁死。2. 动手前先搭框架一个审计型技能包的目录结构2.1 目录结构决定了AI能不能“按图索骥”我最早写Skill时犯过一个典型错误把所有检查和说明全部塞进一个巨大的SKILL.md文件里结果AI加载后上下文被撑爆好多规则根本没走到输出还特别飘。后来参考社区里成熟的做法把技能包拆成“主控文件 规则文件 脚本 参考材料”的结构。我目前稳定在用的目录长这样security-audit-skill/ ├── SKILL.md ├── rules/ │ ├── code-audit.md │ ├── dependency-audit.md │ ├── secret-audit.md │ └── config-audit.md ├── scripts/ │ ├── scan_secrets.py │ └── audit_deps.py ├── references/ │ ├── cwe-mapping.md │ └── owasp-top10-notes.md └── contexts/ └── project-context.md每个目录有明确的用途。SKILL.md是入口负责“判断什么时候触发、按什么顺序做、最后输出什么”rules目录放细分规则AI在做某一类检查时按需读取避免一次性读入太多内容scripts目录放可执行脚本凡是能用程序确定性判断的事情优先让脚本做而不是靠AI“猜”references目录放参考资料帮助AI理解漏洞背后的原理提升报告的可解释性contexts目录放项目相关的说明比如项目技术栈、已知历史问题相当于给审计员看的“项目背景”。2.2 SKILL.md 怎么写才不会被AI“选择性忽略”SKILL.md是整个技能包的灵魂但也是最容易写废的文件。我复盘过很多次发现AI对说明文件的执行程度和编写方式高度相关。下面几条是我实测下来最影响执行效果的点。第一开头就要写清楚触发条件。我习惯写一个Triggers段落告诉AI在什么情况下必须激活这个技能。比如“当用户提及安全审计、安全检查、security audit、扫描漏洞、检查依赖安全、检测密钥等关键词或要求对项目进行安全审查时”。这相当于给AI装了一个启动开关。第二执行流程必须步骤化。不要写一堆描述性的段落而是写明Step 1、Step 2、Step 3每一步做什么、输出什么、读哪个文件。AI对步骤化的指令执行率远高于泛泛的说明。第三明确输出格式。我在SKILL.md里写死了报告模板按严重级别分类、每条漏洞附上文件路径、行号、问题描述、修复建议。固定输出格式之后报告的可读性大幅提升也方便后续接入自动化流程。第四写清楚“不要做什么”。比如绝不执行破坏性命令、不修改源码、不把凭证打印到日志。AI在安全任务里容易“太主动”给出一份行为红线非常必要。第五给足示例。在SKILL.md末尾放一个输入示例和对应的输出示例AI会把这个当成格式参照。这个做法对输出质量的提升非常明显。我当时第一版SKILL.md大概写了200多行后来精简到100行左右把大量细碎规则挪到了rules目录。主文件短而清晰rule文件深而具体这个配合比“一篇长文走天下”要可靠得多。3. 核心内容把安全审计经验固化成机器可读的规则3.1 代码审计规则要怎么写才能抓到真问题代码审计规则是整个技能包的重头戏。我一开始试图让AI自由发挥结果它只能说出“存在SQL注入风险”这种空话别说修复建议了连具体位置都经常给错。后来我把检查规则逐条写成“模式 风险等级 说明 修复建议”的结构效果才真正改善。以Python项目为例我固化了这样几类规则危险函数检测eval、exec、pickle.loads、yaml.load、SQL拼接检测f-string拼接SQL语句、format传参进入execute、命令注入检测os.system、subprocess调用时拼接外部输入、硬编码密钥检测正则匹配常见云厂商AK、私钥块、密码字段。每条规则在code-audit.md里都写成下面这样## SQL注入字符串拼接查询 - 风险等级: Critical - 检测模式: - 调用 cursor.execute / session.execute / engine.execute - 参数使用 f-string、format、% 拼接 - 说明: 直接拼接用户输入进SQL语句可能导致注入。 - 修复建议: 使用参数化查询? 占位符或命名参数例如 execute(SELECT * FROM users WHERE id ?, (uid,))这种规则的好处是AI在执行时能对照模式去代码里找证据而不是凭空抒情。而且规则文件本身也是团队知识库新人一看就知道什么是重点。3.2 依赖审计别让AI自己猜交给工具干确定性的事依赖安全这块我强烈建议让Skill调用现成的扫描工具而不是让AI自己去“判断依赖有没有漏洞”。理由很简单漏洞库是动态变化的AI的知识截止时间决定了它根本不可能准确掌握最新CVE。让AI去猜等于拿旧地图找新路。我的做法是在scripts/audit_deps.py里做两件事。第一件检查项目有没有lock文件比如requirements.txt、Pipfile.lock、poetry.lock、package-lock.json没有就提示“依赖未锁定存在供应链风险”。第二件直接调用系统里安装的扫描器比如pip-audit、osv-scanner、npm audit把它们的输出捕获后整理成结构化结果再交给AI汇总进最终报告。这段逻辑本身不复杂关键是把脚本的输入输出写清楚。AI不需要理解漏洞原理也能用这些结果它只需要把脚本输出翻译成人类能看懂的报告。这正是“AI负责理解与表达脚本负责确定性与准确性”的分工。3.3 配置与权限审计从配置文件里嗅出危险信号配置审计是最容易被忽视、但实际事故率最高的部分。很多项目的代码本身写得挺干净结果公网数据库端口开着、Docker以privileged方式跑、云厂商IAM给了“*”权限一夜之间被打穿。所以我把配置审计单独做了一个规则文件。规则覆盖几类场景第一云权限配置检查IAM策略文本里有没有“Action”: “”或者“Resource”: “”这种过度授权写法第二数据存储暴露检查配置文件里数据库地址是否绑定了0.0.0.0、公网RDS节点等第三容器安全检查Dockerfile里有没有USER root、privileged: true、挂载了宿主机敏感目录比如/etc第四密钥管理检查是否直接把明文口令写在配置文件里而不是用环境变量或密钥管理服务。这些规则几乎都是“静态看文本就能判断”的非常适合固化成规则给AI执行。每次审计时AI会读取配置文件、Dockerfile、部署清单逐条对照规则把命中项归档进报告。由于这类规则非常明确误报率比代码审计低得多整套技能里性价比最高的就是配置检查。4. 实操记录从零搭好Skill并跑通一次真实审计4.1 初始化技能包并接入AI编程环境下面是我实际操作的完整流程照着做基本不会跑偏。第一步在本地建目录这里我用的是一个专门存放技能的目录然后初始化git仓库方便版本管理。mkdir -p security-audit-skill/{rules,scripts,references,contexts} cd security-audit-skill git init第二步编写SKILL.md这是第一步的核心文件。我给了简化的开头示例实际用的时候可以根据自己的项目补充细节。写完之后把rules目录下的四个规则文件一一补齐。第三步把脚本放入scripts目录并赋予可执行权限。chmod x scripts/scan_secrets.py scripts/audit_deps.py第四步把整个security-audit-skill目录放到AI工具能够识别的位置。不同的AI工具加载方式不一样有的从全局skills目录加载有的在项目根目录找.skill文件夹。我自己在Codex环境里会在项目根目录放一个.skill目录在Claude Code环境里会把技能包路径加进配置。但总的原则是一样的让AI明白它的工作目录里有一个可用的技能包并且通过SKILL.md里面的触发词去激活它。第五步做一次最小验证。我通常会先对一个小仓库跑一遍看AI会不会给出结构化的报告、会不会把规则真正执行出来。如果AI只是泛泛而谈我就回头检查SKILL.md是否写得太模糊、规则是否没有被引用到。4.2 演示一次完整的审计执行链路我拿一个模拟的FastAPI小项目来演示。这个项目故意放了四个问题一个SQL拼接、一个硬编码的API密钥、requirements.txt里没有锁版本、Dockerfile缺少非root用户。当我对AI说“用security-audit skill检查一下当前仓库”时AI按SKILL.md里的流程依次执行。第一步AI列出项目文件清单并读取规则。第二步AI调用scripts/scan_secrets.py扫描密钥和敏感信息脚本输出命中位置。第三步AI调用scripts/audit_deps.py检查依赖锁定情况脚本提示requirements.txt缺少固定版本。第四步AI读取Dockerfile和配置文件对照config-audit.md做配置检查。第五步汇总成报告。脚本这块我简单展示一下scan_secrets.py的核心逻辑正则扫描加上常见假阳性目录的排除#!/usr/bin/env python3 import re import os import sys KEY_PATTERNS [ (re.compile(r(?i)(api[_-]?key|secret|password|token)\s*[:]\s*[\][^\][\]), Potential credential assignment), (re.compile(r(AKIA[0-9A-Z]{16})), AWS Access Key), (re.compile(r-----BEGIN (RSA |EC |DSA |OPENSSH )?PRIVATE KEY-----), Private Key Block), ] SKIP_DIRS {.git, node_modules, venv, dist, build, __pycache__} def scan(path): results [] for root, dirs, files in os.walk(path): dirs[:] [d for d in dirs if d not in SKIP_DIRS] for fname in files: fpath os.path.join(root, fname) if os.path.getsize(fpath) 2 * 1024 * 1024: continue try: content open(fpath, r, encodingutf-8, errorsignore).read() except Exception: continue for pattern, desc in KEY_PATTERNS: for m in pattern.finditer(content): line_no content[:m.start()].count(\n) 1 results.append((fpath, line_no, desc)) return results if __name__ __main__: for file, line, desc in scan(sys.argv[1] if len(sys.argv) 1 else .): print(f{file}:{line}: [{desc}])AI最后生成的大致报告如下[Critical] SQL注入风险 文件: app/db.py:42 描述: 使用f-string拼接用户输入构造SQL查询 建议: 改为参数化查询 [High] 硬编码API密钥 文件: app/config.py:17 描述: 检测到疑似API密钥赋值 建议: 改用环境变量或密钥管理服务 [Medium] 依赖未锁定版本 文件: requirements.txt 描述: 未发现版本锁定或lock文件 建议: 使用pip freeze生成requirements.lock [Medium] 容器以root用户运行 文件: Dockerfile 描述: 未声明非root用户 建议: 添加USER appuser并创建低权限用户这个报告格式就是我当初在SKILL.md里把输出模板写死之后得到的效果。没有这一步AI的输出经常是一段散文有了固定模板结果稳定多了。4.3 用了一段时间之后的实际感受我拿这个技能包跑了几个中型项目最直观的感受是当规则定型之后AI的审计覆盖率是很稳的只要项目结构不是特别刁钻像SQL注入、硬编码密钥、依赖未锁版本、容器没有非root用户这类高频问题几乎一抓一个准。它做不到人类资深审计员的“灵光一现”但对常规检查项的覆盖能力已经非常接近标配流程了。更重要的是它可以作为第一道防线反复免费跑人工只需要复检被命中的项和看看有没有漏网之鱼。漏报情况也确实存在尤其是那种需要跨文件理解业务逻辑才能发现的漏洞AI很难靠规则命中。所以我的定位是“机器查常规人查逻辑”两者配合而不是互相替代。这个认知很重要能避免对技能包产生不切实际的期望。5. 常见问题与排查技巧实录5.1 技能包没有被AI加载或触发这是我被问得最多的情况。检查顺序一般是确认SKILL.md文件名和内容格式没有问题确认技能目录放在AI工具要求的加载路径下确认触发词是否与对话输入匹配比如说了“检查一下安全”但触发条件里只写了“security audit”那AI很可能不会激活技能最后在部分工具里新增技能后要重新加载或重启会话否则AI读不到新文件。还有一个小坑如果技能目录被.gitignore忽略了或者放在了没有权限的目录里AI也会找不到。我至少遇到两次是因为目录没读权限导致技能静默失效排查了好久才发现是权限问题。5.2 审计结果太泛、没有细节如果AI给的报告全是“建议增强代码安全性”这种空话多半是规则文件没有真正被AI引用。我在SKILL.md每个执行步骤后面都明确写了一句“请读取rules/code-audit.md并逐条对照检查”这样AI才会真正去加载规则。另一个原因可能是项目太大AI只扫描了根目录几个文件就仓促收尾。我的解法是在SKILL.md步骤里加了范围限制要求AI优先检查代码入口、数据处理函数、数据库访问层、认证授权模块并在报告里列出覆盖的文件数。有了这个要求AI的覆盖范围明显变全了。5.3 误报率偏高怎么办误报集中在两类一是把正常的配置项识别成风险比如把测试环境的密码字段当成生产密码二是密钥扫描把样例、mock数据当成了真实密钥。我的处理方式是两条。第一在规则里加白名单条件比如测试文件、fixtures、mock目录直接跳过第二输出分级Critical和High只放有确定性证据的风险Medium和Info级别用于提示性和疑似问题。分级之后真正需要人工紧急处理的噪音少了很多报告也更能让人信服。5.4 关于AI执行边界的一点提醒最后这条不是技术问题但比技术问题更重要。安全审计技能包在运行时会读取大量代码和配置AI环境必须是可信的不要随意把包含生产凭证的仓库交给来历不明的第三方工具或者云端会话去分析。同时SKILL.md里明确禁止AI执行任何“尝试利用漏洞”“绕过认证”“执行攻击脚本”的行为我这里再强调一次任何人都不应该把这类能力授予AI。安全审计的目标是发现问题、修复问题不是攻破系统。把这条底线守住这个技能包才真正有价值。我把自己踩过的这些坑整理成了表格方便你快速排查。现象常见原因处理方式Skill未加载目录路径错误或触发器不匹配核对加载路径、重启会话、检查权限报告内容空泛没有引用规则文件在SKILL.md步骤中明确要求读取规则文件误报过高未设白名单和分级增加排除目录和严重级别区分扫描覆盖不全项目过大AI只看了一部分限定检查范围和必查模块AI输出不稳定没有固定输出模板在SKILL.md内置报告格式模板说实话最初把安全审计做成Skill纯属是被反复“临时交代”磨得不耐烦了。真正做完之后我才意识到最有价值的不是那几行脚本和规则文档而是把大脑里零散的经验整理成了可以被复制、被迭代、被团队共享的资产。每次发现一个新的漏洞模式我只需要往rules目录里加一条规则这个技能包就比以前更聪明一点。如果你也准备给AI助手装一个类似的技能我的建议是别想一步到位先跑通最小闭环再慢慢往里面喂规则。它不需要一开始就覆盖全世界把一个框架搭起来后续的沉淀会让你越用越顺手。