sonarqube仅能识别源码中明显危险的字符串拼接模式，无法检测运行时sql注入；其java插件默认启用s2077等规则但有严格触发条件，需手动激活、配置字节码路径及自定义mybatis规则，并结合动态扫描与人工验证才能有效治理。
SonarQube 本身不检测运行时 SQL 注入漏洞，它只能识别源码中「明显危险的字符串拼接模式」，比如 String sql = "SELECT * FROM user WHERE id = " + id; 这类硬编码拼接。真正在 HTTP 层面可利用的注入点（如 ?id=1' OR SLEEP(5)--），必须靠动态扫描工具（如 sqlmap、Burp）或带污点追踪能力的插件（如 SonarQube 的 sonar-java 规则集 + 自定义规则）辅助定位。
为什么 SonarQube 默认不报 SQL 注入风险？
SonarQube 的 Java 插件（sonar-java）默认启用的规则中，S1095（使用 Statement）、S2077（SQL 查询中拼接用户输入）等确实能捕获部分高危写法，但有严格触发条件：
- 只检查显式调用
java.sql.Statement#execute*或PreparedStatement构造时传入的字符串是否含变量拼接 - 不分析框架封装层（如 MyBatis 的
${}、JPA 的原生查询、Spring JDBC 的query()第二个参数为字符串） - 对
String.format()、StringBuilder拼接、模板引擎生成 SQL 等场景基本无感知 - 若变量经过
Integer.parseInt()或StringUtils.stripToNull()等“看似安全”的处理，规则可能直接跳过
如何让 SonarQube 实际捕获更多注入触点？
关键不是装插件，而是调整规则激活策略和补充自定义规则：
- 在
Quality Profiles → Java → Activate中，手动启用S2077（SQL query has a potential injection vulnerability）和S3646（Use PreparedStatement instead of Statement） - 禁用
S1095（它只报Statement，而现代项目几乎不用，误报率低但覆盖窄） - 在项目
sonar-project.properties中强制开启污点分析：sonar.java.binaries=target/classes（确保编译后字节码可用），否则S2077无法做数据流跟踪 - 针对 MyBatis，添加自定义正则规则：匹配
<select.>.*?\$\{.*?\}.*?</select.>，并设为 BLOCKER 级别
集成 FindBugs/SpotBugs 后仍漏报？这是正常现象
FindBugs（现为 SpotBugs）的 SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE 规则与 SonarQube 的 S2077 原理类似，都依赖字节码中的字符串常量判定。但两者共同短板明显：
- 遇到
sqlTemplate.replace("{id}", id)这种间接拼接，完全无法识别 - 若 SQL 字符串被拆成多行、用
+分段拼接，静态分析链断裂 - 所有规则对 ORM 框架的注解式查询（如
@Query("SELECT * FROM t WHERE name = ?1")）视而不见 - 实际项目中，80% 以上的注入风险点藏在动态构建的条件语句里（如
WHERE子句由 Map 遍历拼接），这类逻辑 SonarQube 根本不建模
真正有效的自动化组合策略
把 SonarQube 当作「代码卫生检查员」，而非「渗透测试员」。要发现可利用的注入点，必须分层推进：
- 静态层：用 SonarQube + 自定义规则筛出高危拼接模式，人工确认是否可控（重点看参数来源：是
request.getParameter()？还是@PathVariable？） - 动态层：用
sqlmap -u "http://x.com/api?id=1" --batch --level=3 --risk=2扫描已上线接口，它能自动判断数字/字符型、盲注类型，并验证 payload 是否真实执行 - 流程层：在 CI 流水线中，用
sonar-scanner卡住S2077问题（设置sonar.qualitygate.wait=true），同时用curl调用 sqlmap API 对 staging 环境做回归扫描
最易被忽略的是：SonarQube 报出的 S2077 问题，开发常直接改成 PreparedStatement 就提交，但没验证该 PreparedStatement 是否真用了 setString() —— 如果还是用 String.format() 拼完再传给 executeQuery()，漏洞照旧。静态工具永远无法替代对数据流向的完整理解。
