sonarqube默认不报sql注入是因为sonar.java.rule.jdbc=security安全规则被关闭，必须手动启用，并确保字节码路径、源码路径和规则激活三者同时正确，否则statement.executeupdate("update t set v = " + input)等漏洞将静默通过。
SonarQube 默认不报 SQL 注入，不是它没能力，而是 Java 安全规则集（sonar.java.rule.jdbc=security）默认关闭——必须手动启用，且字节码路径、源码路径、规则激活三者缺一不可，否则 Statement.executeUpdate("UPDATE t SET v = " + input) 这类高危拼接会完全静默通过。
为什么 SonarQube 总是扫不出 JDBC 拼接漏洞
根本原因不是分析不准，而是安全规则没“通电”。SonarQube 把 quality 和 security 规则物理隔离，Java 项目中所有 JDBC/HQL/MyBatis 层的字符串拼接风险（比如 executeUpdate、@Query("" + name)、${table}）全在 security 规则集里，不显式激活就等于没装模块。
常见失效组合：
-
sonar.java.rule.jdbc=security没配 →executeUpdate("UPDATE t SET v = " + input)静默通过 -
sonar.java.binaries=target/classes没设或路径错 → AST 分析无法进行，所有 Java 安全规则失效 -
sonar.sources=src/main/java路径不对 → 上下文识别失败，@Query("SELECT * FROM u WHERE name = '" + name + "'")直接漏掉
GitLab CI / Jenkins 中 sonar-scanner 的硬性配置要求
SonarScanner 5.0+ 对 sonar.java.rule.* 类参数有严格限制：不支持命令行 -D 方式传参，这是硬限制，不是配置错误。
正确做法：
- GitLab CI：用
sonar-project.properties文件，或通过环境变量SONAR_SCANNER_OPTS="-Dsonar.java.rule.jdbc=security -Dsonar.java.rule.hql=security" - Jenkins Pipeline：
withSonarQubeEnv块内必须显式指定sonar.java.binaries=target/classes，否则无字节码，AST 分析瘫痪 - Maven 多模块：父 pom 配了
sonar-maven-plugin，但子模块没声明sonar.language=java，可能 fallback 到通用解析器，跳过 Hibernate/JPA 语义识别
如何验证 SonarQube 真正生效了
光配对参数不等于能扫出问题。必须确认三件事同时成立：
- 扫描日志里出现类似
Security rules enabled: [java:S2077, java:S2095]的提示，说明jdbc=security已加载 - 报告中能看到
java:S2077（SQL query is vulnerable to injection）或java:S2095（HQL query is vulnerable to injection）这类规则 ID - 故意写一个测试用例：
String sql = "SELECT * FROM user WHERE id = " + request.getParameter("id");，看是否被标记；如果没报，一定是binaries或sources路径没对上
最容易被忽略的是字节码路径和源码路径的同步——哪怕只差一个 / 或大小写错误，上下文就断了，规则形同虚设。
