年前我把手头几个安全审计项目的流程重新捋了一遍最后统一整理成一个技能包名字就叫security-audit-skill。起这个名字不是赶时髦而是因为我发现大多数团队做安全审计问题不在不会用工具而在于整套审计流程太依赖个人经验。换个人接手往往又从头开始踩坑。我想做的是把安全审计这摊事拆成可复用、可交底、能被AI辅助执行的一组技能知道审什么、怎么验、怎么留证据、怎么让报告有人看。这个技能包最后沉淀下来覆盖了四块代码审计、配置基线审计、流量与威胁检测、审计报告与整改推动。日常工作中我主要用它做三件事评估一个Web系统上线前的安全状态、排查已上线系统的配置弱项、以及在被入侵或出现异常告警时做定向调查。这篇文章就把这套方法和踩过的坑完整写出来适合刚入门的安全工程师、负责系统运维的同学以及想用AI辅助做代码安全审查的开发者参考。1. 先把“安全审计”拆成技能清单到底在审什么1.1 别再只盯着漏洞扫描审计的四个层次很多人一听到安全审计第一反应是拿扫描器跑一遍。实际上漏洞扫描只是整个审计链路里非常靠后的一环。真正有效的安全审计至少要覆盖四个层次。第一层是资产与攻击面。你得先知道系统有哪些入口对外开放的域名、IP、端口、API接口、第三方回调地址、管理后台地址。一个系统如果连资产清单都不完整后面所有扫描都等于盲人摸象。我见过不少审计项目扫描器跑得很欢结果业务方一问这个测试域名已经下线半年了你才发现一大半扫描目标根本不在当前资产范围里。第二层是配置与基线。操作系统、中间件、数据库、容器平台都有自己的安全基线。Windows有本地安全策略和审计策略注册表里HKEY_LOCAL_MACHINE\SECURITY\Policy\Accounts存储了账户策略相关信息Linux常用SELinux、AppArmor这类Linux Security Modules做强制访问控制。这些配置层面的问题往往比一个代码漏洞影响面更大因为它是全局性的。第三层是代码与依赖。静态代码审计工具如Fortify SCA可以帮我们快速定位SQL注入、XSS、反序列化、越权等问题另外一个经常被忽略的点是第三方依赖库的已知漏洞。我在审计时发现过不少项目用了EOL停止维护版本的框架或组件这种问题靠扫描器不一定能发现需要结合依赖清单和公开漏洞库做交叉比对。第四层是流量与行为。线上系统出问题往往不是靠代码审计能看出来的。异常登录、横向移动、数据批量导出、夜间大量请求这些行为特征需要在网络流量和主机日志里去找。Security Onion这类平台就是干这个的把网络流量、IDS告警、主机日志集中在一起做分析。四层都覆盖到了才算是一个完整的安全审计而不是一次漏洞探测器运行报告。1.2 审计技能的核心链路从信息收集到证据留痕我的安全审计流程一般分成六步范围定义、资产盘点、威胁建模、检查与测试、验证分析、报告与整改。每一步都有明确的产出物不然审计做着做着就容易跑偏。范围定义要和业务方、开发负责人一起确认明确哪些系统在范围内、哪些是生产环境、哪些只允许只读检查。资产盘点要形成一份资产清单包括主机、域名、端口、应用路径、负责人。威胁建模是结合业务判断如果被攻击最可能的路径是什么比如一个电商系统从登录到下单到支付每一步都可能被针对。检查与测试阶段我会把自动化工具输出和人工复核结合。自动化工具负责广撒网人工负责对高危项逐条验证。验证分析是最容易翻车的一步——工具报的高危未必是真漏洞可能是业务固有逻辑。所以审计技能里最重要的一环是去伪存真每条结论都要能给出证据链请求包、日志片段、代码行号、配置项位置。最后是报告与整改。报告不是给安全部门自己看的而是要推动业务方动手修复的。没有证据链、没有修复建议、没有优先级排序的报告基本等于白写。1.3 不同场景下的审计侧重点审计场景主要关注对象常用手段核心产出Web应用代码审计认证授权、输入校验、会话管理、敏感信息泄露静态代码扫描、人工代码走查、依赖分析漏洞清单、代码证据、修复建议主机与配置基线审计账户策略、补丁状态、安全模块、开放端口基线扫描、配置核对、日志审查配置偏差表、加固建议流量与威胁检测异常连接、恶意域名、数据外传、横向扩散IDS规则、流量分析、日志关联事件告警、调查时间线、处置建议注意一点一个系统上线前的审计和已经运行很久的系统做排查侧重点完全不同。上线前审计要全只要可能导致后续返工的问题都要列出来已上线系统排查要准优先关注正在被利用的漏洞和异常行为不要因为揪着一个低危配置项耽误了抢救时间。2. 技能落地的第一步把审计经验变成可复用的Checklist2.1 为什么审计经验总在“换人重来”我带过不少新人也接手过别人做了一半的审计项目。最让我头疼的不是技术难点而是经验断层上一个工程师知道某个老系统里有一个隐藏的管理接口但他没写进文档他知道某台机器改了SSH端口但审计报告里没有提。换一个人来又得从零摸一遍。要解决这个问题不能靠这个人记性好得靠资产化。把审计中会用到的检查项、判断标准、证据格式、报告模板全部沉淀成结构化文档。这样哪怕团队换血后来人拿着这套东西也能快速上手更进一步这套结构化文档还能变成指令交给AI助手去执行初步筛查。我常跟团队说安全审计不应该是一个聪明人临场发挥的活儿应该是一个普通人按流程也能执行的活儿。能流程化的东西才有质量下限。2.2 设计一份能直接用的审计Checklist一份合格的审计Checklist不是简单罗列检查项而是每条都要能指导执行。我设计检查项时一般包含以下字段编号、检查项描述、风险等级、依据标准、检测方法、证据要求、修复建议。以代码审计为例我拿其中一条来展示编号检查项风险等级依据检测方法证据要求修复建议WEB-AUTH-003越权访问对象级别的资源访问是否校验属主高OWASP API1:2023 / CWE-639代码审计分析控制器中对ID参数的校验逻辑手工验证不同用户间资源访问构造两个测试账号复现请求并保存响应包与数据库记录在服务端增加资源属主校验禁止仅依赖前端控制这样的表格看起来朴素但实际价值非常大。它能让审计人员问自己这条我查了吗查出来的证据保存了吗如果结论是未发现风险那也有据可查不会空口无凭。2.3 把Checklist升级成“技能包”结合Agent skill思路最近AI圈很流行skill这个概念。大白话讲skill就是一段结构化的指令集里面定义了角色、任务、执行步骤、输入输出格式、参考资料让AI助手能按固定流程完成一类任务而不是每次都要现场自由发挥。Codex、Claude这类工具都有skill插件Spring AI里也有类似的Agent skill设计。安全审计为什么特别适合做成skill因为它判断标准明确、步骤固定、输出格式清晰。我自己的security-audit-skill包结构大概是这样的security-audit-skill/ ├── skill.md ├── checklists/ │ ├── web-code-audit.md │ ├── baseline-config-audit.md │ └── dependency-audit.md ├── prompts/ │ ├── code-review-system.md │ └── config-review-system.md └── templates/ ├── audit-report.md └── evidence-record.mdskill.md定义整个技能包的用途和总流程checklists放前面说的审计检查清单prompts放给AI用的提示词模板templates放报告和证据记录模板。不同技术生态里都能看到这种把经验打包的趋势比如前端有 best-practices 之类的技能包硬件设计里也有基于脚本语言的技能沉淀。归根结底这件事和具体技术栈无关核心是能不能把一个人的经验变成团队可复用的资产。3. 实操手把手构建一个“Web安全审计技能包”3.1 静态代码审计的起点Fortify SCA的教训做Java应用代码审计我常用的工具是Fortify SCA。第一次用的时候就踩了个很典型的坑打开Audit Workbench直接报许可证过期。排查了半天发现是许可证文件没放到正确目录环境变量指向的路径还是旧版本。后来我把这个问题的处理方式直接写进了技能包的FAQ里再遇到就不慌了。Fortify SCA的基本流程是先建项目、做编译前清理、配置源码和依赖再做扫描最后打开审计工作台分析结果。命令行示例如下sourceanalyzer -b MyApp -clean sourceanalyzer -b MyApp -Xmx2G -sourcever 1.8 -cp lib/* src/ sourceanalyzer -b MyApp -scan -f build.fpr扫描完成后可以导出报告也可以直接在Audit Workbench里逐条看漏洞。不同版本命令稍有差异但思路一致先clean保证环境干净再指定源码和classpath最后生成中间文件供审计分析。这里我想强调一个观点Fortify这类工具只是起点不能替代审计师。工具会把所有可能的问题都列出来大量误报和不重要的中低危项混杂在一起。真正的价值在于你如何筛选、验证、合并。比如同一个参数从请求入口传到多个方法工具可能报十几个告警但人工复核后会发现本质上是同一个根因报告里应该合并成一条否则开发人员看着一堆重复漏洞直接就不想改了。3.2 编写第一版审计技能提示词有了Checklist和工具链路接下来就是把经验喂给AI。我写提示词时不会一上来就让它分析这段代码有没有漏洞而是给它一个完整的角色定义和执行框架。下面是一段我实际用的代码审计系统提示词做了简化脱敏你是一名资深Web应用安全审计工程师专注于Java/Spring技术栈。你的任务是对给定的代码片段或项目文件进行安全审计。 审计范围包括 - 认证与授权是否存在越权、未授权访问、硬编码凭据 - 输入校验是否存在SQL注入、XSS、命令注入、路径遍历 - 会话管理Cookie属性、Token有效期、会话固定问题 - 敏感信息日志是否记录密码、配置是否泄露密钥 - 依赖与组件使用已知存在高危漏洞的组件 输出格式要求 1. 按风险等级从高到低排列 2. 每条发现必须包含问题描述、受影响代码位置文件行号、风险等级、对应CWE编号、修复建议 3. 如果不确定是否为真漏洞标记为需人工复核不要强行下结论 4. 禁止编造代码中不存在的问题每条结论必须引用具体代码片段 请开始审计以下内容这段提示词的关键不是让AI干活而是约束AI别瞎说。安全领域最怕的就是AI一本正经地编造漏洞审计报告里出现虚假结论那是会砸招牌的。所以我在prompt里明确要求不确定的标记为需人工复核禁止编造问题。实际使用中这个提示词配合Codex、Claude这类工具能把代码走查的初筛效率提升不少但最终确认和定级还是得过我这一遍。AI在这里的角色是刷经验书不是替代老师傅。3.3 用CSRF/越权场景走一遍流程拿一个实际场景做例子审计一个Spring Boot项目功能是用户修改个人资料。开发人员说登录了就能改自己的资料听起来没毛病。我的审计步骤是这样的第一步看认证实现。查项目里是否引入了Spring Security是谁在做登录校验。很多项目用拦截器只做了是否登录的判断没有做是否有权限的判断。第二步看越权。修改资料的接口/api/user/profile/{id}后端有没有校验当前登录用户和{id}是否匹配。这是典型的对象级越权CWE-639。如果接口完全信任前端传的id那只要登录用户把id换成别人的就能改别人的资料。第三步看CSRF。Spring Security从5.x开始默认开启CSRF防护但很多开发在前后端分离的项目里为了方便直接把CSRF关掉了理由是我们用的是Token认证不需要CSRF防护。这个理由在某些场景下成立但如果项目同时保留了Cookie会话认证关掉CSRF就是风险敞口。审计的时候不能听口头解释要看实际配置。第四步用技能包里的提示词让AI复查一遍把初筛结果和我的分析做交叉验证。确认后我会在报告里写清楚风险等级高问题1越权修改资料CWE-639证据是UserController.java第 58 行使用前端传入的userId直接查询更新问题2CSRF防护被关闭CWE-352证据是SecurityConfig.java第 23 行存在csrf.disable()修复建议服务端从Session或Token中获取当前用户身份禁止依赖前端参数确认认证方式为无状态Token后可考虑保持CSRF关闭否则必须开启这个流程走下来才算完成了一个审计项的闭环。3.4 配置审计落地Windows安全策略与Spring Security代码之外配置审计同样重要而且更琐碎。我拆开说。Windows系统做安全审计经常要看本地安全策略和审计策略。这些策略在系统内部存储于HKEY_LOCAL_MACHINE\SECURITY\Policy\Accounts等注册表位置但实际配置时不会直接去改注册表而是通过secpol.msc或命令行工具auditpol来查看和设置。比如查看当前系统的审计策略可以执行auditpol /get /category:*这条命令会把账户登录、对象访问、进程创建、系统事件等类别的审计开关状态全部列出来。审计的时候要重点确认登录事件是否记录成功和失败、账户管理是否有审计、特权使用是否开启。如果这些关键审计策略都是关闭的那系统被入侵了你连追溯的日志都没有。Linux侧我习惯先看getenforce确认SELinux状态或者用aa-status查看AppArmor配置。虽然很多运维图省事把强制访问控制关了但从审计角度看生产环境关闭SELinux/AppArmor本身就是一个需要记录的基线偏差。再说Spring Security配置。这两年Spring Boot 3里做了不少配置迁移很多人从旧项目升级的时候都会碰到问题。比如旧版用的authorizeRequests()已经废弃新版本里要改用authorizeHttpRequests()配置写法也从链式.and()变成了Lambda DSL。还有Spring Security 7对默认行为做了进一步调整迁移时尤其要注意CSRF默认策略、默认登录页、会话管理的变化。针对配置审计我的技能包里专门有一份配置项速查表把常见中间件和框架的关键安全配置列出来审计时逐项打勾。这种活很枯燥但最不容易出错。4. 流量与主机侧审计主动验证和异常发现4.1 主动验证Kali Linux思路的正确打开方式很多初学者一看到Kali Linux第一反应是拿来攻击。但在安全审计语境下Kali更像一个工具箱用来做主动验证。所谓的渗透测试本质是在授权范围内用真实攻击者的视角去验证系统防御是否有效。Kali Linux官方那句 Assuring Security by Penetration Testing 说得挺清楚通过渗透测试来保证安全。但做这件事有严格的边界必须有书面授权、明确测试范围、约定禁止操作项比如不允许提权后横向移动、不允许删除数据、不允许影响业务可用性。我在审计项目里用Kali做的最多的是信息收集和验证确认开放了哪些不必要的端口检查常见管理入口是否暴露验证某个疑似漏洞是否真实存在。比如发现某台服务器开放了一个非标准端口的数据库服务我不会直接去连它而是先记录到证据表里再联系系统负责人确认用途。如果确认是测试环境遗留的就在报告里记为高风险的攻击面暴露项建议关闭或加白名单。记住审计师的Kali操作逻辑是发现问题、记录证据、推动整改不是进来了还要再逛一圈。4.2 流量侧Security Onion 3.2单机部署与基础配置说到流量侧的审计和检测我团队内部用得比较多的是Security Onion。它是一套开源的安全监控平台把Suricata IDS、Zeek网络分析、日志检索和告警管理集成在一起。3.2版本支持单机安装适合中小规模环境或实验室使用。单机部署时我的建议是这样的先看硬件内存至少16G磁盘越大越好因为流量日志增长很快网络上要区分管理口和监控口监控口接交换机镜像端口SPAN端口才能看到目标网段的流量。安装过程走ISO引导系统起来后用sudo sosetup进入配置向导按提示选择管理模式、配置IP、设置管理员账号。安装完成后通过Web界面验证sensor状态是否正常确认Suricata和Zeek都在运行。这一步常被忽视很多人装完就丢一边过几天发现流量接口根本没接对白装了。部署好之后我一般会先做一轮自测告警用测试机发起一些明显的异常行为比如访问恶意域名用测试域名代替看能不能在Security Onion界面上看到告警。如果自测都看不到说明镜像端口或者规则配置有问题得先排掉再谈正式检测。4.3 判断异常流量而不是误报三层交叉验证安全监控最磨人的是告警太多。Security Onion一顿告警输出如果审计人员只是单纯看告警面板很容易被淹没。我的习惯是三层交叉验证。第一层看IDS告警。Suricata报了可疑行为这只是一个可能有问题的信号。第二层去Zeek的会话日志里找这条告警对应的完整连接记录看源IP、目的IP、端口、传输字节数、持续时间。第三层去主机侧日志里找关联信息那段时间目标服务器有没有对应的登录记录、进程启动记录、文件变更记录。举个例子IDS告警显示有内网主机在大量连接外部地址。只看告警会以为是数据外传但当我去Zeek里查会话发现连接都集中在80/443端口且流量特征像是正常的Windows更新再配合主机日志确认是系统补丁在自动下载。这就是一个典型的误报。反过来如果Zeek日志显示连接目的端口不常见、回包很小、请求频率固定同时主机日志里出现了异常的计划任务那就有理由升级为事件做进一步处置。审计技能里最值钱的部分其实就是这种把多个数据源串起来交叉验证的能力。5. 常见问题与排查技巧实录5.1 工具、环境与操作系统层面的坑做安全审计几年工具和环境层面的坑没少踩。我把高频问题列个表方便你直接查。问题常见原因处理思路Fortify SCA打开Audit Workbench报许可证过期许可证文件路径不对、环境变量指向旧版本、许可证日期失效检查许可证文件是否在正确目录替换为有效许可确认环境变量没有残留旧路径Windows Security变成英文了系统更新或语言包异常导致显示语言变化检查设置-时间和语言-语言把显示语言切回中文如果无效重装中文语言包Local Security Authority Process 占用CPU过高认证请求量突增、证书验证异常、服务本身异常先看事件日志中认证相关错误检查证书信任链在维护窗口重启相关服务并观察Linux下getenforce返回DisabledSELinux被关闭可能是历史遗留或性能考虑确认是否为运维主动关闭在报告中标记为基线偏差提供逐步启用的建议老项目报 Visual C 2005 SP1 ATL Security Update 相关错误老组件缺少安全更新或与新版系统不兼容安装对应安全更新评估是否能迁移到受支持的现代组件这类问题解决一次不难难的是下次换个环境又遇到的时候又要重新搜一遍。所以我每踩一次坑都会把问题原因解决写回技能包里的FAQ文件时间长了就是一份很值钱的经验库。5.2 审计过程中被验证码和安全策略挡住的处理自动化扫描或脚本审计时经常碰到两个提示第一个是 Please complete the security check and try again.第二个是 This action is not allowed with this security level configuration.第一个提示通常意味着目标系统部署了人机验证或WAF防护把自动化请求识别为异常流量。审计人员这时候要做的不是想方设法绕过而是确认这类防护本身就是系统的一项安全控制应该在报告里如实记录系统启用了人机验证/WAF防护自动化审计工具的深度访问受限建议在授权情况下提供测试白名单或改用只读账号进行进一步验证。第二个提示一般是应用的安全配置限制了当前账号或当前安全级别下的操作。审计思路是判断这是预期安全策略还是配置错误。比如一个普通运维账号试图修改策略配置被拒绝这是预期行为说明权限控制生效了如果是一个应该在管理组的账号被拒绝那就要查账号权限分配是否正确可能是角色配置有误。还有一个容易混淆的场景就是Windows下提示某些操作受安全策略限制比如HKEY_LOCAL_MACHINE\SECURITY\Policy\Accounts相关键值不允许直接读取修改。这是系统底层权限设计正常审计通过标准工具即可不要去硬碰注册表。遇到这个操作被安全设置拒绝先看当前进程是否以管理员身份运行、是否真的需要该权限避免为了审计把自己机器搞崩。5.3 写报告与推动整改的个人体会最后聊点个人体会。审计报告写得再好如果没人看等于零。我见过很多报告密密麻麻几十页把工具的输出原封不动贴上去乍一看很专业实际上业务方根本不知道从哪下手。我的报告结构固定为四块审计范围与目标、问题汇总排序表、重点问题证据与整改建议、复测时间安排。问题汇总按风险等级排每个问题只给一句话说明细节放附录。研发同学看汇总表就知道优先级需要深入看的再翻附录里的证据。报告的每个结论必须能回答三个问题影响是什么、发生可能性多大、证据在哪。说不清楚的宁可再花一天去验证也不要靠猜。因为我见过太多因为报告里一句疑似高危引发的扯皮最后发现是误报信任感直接打折扣。这几年我越来越觉得安全审计这个技能核心不是发现漏洞的敏锐度而是建立证据链的严谨度和推动事情闭环的沟通力。技术工具可以换方法论和经验沉淀才是真正长期值钱的东西。把每一次审计都当成一次知识积累把每一个踩过的坑都固化下来这就是security-audit-skill这个技能包对我来说最大的意义。