用AI给老项目做安全升级，Token干冒烟了

摘要：给一个 JDK 1.8 的老 Spring MVC 项目做安全审查，想让 AI 扫 pom.xml 找出组件漏洞并升级。两轮对话下来，Token 烧了一大把，漏洞一个没修。根因就一条：AI 不是安全工具，它不认识 CVE 数据库。正确的做法是三道防线互补：SAST 堵代码逻辑漏洞、SCA 堵组件供应链漏洞、配置加密堵明文凭据泄露。

2026 年了，弄了个老项目。JDK 1.8，Spring MVC——不是 Spring Boot，连微服务的影子都没有。

你可能觉得「这年头还有这种项目」，就像有人还在用 Win7 一样。不用太吃惊，真实世界就这样。

需求：做一轮安全审查，把依赖组件里的已知漏洞找出来，升级到安全版本。

第一轮：让 AI 来扫

打开 Cursor，把 pom.xml 扔进去，给了一句 Prompt：

找出 pom.xml 中依赖的组件漏洞，并修复升级到最新版

AI 很认真。它拆了好几个任务，先分析依赖树，再逐个查版本号，然后试图匹配它「知道」的安全公告。一顿操作，输出了不少东西。

一轮下来，等它忙完，Token 烧了不少。pom.xml 及代码修改了不少，修复编译报错也花了不少时间。

第二轮：Token 彻底炸了

经历了漫长的过程，好不容易第一轮结束了，发现升级的很多组件并不是最新版，在https://mvnrepository.com仓库中查看组件对应版本还是有漏洞的。
又跟 AI 说话：

升级pom.xml 中xxx组件，并修复升级到最新版

一顿操作，输出了不少东西，修改pom.xml、修复编译报错.....结束后发现还是没有升级到最新版。

两轮下去，Token 干冒烟了。漏洞还是一大堆。

它不是在扫描，是在猜

冷静下来想，这个翻车不是偶然的。

AI 做安全审查，本质上是 Pattern Matching。它把你 pom.xml 里的 groupId:artifactId:version，跟训练数据里见过的安全文章做模糊匹配。某个组件在哪篇安全文章里出现过，它就输出「可能有漏洞」。

但它不认识 CVE 数据库。它不知道 NVD（美国国家漏洞数据库）里存了什么。它更不会做依赖链分析——你的项目里 A 依赖 B，B 依赖 C，C 的某个版本有 CVE-2024-38821，这条链路 AI 根本追踪不了。

你让 AI 做组件漏洞扫描，约等于让一个读过很多安全博客的人凭记忆帮你审计。他能说个大概，但你真跑 mvn verify 就露馅了。

正确的做法：三道防线

安全这件事，没有银弹。三道防线覆盖三个完全不同的攻击面，谁也替代不了谁。

防线一：SAST（Semgrep / SonarQube）
堵代码逻辑漏洞。SQL 注入、越权、不安全加密、命令执行、硬编码密钥——这些在 .java 文件里。

防线二：SCA（OWASP Dependency-Check）
堵第三方依赖的 CVE 供应链漏洞。Log4j、Fastjson、Spring 框架高危版本——这些在 pom.xml 里。

防线三：配置文件加密（jasypt / Nacos / Vault）
堵明文凭据泄露。数据库密码、AK/SK、Redis 密钥、MQ 凭证——这些在 application.properties 里。

拿一句话记住：SAST 管你写的代码有没有毛病，SCA 管你引的包有没有漏洞，配置加密管你的密码有没有裸奔。

安全等级从低到高

只用 SAST + SCA，是「代码和供应链及格，配置存储不及格」。Semgrep 能扫出代码里硬写的密码，但管不了 application-dev.yml 里那行明文——开发本地留着、运维打包镜像带着、服务器磁盘被拖走，全是裸奔。

加上配置加密，才是完整闭环。三个等级：

🟡 层级 1：SAST + SCA（低）
能拦代码漏洞和已知 CVE，但配置文件明文泄露无解。不适合生产。

🟠 层级 2：SAST + SCA + 配置加密（生产基线）
轻量用 jasypt、dotenv，企业级用 Nacos/Apollo 加密或 Vault/KMS 托管密钥。密文落盘、密钥分离，配置文件泄露也解不开。

🟢 层级 3：SAST + SCA + 加密 + 密钥扫描（等保/密评）
加 Gitleaks 在 CI 流水线拦截明文提交，禁止本地明文配置，环境变量注入密钥不落盘。

防护维度	SAST（Semgrep/Sonar）	SCA（OWASP DC）	配置加密
防护对象	自研代码逻辑缺陷	第三方依赖 CVE	配置文件密码/AK/Token
风险类型	注入、越权、命令执行	Log4j、Fastjson 等供应链	静态存储明文泄露
泄露后防护	无法阻止配置泄露	无关	文件被拖走也拿不到明文
漏报场景	跨文件污点、变形漏洞	内部私有包无 CVE	加密密钥硬编码
等保/密评	建议必备	建议必备	强制要求

三个常见误区

误区一：「Semgrep 能扫明文配置，就不用加密了」

Semgrep 只是检测工具，只能拦截提交到 Git 的明文。开发本地保留的 application-dev.yml 扫描管不到；运维打包镜像时把本地明文配置打进去，CI 拦截不了本地文件。扫描是流程上的「门禁」，加密是存储上的「保险柜」，两个都要。

误区二：「配了加密，SAST 和 SCA 可以省了」

配置加密只管密码，不管业务代码。数据库密码加密存放，但代码里写了字符串拼接 SQL，照样注入。只做配置加密，代码和供应链全是洞，系统一样被捅穿。

误区三：「让 Claude 做 Code Review，这些都能省」

LLM 只能做人工辅助 Review，没有全局数据流分析、没有 CVE 数据库、没有加密存储能力。三个都替代不了。

防线一：组件漏洞——OWASP Dependency-Check

Maven 插件，一行配置的事：

<plugin>
  <groupId>org.owasp</groupId>
  <artifactId>dependency-check-maven</artifactId>
  <version>12.2.2</version>
</plugin>

然后：

mvn dependency-check:check

它干的事很直接：把你的依赖树和 NVD 的 CVE 数据库做精确匹配。不是猜，是查。跑完生成一份 HTML 报告，每个漏洞有 CVE 编号、CVSS 评分、受影响版本范围、修复建议。这才是组件漏洞扫描该有的样子。

（来源：OWASP Dependency-Check 官方文档）

防线二：代码漏洞——Semgrep

pip install semgrep
semgrep --config=auto .

它会告诉你哪一行写了什么不该写的东西。也可以自定义规则——比如禁 SELECT *，写一条 Semgrep 规则就能自动拦。

SonarQube 社区版备选，有 Web 面板、新增代码阻断、漏洞归属和历史对比。如果想降低 SAST 误报，可以搭配语言原生专用工具：

Java：SpotBugs + FindSecBugs
Go：gosec
Python：Bandit
Node：eslint-security

防线三：配置加密

application.properties 里的密码是明文的：

db.password=MyPlainTextPwd123

跟把钥匙挂在门锁上一个性质。

配置加密分两个层级。轻量级：jasypt 给配置加解密、dotenv 用 .env 文件、Spring Cloud Config 统一管理。企业级：Nacos 配置中心自带加密插件、Apollo 支持配置项级加密、Vault 或云厂商 KMS 托管密钥。

我们项目的路径是两步走：先用 Nacos 把配置管起来，后续用 Vault 单独管密钥——配置和密钥分开，权限分离，万一 Nacos 的配置被人翻到了，密码至少不是明的。

这里踩了一个很隐蔽的坑。运维给的 Nacos 实例，没开 gRPC 端口。Nacos 的 gRPC 端口默认是 HTTP 端口 + 1000，运维只开了 HTTP 那一个。用 curl 查配置没问题，但用 nacos-client SDK 就得走 gRPC 长连接——一直连不上，没有任何报错信息，日志里干干净净，就是获取不到配置。排查了半天才翻到 Nacos 文档里那行小字。

教训就一条：对接新组件之前先看端口文档，别默认"给了地址就能用"。

端口	与主端口的偏移量	描述
9848	+1000	客户端 gRPC 请求服务端端口
9849	+1001	服务端 gRPC 请求服务端端口
7848	-1000	Jraft 请求服务端端口

（来源：Nacos 官方文档 gRPC 端口说明）

分场景落地

个人/小项目自测：Semgrep + OWASP DC，只能保代码和依赖无明显漏洞，配置明文风险高，不建议生产用。

测试/预发环境：Semgrep + OWASP DC + jasypt 轻量加密，拦截明文提交 + 加密线上配置。

生产/等保三级：SAST 流水线门禁 + SCA 阻断高危依赖 + Gitleaks 拦截明文提交 + Nacos/Vault 托管密钥，禁止本地明文配置，密钥走环境变量不落盘。

一句话

AI 不是安全工具。三道防线：SAST 查代码、SCA 查组件、加密保管配置。缺一道，就漏一个口子。各用各的工具，别让 AI 干它干不了的事。

唐悦玮