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

摘要给一个 JDK 1.8 的老 Spring MVC 项目做安全审查想让 AI 扫 pom.xml 找出组件漏洞并升级。两轮对话下来Token 烧了一大把漏洞一个没修。根因就一条AI 不是安全工具它不认识 CVE 数据库。正确的做法是三道防线互补SAST 堵代码逻辑漏洞、SCA 堵组件供应链漏洞、配置加密堵明文凭据泄露。2026 年了弄了个老项目。JDK 1.8Spring 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 依赖 BB 依赖 CC 的某个版本有 CVE-2024-38821这条链路 AI 根本追踪不了。你让 AI 做组件漏洞扫描约等于让一个读过很多安全博客的人凭记忆帮你审计。他能说个大概但你真跑mvn verify就露馅了。正确的做法三道防线安全这件事没有银弹。三道防线覆盖三个完全不同的攻击面谁也替代不了谁。防线一SASTSemgrep / SonarQube堵代码逻辑漏洞。SQL 注入、越权、不安全加密、命令执行、硬编码密钥——这些在.java文件里。防线二SCAOWASP 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里那行明文——开发本地留着、运维打包镜像带着、服务器磁盘被拖走全是裸奔。加上配置加密才是完整闭环。三个等级 层级 1SAST SCA低能拦代码漏洞和已知 CVE但配置文件明文泄露无解。不适合生产。 层级 2SAST SCA 配置加密生产基线轻量用 jasypt、dotenv企业级用 Nacos/Apollo 加密或 Vault/KMS 托管密钥。密文落盘、密钥分离配置文件泄露也解不开。 层级 3SAST SCA 加密 密钥扫描等保/密评加 Gitleaks 在 CI 流水线拦截明文提交禁止本地明文配置环境变量注入密钥不落盘。防护维度SASTSemgrep/SonarSCAOWASP 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-CheckMaven 插件一行配置的事plugingroupIdorg.owasp/groupIdartifactIddependency-check-maven/artifactIdversion12.2.2/version/plugin然后mvn dependency-check:check它干的事很直接把你的依赖树和 NVD 的 CVE 数据库做精确匹配。不是猜是查。跑完生成一份 HTML 报告每个漏洞有 CVE 编号、CVSS 评分、受影响版本范围、修复建议。这才是组件漏洞扫描该有的样子。来源OWASP Dependency-Check 官方文档防线二代码漏洞——Semgreppipinstallsemgrep semgrep--configauto.它会告诉你哪一行写了什么不该写的东西。也可以自定义规则——比如禁SELECT *写一条 Semgrep 规则就能自动拦。SonarQube 社区版备选有 Web 面板、新增代码阻断、漏洞归属和历史对比。如果想降低 SAST 误报可以搭配语言原生专用工具JavaSpotBugs FindSecBugsGogosecPythonBanditNodeeslint-security防线三配置加密application.properties里的密码是明文的db.passwordMyPlainTextPwd123跟把钥匙挂在门锁上一个性质。配置加密分两个层级。轻量级jasypt 给配置加解密、dotenv 用.env文件、Spring Cloud Config 统一管理。企业级Nacos 配置中心自带加密插件、Apollo 支持配置项级加密、Vault 或云厂商 KMS 托管密钥。我们项目的路径是两步走先用 Nacos 把配置管起来后续用 Vault 单独管密钥——配置和密钥分开权限分离万一 Nacos 的配置被人翻到了密码至少不是明的。这里踩了一个很隐蔽的坑。运维给的 Nacos 实例没开 gRPC 端口。Nacos 的 gRPC 端口默认是 HTTP 端口 1000运维只开了 HTTP 那一个。用curl查配置没问题但用nacos-clientSDK 就得走 gRPC 长连接——一直连不上没有任何报错信息日志里干干净净就是获取不到配置。排查了半天才翻到 Nacos 文档里那行小字。教训就一条对接新组件之前先看端口文档别默认给了地址就能用。端口与主端口的偏移量描述98481000客户端 gRPC 请求服务端端口98491001服务端 gRPC 请求服务端端口7848-1000Jraft 请求服务端端口来源Nacos 官方文档 gRPC 端口说明分场景落地个人/小项目自测Semgrep OWASP DC只能保代码和依赖无明显漏洞配置明文风险高不建议生产用。测试/预发环境Semgrep OWASP DC jasypt 轻量加密拦截明文提交 加密线上配置。生产/等保三级SAST 流水线门禁 SCA 阻断高危依赖 Gitleaks 拦截明文提交 Nacos/Vault 托管密钥禁止本地明文配置密钥走环境变量不落盘。一句话AI 不是安全工具。三道防线SAST 查代码、SCA 查组件、加密保管配置。缺一道就漏一个口子。各用各的工具别让 AI 干它干不了的事。延伸阅读OWASP Dependency-Check Maven PluginSemgrep Registry — Java 安全规则库Nacos gRPC 端口说明NVDNational Vulnerability Database — CVE 查询入口作者唐悦玮 公众号同名从后端出发用 AI 拓展到全栈的工程师。