企业官网建设流程全解析

真正意识到“安全审计”必须当作一门技能来打磨，是我第一次独立负责一个业务系统的上线前评估。当时我手里的工具很全，但整个流程跑得七零八落：一会儿拿着扫描器全站扫，一会儿翻代码找硬编码密钥，一会儿又去改 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 SCA（Static 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 Security（Windows 安全中心）其实是一个聚合面板，它管理着病毒和威胁防护、账户保护、防火墙和网络保护、应用和浏览器控制、设备安全性、设备性能和运行状况、家庭选项这几个模块。审计时不能只看一眼“绿色对勾”就完了，要逐项核查策略是否真正生效。

我遇到过一个很典型的情况：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 有 Skill，Codex 有 Skill，OpenCode 也有 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.md

SKILL.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.md，AI 在最终汇总时会严格按照这个结构输出。

搭好之后，我会用两到三个真实项目做测试。第一轮通常会暴露一个问题：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. 常见问题与排查技巧实录

工具用得越多，踩过的坑就越有参考价值。下面这些问题是安全审计项目里高频出现的，我把排查思路和解决方法整理出来，方便直接查阅。

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，用一两个真实项目跑通，再慢慢扩充成完整的审计流水线。这个过程踩的坑，比看一百篇教程都有价值。