SonarQube 默认不报SQL注入，因JDBC/HQL/MyBatis安全规则被隔离在security规则集且默认关闭；必须显式启用sonar.java.rule.jdbc=security等参数，并确保字节码路径、源码路径与规则启用三者齐全有效。
SonarQube 默认不报 SQL 注入，不是漏了，是规则根本没开——必须手动激活 sonar.java.rule.jdbc=security，且字节码路径、源码路径、规则启用三者缺一不可。
为什么 Statement.executeUpdate("UPDATE t SET v = " + input) 从不告警？
因为 Java 安全规则（JDBC/HQL/MyBatis）被隔离在 security 规则集里，默认关闭。SonarQube 把 quality 和 security 完全分开，sonar.java.rule.jdbc=security 不配，等于没装 SQL 注入检测模块。
-
sonar.java.rule.hql=security没开 →@Query("SELECT * FROM u WHERE name = '" + name + "'")静默通过 -
sonar.mybatis.mapper.location路径错或未设 → XML 中的<select>SELECT * FROM ${table}</select>直接跳过 - 用 Maven 多模块时，子模块没声明
sonar.language=java→ fallback 到通用解析器，Hibernate/JPA 语义识别失效
sonar-scanner 5.0+ 的配置陷阱：命令行 -D 传参无效
SonarScanner 5.0 及以上版本明确不支持命令行用 -Dsonar.java.rule.jdbc=security 这类方式传安全规则参数——这是硬限制，不是配置顺序问题。
- 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 分析失败 → 所有 Java 安全规则不触发 - Spring Boot 项目还要补
sonar.java.libraries=target/lib/*.jar，否则无法解析 Spring Data JPA 或 MyBatis 的动态 SQL 上下文
MyBatis XML 和注解 SQL 怎么一起扫？
MyBatis 的 SQL 风险分散在 XML 和注解两种载体，SonarQube 原生不统一处理，需分别配置：
- XML 方式：装
sonarqube-mybatis-plugin插件（GitHub amoywang），它把 XML 当作独立语言扫描，支持${table}、#{param}区分校验 - 注解方式：依赖
sonar.java.rule.jdbc=security+ 正确的sonar.sources（必须包含含@Select/@Query的 Java 文件） - 注意：插件启用后会覆盖项目原有的 XML 规则，若已有其他 XML 检查（如格式规范），需手动合并规则集
最容易被忽略的是字节码路径和源码上下文的严格对齐——target/classes 编译产物缺失、或 src/main/java 路径指向错误，都会让所有 JDBC 安全规则变成摆设。规则开了≠能跑，得让 SonarQube 真正“看懂”那段拼接 SQL 是在哪执行、用了什么框架、参数从哪来。
