SonarQube默认不报SQL注入，因其security类规则（如SQL拼接、${}占位符）默认关闭；必须显式启用sonar.java.rule.jdbc=security、sonar.java.rule.hql=security及sonar.mybatis.mapper.location等配置，并确保源码与字节码路径正确，否则无法识别上下文中的高危模式。
能直接检测SQL注入，但必须配对规则+上下文识别，否则漏报率极高。
为什么默认扫描不报SQL注入
SonarQube 默认开启的是基础代码质量规则，security 类规则（如 SQL 拼接、硬编码密码）默认是关闭的。Java 项目里，@Query 字符串拼接、JdbcTemplate.execute() 动态 SQL、MyBatis 的 ${} 占位符这些高危模式，只有显式启用对应安全规则集才会被标记。
- Spring Boot + JPA 场景下，不配置
sonar.java.rule.hql=security，@Query("SELECT * FROM user WHERE name = '" + name + "'")不会触发告警 - MyBatis 项目若没设
sonar.mybatis.mapper.location，XML 中的<script>SELECT * FROM ${table}</script>完全不会被扫描到 - Gradle 项目如果没在
sonar-scanner命令中传-Dsonar.language=java，可能 fallback 到通用解析器，跳过 Hibernate/JPA 语义分析
CI/CD 中必须加的 3 个关键配置项
这些不是可选项，缺一不可，否则安全规则形同虚设：
-
sonar.java.rule.jdbc=security：激活 JDBC 层字符串拼接检测，覆盖Statement.executeUpdate("UPDATE t SET v = " + input)类模式 -
sonar.java.rule.hql=security：启用 HQL/JPQL 注入检测，识别@Query和EntityManager.createQuery()中的拼接风险 -
sonar.mybatis.mapper.location=src/main/resources/mapper：指定 MyBatis XML 映射文件路径，否则被完全忽略
注意：sonar.java.rule.* 配置只在 SonarScanner 5.0+ 有效；老版本需改用 sonar.rules.category=Security，但精度差很多。
GitLab CI / Jenkins 流水线中的典型错误写法
常见配置错误会导致规则加载失败或参数被忽略：
- GitLab CI 中写成
sonar-scanner -Dsonar.java.rule.hql=security—— 错。必须通过sonar-project.properties文件或环境变量SONAR_SCANNER_OPTS传递，命令行 -D 不生效于 rule.* 参数 - Jenkins Pipeline 中
withSonarQubeEnv块内漏掉sonar.java.binaries=target/classes—— 错。没有编译产物路径，SonarQube 无法做 AST 分析，所有 Java 安全规则失效 - 在 Maven 多模块项目中只在父 pom 配置
sonar-maven-plugin，但子模块没声明sonar.sources—— 错。子模块源码路径未显式指定，扫描范围为空
验证是否真起作用的最快方式
别等流水线跑完看报告，本地快速验证更可靠：
- 在项目根目录放一个测试文件
SqlInjectDemo.java，内容含明确高危模式：String sql = "SELECT * FROM users WHERE id = " + userId; - 执行：
sonar-scanner -Dsonar.projectKey=test -Dsonar.sources=. -Dsonar.java.binaries=target/classes -Dsonar.java.rule.jdbc=security - 检查控制台输出是否有类似
1 issue found: 'SQL injection vulnerability'；再登录 SonarQube UI 确认该问题出现在 Security > Vulnerabilities 分类下
真正容易被忽略的点是：规则启用后，仍需确保源码和字节码路径都正确指向实际构建产物——很多团队扫了半天没结果，最后发现 sonar.java.binaries 指向了空目录或旧缓存。
