真正意识到“安全审计”必须当作一门技能来打磨是我第一次独立负责一个业务系统的上线前评估。当时我手里的工具很全但整个流程跑得七零八落一会儿拿着扫描器全站扫一会儿翻代码找硬编码密钥一会儿又去改 Nginx 配置最后写报告的时候发现遗漏了好几项关键风险。那次项目复盘让我明白一件事——安全审计不是“拿着工具跑一遍”的动作而是一套可以拆解、可以沉淀、可以被复用的知识体系。现在这个知识体系正好赶上了大模型时代真的可以把它打包成“技能Skill”让 AI 在合规授权的前提下帮你分担重复劳动。这篇文章就把我这几年的安全审计实操经验加上最近半年在 AI Skill 上的落地实践一起梳理出来。内容覆盖核心审计工具Fortify、Spring Security 配置核查、Windows Security 基线、Security Onion、Kali Linux 在授权测试中的定位、审计技能的分层设计以及如何把审计检查清单封装成可复用的 AI Skill 工作流。无论你是刚入行的安全工程师还是负责业务系统保障的开发和运维同学都能从中找到可以直接抄作业的部分。1. 安全审计技能这件事先从一次“翻车”说起那次“翻车”其实不是技术问题而是没有把安全审计当成一个系统工程来做。我接手的是一个 Java 微服务项目接口几百个服务依赖十几个。最开始我按照惯例先跑了一遍依赖漏洞扫描然后去翻代码里常见的注入问题最后测了几个管理后台的登录接口。折腾了两天看起来覆盖很全面但验收方问我三个问题时我愣住了数据库账号权限有没有按最小化分配日志是否记录了完整的审计事件第三方回调接口的验签逻辑校验的是哪一层前两个我完全没查第三个我答错了。安全审计最忌“按自己熟悉的顺序随便查”它需要一套覆盖资产、配置、代码、运行状态的完整检查逻辑。1.1 安全审计到底在审什么安全审计和渗透测试的定位不同。渗透测试的核心目标是“能不能打进来”安全审计的核心目标是“当前系统的安全状态是否符合预期”。所以审计的对象是一组更宽泛的东西资产清单有哪些主机、服务、API、数据存储、第三方组件是否都纳入了台账。配置基线系统配置、中间件配置、框架安全配置、账号权限策略是否符合最小权限和默认安全原则。代码质量源码中是否存在注入、越权、硬编码凭据、不安全反序列化等典型缺陷。运行状态日志是否完整、告警是否有效、流量是否被监控、补丁是否及时更新。这四个层面缺一不可。很多团队审计时会过度关注“代码漏洞扫描”把其他三项弱化了。实际上配置基线问题和资产台账问题在真实事故中占比更高而且它们更隐蔽——代码漏洞可以用扫描器快速定位但一个多年未清理的高权限账号往往要翻遍所有服务器的用户列表才能发现。1.2 为什么审计经验必须技能化传统安全审计高度依赖个人经验。同样一个系统资深审计师和新手看出来的问题数量可以相差一个量级。原因在于资深审计师脑子里有一套完整的“检查逻辑”他看到某个接口会下意识想这个接口有没有鉴权看到某个数据表会想这条数据链路在传输和存储过程中是否有加密看到某个第三方依赖会想它是否在主版本更新中悄悄改变了默认行为。这些逻辑并不是天生的而是一次次踩坑、一个个 CVE 公告、一页页官方文档积累出来的。但这些经验一旦只存在个人脑子里就会变成企业的脆弱点。人员流动、项目交接、经验断层每一个都是安全审计质量的大敌。所以过去几年我一直在做一件事把审计步骤、检查项、风险评级标准、修复建议整理成结构化文档让团队里每个人都能按同一套标准去执行。这其实就是“技能化”的雏形——把隐性的个人经验变成显性的可复用资产。到了大模型时代“技能化”有了新的含义。像 Claude 的 Skill、Codex 的 Skill、OpenCode 的 Skill 这类机制本质上就是让 AI 按一套预设的指令、知识、模板去执行特定任务。安全审计的检查清单、漏洞评级标准、报告模板几乎可以原样注入到 Skill 的配置里。这意味着 AI 能在授权前提下帮你完成信息收集、基线比对、风险汇总这些重复度高、规则明确的工作而人可以把精力集中在需要判断力的部分。1.3 一套可复用的安全审计技能分层模型我目前使用的安全审计技能体系分成四层。底层是通用知识包括网络协议、操作系统、数据库、编程语言的基础原理第二层是工具能力熟悉 Fortify、Kali 工具套件、Security Onion、Nuclei、Trivy、Semgrep 这些具体工具第三层是场景实践也就是知道在代码审计、配置审计、基础设施审计、应急排查等不同场景下该用哪些工具、先查什么后查什么最高层是自动化与 AI 辅助把前三层的经验抽成检查清单封装成 Skill 或自动化脚本让标准化的部分自动跑。举个例子底层通用知识告诉你“反序列化漏洞的原理是 Java 在还原对象时可能执行了危险方法”工具能力层你会用 Fortify 或 Semgrep 扫描序列化入口场景实践层你会重点排查继承了 Serializable 的类以及是否有未经过滤的 readObject 调用。到了自动化层你可以把“是否存在不安全反序列化”写成一条检查规则放进审计 Skill 的检查清单里AI 拿到代码仓库后自动定位可疑点并生成初步风险说明。四层能力的核心逻辑是知识支撑判断工具提升效率场景决定优先级自动化放大产能。2. 核心审计场景的工具体系与选型思路工具选型是安全审计里最容易让人纠结的环节。市面上的工具五花八门静态扫描、动态扫描、依赖分析、容器扫描、流量监控每个类别都有好几个代表选手。但我的建议一直很简单不要追求工具数量要把“能覆盖审计四层目标”的最小工具集用透。我自己的工具集长这样代码层用 Fortify SCA 加 Semgrep依赖层用 Trivy 加 OWASP Dependency-Check配置层靠人工核查加 Spring Security/Docker Bench 等专项基线基础设施层用 Security Onion 做流量监控和告警研判Kali Linux 作为授权测试环境里的验证工具箱。每个工具负责一条链路交叉验证相互补位。2.1 代码审计Fortify SCA 和人工审计怎么配合Fortify SCAStatic Code Analyzer是我做 Java 代码审计时的主力工具之一。它在业内深耕多年对 OWASP Top 10 里的常见漏洞覆盖很全尤其是注入类、XSS、不安全反序列化、硬编码凭据这些典型问题检测规则成熟误报率相对可控。Fortify SCA 的典型流程是先用 SCA 扫描源码生成 FPR 结果文件再用 Audit Workbench 打开结果做人工审计最后用 Fortify 的软件安全中心SSC做漏洞管理和报告输出。但 Fortify 不是万能的。静态分析的本质是基于规则做模式匹配它抓不到业务逻辑层的漏洞比如越权——两个接口看起来代码结构一模一样但一个用了当前用户 ID另一个直接用了参数里的用户 ID这种差异只有人工审计才能发现。所以我的做法是“扫描器快速铺底人工审计做深度确认”。Fortify 扫出来的高危项我通常不会直接信而是去定位实际代码结合数据流、入口参数、权限控制逻辑综合判断是否真的可利用。很多新手拿到 Fortify 报告就开始填漏洞数量这是最危险的做法——工具报告里的“高危”只是候选风险必须经过可用性验证才能定级。还有一点要注意Fortify SCA 是有许可证机制的。装完环境后审计工作台可能会出现“许可证过期”之类的报错这个后面专门讲排查方法。出现这类问题别慌无非是许可证文件路径、时间同步、环境变量这几类原因。2.2 配置基线审计以 Spring Security 配置迁移为例配置基线审计常常被忽略但影响面往往比单点代码漏洞更大。拿 Java Web 项目来说Spring Security 是整个应用安全模型的基石如果它的配置出现疏漏所有接口的鉴权逻辑都可能被绕过。我最近两年遇到的高频场景是 Spring Boot 3 升级时 Spring Security 配置的迁移因为 Spring Security 6 里很多东西变了。Spring Boot 3 使用的 Spring Security 6 和 5 相比主要有几个关键变化WebSecurityConfigurerAdapter 被移除了原来的继承写法要改成基于 SecurityFilterChain Bean 的声明式配置authorizeRequests 方法改成了 authorizeHttpRequests而且默认的请求匹配逻辑也变了方法级别的安全注解PreAuthorize 等需要在配置里显式启用自定义登录逻辑的配置方式也做了重构。我踩过的坑是升级到 Spring Boot 3 后服务能正常启动但所有接口都变成了匿名可访问。原因就是原来的自定义 SecurityConfig 继承了 WebSecurityConfigurerAdapter升级后这个类被移除旧配置失效但没有报错系统走了没有任何鉴权规则的默认配置。所以审计这类项目时我要做的第一件事就是确认 SecurityFilterChain 是否正确注册然后逐个接口验证哪些需要认证哪些角色可访问路径匹配规则是否有覆盖遗漏CSRF、CORS、会话管理是否按预期配置。建议把 Spring Security 配置审计的检查项固化成清单过滤器顺序、permitAll 路径、方法安全开关、密码加密方式、会话固定保护、跨域策略缺一不可。2.3 主机与终端安全基线Windows Security 那些细节Windows 主机的安全基线审计在很多公司被当成“装个杀毒软件就行”这是误区。微软自己的 Windows SecurityWindows 安全中心其实是一个聚合面板它管理着病毒和威胁防护、账户保护、防火墙和网络保护、应用和浏览器控制、设备安全性、设备性能和运行状况、家庭选项这几个模块。审计时不能只看一眼“绿色对勾”就完了要逐项核查策略是否真正生效。我遇到过一个很典型的情况Windows 安全中心显示“病毒和威胁防护”正常但实际上实时保护被组策略关闭了。原因是有个第三方安全软件接管了系统防护后Windows Security 变成了影子状态界面上看不出来。所以审计 Windows 主机时我一般会结合 PowerShell 命令和注册表项做双重确认而不是单纯看界面状态。还有一个小坑是 Win10 在特定版本更新后 Windows Security 界面可能变成英文或者设置中文后仍然显示英文本质上是系统语言包和区域设置没有同步处理方案放到后面排查章节说。基线审计类的检查项很适合做成表格比如“Windows 安全中心状态、实时保护、云提供的保护、提交样本、防火墙策略、账户控制 UAC、BitLocker 状态”这些字段逐台主机打分汇总成矩阵一眼就能看出哪台机器在裸奔。2.4 基础设施安全监控Security Onion 和 Kali 在授权审计里的位置基础设施审计的核心目标有两块一是确认安全监控覆盖到位、告警有效二是验证自身防御能力在可控环境中找到薄弱点。前者我常用 Security Onion后者离不开 Kali Linux但两者的使用边界完全不同。Security Onion 是一套开源的网络安全监控NSM平台集成了 Suricata入侵检测、Zeek元数据提取、Elasticsearch日志存储和分析、Kibana可视化、TheHive案件管理等一揽子组件。它特别适合在中型网络里做流量分析和安全事件响应。Security Onion 3.x 支持单机部署对硬件要求不算离谱我测试时用的是 8 核 CPU、16GB 内存、500GB 存储的机器跑测试流量没有问题。部署过程中最容易出问题的环节是网络接口绑定和 Elasticsearch 的内存配置后面排查章节会展开。Kali Linux 在安全审计里的角色我更愿意把它定义为“验证工具集”而不是“渗透工具集”。在获得充分授权的前提下审计师可以用它来验证某项风险是否真的可利用比如自己写一段测试代码去确认反序列化点是否可以触发或者用 Nmap 做一次端口扫描确认资产暴露面。但必须强调两条红线第一测试范围必须严格限定在与客户约定好的目标资产上第二测试动作应当以“验证风险”为边界不做破坏性、横向扩散性操作。安全审计的本质是帮助企业把防线补牢而不是展示攻击技巧。3. 把审计经验沉淀成 AI Skill 的实操方法最近半年 AI 圈最热的概念之一就是“Skill”。Claude 有 SkillCodex 有 SkillOpenCode 也有 Skill各种 AI 编程助手都可以通过加载 Skill 来获得特定领域的专业能力。很多做业务开发的同事问我这东西到底是啥我用一句话解释Skill 就是把完成某一类任务所需要的说明文档、检查清单、示例模板、约束规则打包成一个文件夹AI 在运行时加载这个文件夹按里面写的逻辑去干活。本质上和给实习生一本操作手册让他照做是一个道理。而安全审计这个场景天然适合做成 Skill。因为审计流程高度结构化——有明确的输入代码仓库、配置信息、资产清单、明确的过程检查清单逐项核查、明确的输出风险报告、修复建议。这些正是 Skill 最擅长的东西。3.1 先搞清楚 AI Skill 和安全审计的关系要理解 AI Skill 对安全审计的价值先要对比一下“直接用 AI 问安全问题和挂了 Skill 再用 AI”的区别。不挂 Skill 的通用 AI你问它“帮我看一下这段代码有没有 SQL 注入”它能基于训练知识给出一些判断但它不知道您的项目的审计基线是什么不知道您们公司对高危漏洞的定级标准也不知道报告应该用哪个模板。它回答得很“通用”但审计交付需要的是“特定于本项目”的结论。挂了 Skill 之后AI 在回答前会先读取 Skill 文件夹里的规则。比如我自建的安全审计 Skill 里写明了“对 Java 项目先检查 pom.xml 中的依赖版本对照已知 CVE 列表再检查 controller 层是否有统一的鉴权逻辑对 SQL 语句必须追踪参数传入链路标记拼接字符串为高危风险。”AI 按这套规则执行后输出的结果就是贴着咱们项目实际情况的可以直接放进审计报告里。这个差别有点像用通用搜索还是用行业垂直数据库搜索。通用 AI 是一个什么都懂一点的通才Skill 则是给它装了一套行业专家的外挂。3.2 一个审计 Skill 的完整设计流程创建一个安全审计 Skill我总结出五个步骤定义目标、准备知识、撰写指令、搭建模板、测试迭代。第一步定义目标要回答清楚“这个 Skill 在什么场景下被调用”。我一般把审计目标拆得很细比如“Spring Boot 项目代码审计”“Linux 主机基线审计”“Spring Security 配置核查”一个 Skill 只干一件事不要做“万能审计”否则指令会互相冲突AI 输出的稳定性也会变差。第二步准备知识把审计需要的参考素材放进去。包括项目常用的技术栈清单、公司内部的漏洞定级标准、OWASP Top 10 描述、常见漏洞的核查范例。这些知识会被 AI 在推理时引用。第三步撰写指令这是整个 Skill 的灵魂。指令要写清楚 AI 的执行逻辑先做什么再做什么每步使用什么工具满足什么条件时判定为高风险哪些情况下必须向用户确认而不是自行判断。第四步搭建模板定义输出格式。比如代码审计报告必须包含项目概述、扫描范围、风险总览、漏洞明细、修复建议、复测记录。模板的价值在于让 AI 每次输出的结构一致项目组、客户、上级看起来都舒服。第五步测试迭代用真实项目样本去跑看输出结果是否符合预期。我自己的经验是第一版 Skill 跑出来的报告总是会多多少少有些“AI 味”比如风险和修复建议写得过于笼统。这时候就逐个反馈调整把模糊之处在指令里写得再清楚些两三轮之后质量会稳定很多。3.3 从零搭一个代码审计 Skill逐步实操下面用一个具体的例子演示搭建过程。假设我要做一个“Java 代码审计 Skill”它需要完成依赖风险检查、常见Web漏洞代码定位、风险汇总报告生成。第一步创建 Skill 目录结构。我的习惯是java-security-audit-skill/ SKILL.md references/ cve-checklist.md vuln-patterns.md severity-standard.md templates/ audit-report.mdSKILL.md 是这个 Skill 的主入口Claude、Codex 这类工具在加载 Skill 时会优先读取这个文件。references 目录放 AI 推理时参考的知识文档templates 目录放报告输出模板。第二步在 SKILL.md 里写清楚任务描述和执行流程。核心内容大致长这样先检测项目构建文件pom.xml、build.gradle拉取依赖清单逐一比对已知高危 CVE然后扫描源码中的典型漏洞模式最后按报告模板输出结果。关键约束要写明白只做静态分析不做实际漏洞利用对模糊结论必须标注“需要人工复核”不能给出确定性的虚假定论。第三步在 references 目录里放具体的检查规则。比如“SQL 注入核查要点”可以写成在 Mapper 或 Repository 层查找select * from where等拼接 SQL 的写法。如果 SQL 通过拼接字符串且参数来自前端直接标记为高风险必须使用预编译参数化查询。如果使用了 MyBatis检查${}动态参数的用法出现${}且无法确认参数来源可信时标记为高风险。第四步设计报告模板。审计报告的字段包括项目名称、审计时间、审计范围、风险统计高/中/低、漏洞列表位置、类型、风险等级、问题描述、修复建议、人工复核意见。把这个模板放进 templates/audit-report.mdAI 在最终汇总时会严格按照这个结构输出。搭好之后我会用两到三个真实项目做测试。第一轮通常会暴露一个问题AI 在解读 CVE 时会过度报告把低版本依赖的所有已知漏洞全部列出来忽略了实际利用条件。对策是在指令里加上“对每个漏洞必须结合该组件在实际代码中的使用位置判断可利用性不能仅根据版本号机械判定”。这条约束加上去之后报告质量明显提升。3.4 用多个 Skill 编排出一条审计流水线单个 Skill 解决单点任务但完整的审计流程需要多个 Skill 协同。我在实际项目中的做法是建立一套 Skill 组合信息收集 Skill读取项目资产清单、配置文件、拓扑图生成审计范围概览。代码审计 Skill按技术栈扫描源码中的安全问题。配置审计 Skill检查 Spring Security、数据库权限、中间件配置等基线项。报告生成 Skill把前面几个 Skill 的结果进行汇总、去重、关联生成最终报告。这套组合背后的逻辑是前一个 Skill 的输出作为后一个 Skill 的输入。信息收集 Skill 生成的“审计范围概览”直接喂给代码审计 Skill代码审计 Skill 生成的漏洞列表直接交给报告生成 Skill。这样流水线跑下来我作为一名审计工程师只需要在每个环节之间做一些关键决策和抽查比如确认某条漏洞是否真的存在、某个风险评级的定级是否合理。需要注意的是Skill 编排目前在不同工具里的实现方式不一样。Claude Code 里可以直接引用多个 Skill 目录Codex 里通过 AGENTS.md 和自定义指令加载OpenCode 也有自己的配置方式。不要被具体的实现细节困住核心思路是相通的把一份工作拆成多个独立任务每个任务由一个 Skill 负责任务之间用标准化的数据结构传递信息。4. 常见问题与排查技巧实录工具用得越多踩过的坑就越有参考价值。下面这些问题是安全审计项目里高频出现的我把排查思路和解决方法整理出来方便直接查阅。问题现象可能原因排查与处理建议Fortify SCA 打开 Audit Workbench 报许可证过期许可证文件路径错误、系统时间与许可证有效期不一致、license 环境变量未配置检查环境变量 FORTIFY_LICENSE 指向的 license 文件是否存在确认系统时间与 NTP 同步重新申请并部署许可证文件Windows 安全中心变成英文系统语言包不完整、区域设置未同步、更新后语言资源未加载进入“设置 时间和语言”确认显示语言已设为中文运行lpksetup重新安装语言包必要时重启系统Windows 安全中心部分功能显示灰色不可操作第三方安全软件接管了防护模块或组策略禁用了相关项用gpedit.msc检查“Windows 组件 Windows 安全中心”相关策略确认第三方安全软件的接管状态Spring Boot 3 升级后接口全部匿名可访问旧配置依赖 WebSecurityConfigurerAdapter升级后失效且没有新的 SecurityFilterChain改用 SecurityFilterChain Bean 声明式配置添加EnableMethodSecurity启用方法级鉴权检查 permitAll 路径是否意外覆盖了受保护接口Security Onion 3.2 单机部署后 Elasticsearch 频繁 OOMJVM 堆内存配置与物理内存不匹配调整 Elasticsearch JVM 堆为物理内存的一半但不超过 31GB检查索引分片数关闭不必要的采集模块自动化审计脚本提示“please complete the security check and try again”目标系统启用了反自动化的安全验证如验证码、行为校验降低请求频率使用目标系统允许的官方 API 替代页面采集对受限功能做好日志记录并说明为何跳过4.1 Fortify SCA 打开 Audit Workbench 报许可证过期怎么办这个报错几乎每个刚接触 Fortify 的团队都会遇到。大多数人第一反应是“许可证真的过期了”但实际很多时候是因为许可证文件没被正确加载。Fortify 的许可证验证链路是SCA 安装目录下的bin/fortify-license命令用来查看和安装许可证通过环境变量 FORTIFY_LICENSE 指定许可证文件路径。如果环境变量没配或者路径指向了一个旧的 license 文件就会报“许可证过期”。排查路径我一般这样做先运行fortify-license -status查看当前许可证状态和过期时间确认是不是真过期如果显示正常但仍然报错检查环境变量是否指向了正确路径同时确认扫码过程中使用的机器时间与 NTP 时间一致。Fortify 的许可证对系统时间很敏感虚拟机环境如果挂了快照、休眠恢复后时间漂移也会触发这类报错。这些操作背后其实是“先确认事实再动手修复”的思路能避免很多无效操作。4.2 Windows 安全中心变成英文、设置不了中文怎么处理Windows 安全中心界面语言跟随系统显示语言但偶尔会出现系统显示语言是中文、安全中心仍然是英文的情况。我排查过多次本质原因基本是系统在版本更新后语言资源包没有完整加载或者 Microsoft Defender 相关的组件仍在使用旧的语言标识。处理办法比较简单先到“设置 时间和语言 语言”确认“Windows 显示语言”下拉框确实选择了“中文”然后以管理员身份打开 PowerShell运行Get-WinUserLanguageList检查语言列表顺序如果列表中不存在中文用Set-WinUserLanguageList zh-CN添加。做完之后重启系统绝大多数情况下界面就变回中文了。如果仍然不行可以尝试运行 Windows Update将 Defender 平台更新到最新——这类界面语言问题经常随着安全智能更新一起修复。4.3 Spring Boot 3 中 Spring Security 配置迁移踩坑这个坑我在 2.2 节里提到了这里补充一个更隐蔽的场景项目升级到 Spring Boot 3 后启动没有任何报错登录功能还正常但某个管理接口在未登录状态下也能直接访问。排查后发现旧代码里用了antMatchers(/admin/**).hasRole(ADMIN)这个 API 在 Spring Security 6 里已经被移除代码在编译阶段应该报错但因为项目中混合了新旧配置某些旧配置被静默忽略导致部分路径没有走新的鉴权规则。审计这类项目时不要只盯着启动日志要实际跑一遍接口访问控制矩阵。把项目所有 controller 的路径收集起来分角色逐一测试访问结果再和预期鉴权逻辑做对比。这个过程很适合交给 AI Skill 辅助让 AI 读取全部 controller 代码自动生成路径清单和当前鉴权注解标注然后由审计人员去判断是否存在配置盲区。4.4 自动化审计脚本遇到安全验证拦截怎么处理做安全审计的人多少会碰过这类提示“please complete the security check and try again”。这通常是目标系统为了保护自身资源在发现可疑高频请求后弹出的人机验证。我在编写自动化审计或信息收集脚本时就撞上过当时是写了一个批量检查登录页面响应状态的小脚本请求频率控制得不够细触发了几十个 IP 维度的拦截策略。这个问题要从两个层面看一是技术层面脚本要控制并发和请求频率模拟正常浏览器行为设置合理的 User-Agent最重要的还是要通过目标系统提供的官方接口去获取信息而不是在页面层面做逆向抓取。二是合规层面审计脚本在触发拦截之后要及时停止该方向的测试动作做好记录并和相关方沟通是否需要调整审计方式。安全审计的前提永远是授权和适度宁可不测也不要因为脚本行为影响业务可用性。希望大家在实际操作中守住这条底线。尾巴做安全审计这些年我最大的体会是真正拉开差距的不是你手里有多少工具而是你是否能把知道的东西变成一套可重复执行的方法并且把它写得让第二个人也能接手、让机器也能执行。把审计经验沉淀成 Skill 这件事本质上就是在给整个团队补“组织级经验”的课。我建议你从最小的场景开始试比如先做一个“Spring 配置文件安全核查”的 Skill用一两个真实项目跑通再慢慢扩充成完整的审计流水线。这个过程踩的坑比看一百篇教程都有价值。