从AI安全审计到Skill工程化：打造可复用的代码审计工作流

1. 为什么单独做一套安全审计Skill核心需求拆解这几年跟AI编码工具打交道多了我养成一个习惯凡是重复性的技术活先想能不能沉淀成一个skill。原因很简单通用对话模型虽然有编程能力但让它做一次像样的安全审计效果往往飘忽不定。上一轮它可能认认真真盯完了SQL注入下一轮你把项目换掉它又漏了日志脱敏。问题不是模型变笨了而是缺少一套固定的、可复用的工作流约束。做安全审计这行的人都清楚审计最怕的不是技术不够深而是覆盖面不稳定。人工审计靠checklist靠经验驱动的抽查节奏靠对业务逻辑的理解但AI辅助审计如果只靠临时prompt它会随上下文漂移。今天提醒了它检查越权它查了明天换一个会话它可能又忘了。security-audit-skill这个项目的出发点和价值就是把分散的安全知识、检查项、报告模板、输出规范全部固化成一个可装载的技能包让AI每次执行时都走同一条路不会漏站。它解决的核心问题有三个检查覆盖面不稳定用固定流程和检查项清单约束模型最大限度减少漏检。结果难以复用每次审计输出格式不同没法直接归档。skill里预设了报告结构和风险评级。人工经验没沉淀把资深审计师的脑内清单变成可共享的结构化内容团队里任何人调用都能获得相近质量。适合谁来参考呢一是做应用安全、代码审计的工程师想用AI提效但不希望它胡来二是DevOps和研发团队想在日常迭代里引入轻量安全自检三是对Agent开发感兴趣、想了解如何把专业方法论做成skill的开发者。这篇文章我会把安全审计skill的设计思路、配置方式、实操流程和坑全部拆开讲尽量给出一份能直接抄作业的参考。2. Security Audit Skill整体设计思路2.1 Skill本质是一套可装载的专业方法论先聊一个基础概念skill在AI Agent场景里到底是什么。简单说它是一组指令、提示模板和可选脚本的集合用来让模型在特定任务上有更稳定的表现。它和普通prompt的区别就像模板函数和一次性脚本的区别。prompt是一次性的关掉窗口就没了skill是可以反复调用、跨项目迁移、团队共享的结构化资产。安全审计skill的设计核心是把审计流程拆成四个阶段信息收集、静态分析、动态验证、报告输出。每个阶段都有一组独立的指令和检查提示模型被要求严格按顺序执行。这样做的逻辑是安全审计本身是一个强流程性的工作不能上来就翻代码得先明确范围和技术栈不能发现一个点就急着下结论要交叉验证再定级。把流程写进skill里本质上是用工程化手段对抗大模型在开放任务上的随意性。我踩过不少次坑最典型的是直接扔给模型一个项目让它找漏洞它确实能找到几个问题但报告写得乱七八糟风险等级全靠猜也没有复现步骤。后来把流程固定成模块每个阶段限定输出内容质量立刻稳定了。这一步的经验是skill不光是告诉AI“查什么”更重要的是告诉它“先做什么、后做什么、每步输出什么”。2.2 方案选型为什么用文件目录加规则约束实现skill的方案并不少我最终选择了文件目录驱动的形式。项目的核心结构包含三部分SKILL.md作为主入口audit_rules/目录放专项检查规则report_template.md规范报告输出格式。选用这种结构的原因很实际它平衡了灵活性和可控性。主文件负责流程编排告诉模型什么时候加载哪些规则。规则目录按主题拆分方便单独维护和增量添加新检查项。报告模板保证每次输出的结构一致便于自动归档和后续对比。有人习惯把所有内容怼进一个巨大prompt我不推荐。一方面上下文窗口是有限资源规则太长会挤占代码分析空间另一方面拆开目录后模型可以按需读取不用一上来就加载全部规则。这就好比审计工作底稿你不会把几百页检查清单背在脑子里而是需要查哪块就翻哪块。还有一个选型细节值得说安全审计本身是个偏防御性的技术方向我做这套skill时特意把规则里涉及复现利用的部分写得克制。目标是让开发者自查、让审计师提效而不是把一套攻击兵器交到不会用的人手里。像SQL注入和命令注入这类检查项我强调定位和修复建议尽量不给完整利用链路。2.3 构成拆解每个文件解决什么问题现在把目录结构摊开讲一讲。security-audit-skill/ ├── SKILL.md ├── audit_rules/ │ ├── injection.md │ ├── auth.md │ ├── access_control.md │ ├── data_protection.md │ └── config_and_dependency.md └── report_template.mdSKILL.md是总调度文件定义了任务目标、审计阶段以及规则文件的加载顺序。它告诉模型如果收到审计请求先确认目标范围再依次读取audit_rules/下相关文件最后按report_template输出。audit_rules/里每份文件专注于一个安全域。injection.md管注入类问题auth.md管认证与会话管理access_control.md管越权和权限控制data_protection.md管敏感数据泄露与日志脱敏config_and_dependency.md管配置错误和依赖漏洞。这种划分沿用了业内常见的安全知识体系没有标新立异但覆盖面足够日常项目用。report_template.md是很多人会忽略、但实际极其重要的一块。它规定了报告必须包含风险等级、影响范围、问题描述、复现步骤、修复建议。为了减少模型编造风险我还加了一行指令所有问题必须标注证据来源比如代码文件路径和行号拿不准的宁可不写也不能编。3. 核心检查点设计与实操要点3.1 认证与授权最容易出事的两个领域认证和授权看着简单实际写规则文件时非常容易写得假大空。比如“检查是否存在越权漏洞”这种描述对模型来说没有可执行性。它不知道要去看哪些接口、对比哪些角色、判断什么逻辑。所以规则里必须给足具体的动作指令。我审计早期踩过很经典的坑。有一个管理后台接口前端隐藏了删除按钮但后端没有校验当前用户角色。用普通prompt让AI审代码它看接口逻辑时通常会漏掉这种问题因为接口本身写得很正常没有明显的漏洞特征。后来我在access_control.md规则里明确写了一条对每个接口不仅要看它是否校验token存在还要看是否校验角色权限尤其注意前端隐藏入口但后端未鉴权的情况。加上这类具体指引之后再次审计同一段代码模型准确地指出了问题。认证这块有一个高频考点是会话固定和会话过期。编写auth.md时我建议这样约束模型检查登录成功后是否生成了新session检查session超时时间是否可配置检查退出登录时是否同时销毁了前后端会话凭证。别看这些点小真实项目里常年翻车。我见过一个内部系统session有效期设成了一周员工离职了账号还能用直到做权限复核才暴露。授权规则更复杂一点。我在文件里强调几个动作找到所有请求入口梳理每个接口需不需要区分用户检查资源ID是否直接暴露且没有归属校验。即使是这样模型也可能审得粗糙所以规则文件里我加了一个强制动作生成一个接口权限矩阵把每个接口和所需角色列出来。这样模型必须系统性地过一遍而不是挑顺眼的看。3.2 输入校验与注入类检查项的落地写法注入类问题是安全审计的重头戏但如果规则写不好模型会陷入两个极端要么只盯着字符串拼接SQL漏掉ORM误用和存储型XSS要么看什么都像注入误报率极高报告没法用。我编写injection.md文件时第一原则是让模型区分数据流和控制流。推荐给模型的指令是追踪用户输入从入口到落地的完整链路判断每个节点是否有不可绕过的校验。具体检查项包括SQL注入是否使用参数化查询字符串拼接点前后的过滤是否完备ORM框架是否存在动态拼接原生SQL的场景。命令注入是否有调用系统命令的代码参数是否来自用户输入有没有经过白名单校验。XSS输出到HTML、JS、URL上下文时是否有对应的转义处理富文本场景下是否做了标签白名单。路径穿越文件读写路径是否由用户输入拼接有没有做规范化处理。写这类检查规则时不要用抽象的“检查是否存在注入漏洞”这种话而要落到具体模式。比如对于命令注入规则可以写搜索exec、system、subprocess等关键字回溯参数来源再确认是否有shellTrue之类的危险配置。这样模型执行起来才有抓手。还有一条实操经验注入类检查必须要求模型给出数据流追踪过程。光给出结论不够得让它把输入怎么进来的、在哪拼接的、最终在哪触发一步步写出来。这个过程能显著降低误报率因为很多模型生成的“疑似注入”根本经不起数据流推演。3.3 数据泄露与日志脱敏容易被忽略的合规点前几年我做过一次比较完整的业务系统审计发现真正严重的不是SQL注入而是一堆日志把用户手机号和身份证号原样打出来了。那时系统还在开发阶段数据量不大但一旦上线日志汇总到分析平台这类问题就是数据合规事故。数据保护类的检查点平时大家嘴上都会提落成规则的时候就很容易一笔带过。我的data_protection.md里分了三块内容。第一块是日志脱敏。规则要求模型遍历所有日志输出语句识别其中是否包含个人信息字段比如手机号、邮箱、身份证号、银行卡号、家庭住址等。如果包含就必须标注脱敏缺失并给出脱敏函数的使用位置建议。这里需要注意脱敏策略不是简单地把字段全部置为星号好的做法是一对一业务场景讨论既保留部分信息供排查用又防止完整泄露。第二块是接口响应。很多后端接口会把数据库实体直接序列化返回包括密码哈希、内部备注等不该出去的字段。规则里我让模型检查序列化注解和返回对象的字段范围凡是出现密码、token、内部标记的一律记为高风险。第三块是前端存储。localStorage里放token很常见不致命但容易被XSS顺走。规则的要求是如果发现敏感凭证存到localStorage或sessionStorage记录下来并建议迁移到HttpOnly Cookie。3.4 配置文件与第三方依赖用白名单思维做检查配置和依赖检查是另一类高频问题。很多项目的安全审计报告里依赖漏洞占了大头但模型如果没有知识库支持很难知道某个版本到底有没有CVE。所以这块规则的正确设计思路不是让模型背诵漏洞库而是要求模型识别出危险配置模式和低版本依赖再结合已知CVE库做核实。config_and_dependency.md中强调的模式有管理端口暴露在公网或者绑定0.0.0.0且无访问控制。配置文件中硬编码了数据库密码、API密钥、私钥。框架默认调试模式开启导致堆栈信息直接回显到客户端。CORS配置为*且允许携带凭证等于给跨域请求开了大门。依赖锁定文件存在高危组件版本且没有更新记录。这类检查相对机械模型容易执行关键问题是要防止它把文件里的每处敏感字段都当成漏洞。比如本地开发配置里出现一串测试数据库密码不一定是上线时的风险。所以规则里我明确写了对配置文件做环境标识只有生产环境或没有环境区分的代码才需要进一步确认。这一条加进去之后报告的噪声明显下降了。4. 完整审计实操流程从接触目标到输出报告4.1 初始化与信息收集阶段调用skill之后第一步是让模型明确审计范围。这一步我觉得是整个流程里最容易被跳过的但也是最值得花时间的。如果目标不明确模型要么看到什么审什么要么一阵乱扫没有重点。我在SKILL.md中定义的信息收集命令大致是这样的/audit init --target path --type app|api|librarytarget是待审计项目路径type里的app表示完整Web应用api表示纯接口服务library表示代码库类。模型拿到这个指令后需要先做几件事确认目标目录结构找到入口文件和技术栈标志列出项目使用的框架和关键依赖识别是否包含前端、后端、配置文件生成一个审计计划清单。这个阶段的输出不需要很深但它决定了后面的检查节奏。比如目标是一个基于Flask写的API服务那么injection、auth这些规则权重高前端相关规则基本可以跳过。反过来如果是Vue项目重点就转向XSS和敏感信息泄露。实操中我遇到过几次模型跳过信息收集直接开跑的情况原因是目标目录里代码量少模型觉得自己一两眼就能看完。但即使项目小信息收集也有价值它为后面的报告提供了技术栈上下文还让模型在报告里能准确标记影响范围。所以规则里我写了硬性要求无论项目规模大小审计计划必须先生成。4.2 静态扫描阶段信息收集完成之后模型按规则目录逐项加载检查文件并执行。这里SCAN的顺序是经过设计的先看注入和配置类再看认证授权最后查数据保护。这个顺序背后有一个原则就是把容易出确定性结论的检查放在前面把依赖业务理解和场景判断的放在后面。这样即使项目复杂度高、上下文不够用前面的高置信度结论也已经沉淀在结果里。每个检查文件内部我也固定了执行方式。以injection.md为例执行流程是定位所有用户输入入口请求参数、请求体、HTTP头、文件上传名、环境变量。追踪每条输入数据的流向标记所有经过的赋值和变换。在所有危险函数调用点检查参数是否直接或间接来自用户输入。对可疑点记录数据流不马上定级留到验证阶段。这个阶段模型最怕“直奔结论”。如果你直接问它这个项目有没有漏洞它可能会秒回“有SQL注入”但没有证据链。所以规则里我特意要求每个发现必须挂载证据文件路径、关键代码行、数据流描述。宁可漏掉一些无法确认的也不能让模型编造。这一条在报告质量上好处非常明显。4.3 动态验证与业务逻辑判断静态扫描只能提供候选问题真正定级时需要验证。安全审计skill里的验证阶段不是让你真的去攻击系统而是让模型结合上下文做交叉检查。举一个实际案例。有一回审计一个订单导出接口静态扫描发现接口接收dateRange参数后直接拼进了SQL查询。按规则这是一个高危SQL注入候选。但进入验证阶段模型追踪了参数来源发现接口前面有个白名单中间件只允许日期格式且框架层做了参数化查询。这样一来这个候选就被降级为“低风险配置建议”。这个环节做得好的话报告就不会变成单纯的漏洞清单而是有判断力的分析文档。规则里我明确要求模型区分可确定的、可能但不确定的、建议人工复查的三类结果分类标识清楚。动态验证还需要关注业务逻辑漏洞这类问题最依赖经验。比如支付流程中订单金额是否可被篡改、优惠券是否可重复使用、商品库存是否超卖。这些代码逻辑往往不是“标准漏洞”但造成的业务风险很高。我在规则里没有展开做因为业务逻辑因系统而异我更倾向于让模型在报告里单独开一个“业务逻辑观察项”板块把自己觉得可疑的流程描述出来由人工复核。4.4 报告输出与风险定级报告是我写这套skill时反复打磨的部分。审计做得再好输出不清晰价值就少了一半。我遇到过很多工具生成的报告动辄几十页真正有用就两页大部分是自动扫描器的机器结果没有优先级。report_template.md里规定的结构是审计概览目标、范围、审计时间、技术栈说明、总体风险评级。高危问题风险等级、影响位置、触发条件、证据、修复建议。中低危问题问题描述、建议处理时间窗口。业务逻辑观察项值得人工关注的场景。复测清单下次审计时需要重点确认的点。风险定级规则我也写得很细。高危的定义是可直接导致数据泄露、提权、远程执行且无前置条件或前置条件极低。中危包括需要特殊条件才能触发、影响有限但不符合安全基线。低危包括配置建议、加固建议、代码风格类问题。这里特别注意提醒模型不要“高帽式定级”它一旦发现一个SQL注入就给整个系统挂高危这不合理。正确做法是先确认触发条件再定等级。5. 实战中常见的坑与排查技巧5.1 误报、漏报和“模型幻觉”问题汇总用AI做安全审计最大的坑不是模型不够强而是它看起来太强。它给出的结论往往语气笃定但证据可能是编的。我整理过一份问题速查表按频率从高到低排问题类型典型表现排查思路证据幻觉报告中代码路径不存在强制规则要求所有证据可点击找不到就标记为未验证定级虚高普通配置问题标为高危加粗提示“级别必须与触发条件强关联”漏检严重大项目只查出2个问题让模型输出检查覆盖矩阵确认哪些文件没看业务逻辑薄弱只看标准漏洞不看业务风险在规则中增加“业务逻辑观察项”独立段落上下文漂移长会话后前后口径不一致每个检查阶段让模型先复述本阶段目标再行动针对证据幻觉我在设计skill时做了一个硬性设置报告中所有问题必须标注证据来源而且强调拿不准就写“待确认”不允许猜测。这个约束一开始会让报告显得保守但长期使用后模型的准确率比“自信模式”高得多。审计这件事真实可靠永远排在效率前面。漏检的处理方式对实战很关键。如果你发现一个大项目只查出两三个问题大概率不是项目真的安全而是模型漏审了。排查方式可以是问模型一句“你检查了哪些文件哪些文件被跳过了”很多情况下模型会因为上下文窗口不足而跳过后半部分文件这个问题只能通过缩小审计范围解决。所以我现在用这个skill时规定单次审计的理想代码量在2000行以内超过就分批跑最后人工合并报告。5.2 Skill本身维护时容易踩的坑规则文件不是写一次就完了项目用久了会有几个反复出现的问题。一个是规则过细导致模型绕圈子。早期我把每个安全域的规则写得很长动不动一千多字结果模型每次都要读完才能开始干活。检查项之间还有相互冲突的指令模型执行时经常卡壳。后来我精简了规则每个文件控制在500字以内每条规则都以“动作对象输出”的方式描述模型执行效率明显提升。另一个是缺少回归测试。改了规则之后旧项目审计结果有没有变差没有可观测手段。后来我准备了一组固定的小样本测试项目每个项目故意埋了几个典型漏洞。每次修改skill配置后先跑一遍测试集对比输出是否达标。这个方法成本很低但能把改动带来的副作用在有效范围内。推荐的做法是给每个规则文件末尾加一段“本规则适用场景”和“本规则不适用场景”的说明。比如说auth.md适用于有登录系统的Web应用但对于没有用户体系的工具类应用可以不加载。这样能让模型在信息收集后快速决定要加载哪些规则减少无谓的上下文消耗。5.3 快速上手现有Skill的复用与微调建议如果你想直接试做一套安全审计skill不建议从零硬写。GitHub上有不少现成的安全技能库和预置规则文件基础框架可以拿来就用但建议先看三处主流程文件有没有阶段划分规则文件是抽象描述还是具体动作指令报告模板是否要求证据标注。这三处过关再针对自己的项目微调。我自己常用的包装方式是做一个“入口脚本”概念让skill支持 /audit init 这样的命令式交互模型根据命令参数自动走完信息收集、规则加载、静态扫描、报告输出四个阶段。这样团队成员不需要了解skill内部细节只需知道怎么发起命令就能得到结构化的审计结果。把个人能力沉淀成团队的标准化流程这才是skill真正有杠杆的地方。写在最后做安全审计skill这半年我最大的体会是它看起来是在教AI怎么做审计实际上是在逼自己把脑子里的模糊经验写清楚。每天挂在嘴上说“注意脱敏”“要检查越权”和把它们落成一条条可执行的规则是完全两码事。如果你也打算做一套建议从一个最常做的项目类型开始把日常重复的那些检查内容慢慢拆成规则文件别一上来就想覆盖所有场景。后面用起来了再根据实际报告质量迭代。审计这条路没有终点但每多沉淀一条规则下一次就会轻松一分。