从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.md

SKILL.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等关键字，回溯参数来源，再确认是否有shell=True之类的危险配置。这样模型执行起来才有抓手。

还有一条实操经验：注入类检查必须要求模型给出数据流追踪过程。光给出结论不够，得让它把输入怎么进来的、在哪拼接的、最终在哪触发，一步步写出来。这个过程能显著降低误报率，因为很多模型生成的“疑似注入”根本经不起数据流推演。

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|library>

target是待审计项目路径，type里的app表示完整Web应用，api表示纯接口服务，library表示代码库类。模型拿到这个指令后，需要先做几件事：确认目标目录结构，找到入口文件和技术栈标志；列出项目使用的框架和关键依赖；识别是否包含前端、后端、配置文件；生成一个审计计划清单。

这个阶段的输出不需要很深，但它决定了后面的检查节奏。比如目标是一个基于Flask写的API服务，那么injection、auth这些规则权重高，前端相关规则基本可以跳过。反过来如果是Vue项目，重点就转向XSS和敏感信息泄露。

实操中我遇到过几次模型跳过信息收集直接开跑的情况，原因是目标目录里代码量少，模型觉得自己一两眼就能看完。但即使项目小，信息收集也有价值：它为后面的报告提供了技术栈上下文，还让模型在报告里能准确标记影响范围。所以规则里我写了硬性要求：无论项目规模大小，审计计划必须先生成。

4.2 静态扫描阶段

信息收集完成之后，模型按规则目录逐项加载检查文件并执行。这里SCAN的顺序是经过设计的：先看注入和配置类，再看认证授权，最后查数据保护。这个顺序背后有一个原则，就是把容易出确定性结论的检查放在前面，把依赖业务理解和场景判断的放在后面。这样即使项目复杂度高、上下文不够用，前面的高置信度结论也已经沉淀在结果里。

每个检查文件内部我也固定了执行方式。以injection.md为例，执行流程是：

1. 定位所有用户输入入口：请求参数、请求体、HTTP头、文件上传名、环境变量。
2. 追踪每条输入数据的流向，标记所有经过的赋值和变换。
3. 在所有危险函数调用点检查参数是否直接或间接来自用户输入。
4. 对可疑点记录数据流，不马上定级，留到验证阶段。

这个阶段模型最怕“直奔结论”。如果你直接问它这个项目有没有漏洞，它可能会秒回“有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怎么做审计，实际上是在逼自己把脑子里的模糊经验写清楚。每天挂在嘴上说“注意脱敏”“要检查越权”，和把它们落成一条条可执行的规则，是完全两码事。如果你也打算做一套，建议从一个最常做的项目类型开始，把日常重复的那些检查内容慢慢拆成规则文件，别一上来就想覆盖所有场景。后面用起来了，再根据实际报告质量迭代。审计这条路没有终点，但每多沉淀一条规则，下一次就会轻松一分。