如何在CICD流水线中集成SonarQube安全插件以检测SQL注入？

本文共计873个文字，预计阅读时间需要4分钟。

能直接检测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 映射文件路径，否则 <select>...${param}...</select> 被完全忽略

注意：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 指向了空目录或旧缓存。