Java项目Checkmarx报SQL注入误报，有哪些可行的消除方案？

核心原因是Checkmarx无法识别动态拼接的表名processTable的来源是否为用户可控，因此触发SQL注入规则，可通过以下任意方案解决：

• 方案1：新增表名白名单校验逻辑
  在做字符串替换前，先校验传入的表名是否在预定义的合法表名白名单内，仅完全匹配时才执行后续拼接逻辑，Checkmarx可识别该 sanitization 逻辑消除告警。
  示例代码如下：

// 预定义允许操作的表名白名单
private static final Set<String> ALLOWED_PROCESS_TABLES = Set.of("t_process_1", "t_process_2", "t_process_config");

// 替换前先校验
if (!ALLOWED_PROCESS_TABLES.contains(processTable)) {
    throw new IllegalArgumentException("非法的表名参数：" + processTable);
}
String SQL_SELECT = "SELECT PROCESS_ID FROM ${table}";
query = SQL_SELECT.replaceAll(TABLE_REGEX, processTable);
// 后续逻辑保持不变

• 方案2：固化表名来源的可信标识
  将配置文件读取的表名封装为静态常量，切断和外部用户输入的链路：
  1. 把从properties读取的表名赋值给static final修饰的常量，禁止运行时修改
  2. 读取配置时就完成合法性校验，不允许非法值流入DAO层
  3. 若项目支持可将表名定义在枚举类中，通过枚举值映射得到表名字符串，避免直接字符串替换
• 方案3：走Checkmarx误报标记流程
  如果团队允许对确认的误报做标记，可直接在Checkmarx扫描控制台将该告警标记为「False Positive」，标注理由为：表名仅从内部配置文件读取，无用户可控输入路径，不存在注入风险，标记后后续版本扫描不会再触发该告警。
• 方案4：改用ORM框架的动态表名能力
  如果项目使用MyBatis等ORM框架，可替换原有字符串拼接逻辑，使用框架内置的动态表名能力（如MyBatis的<bind>标签、表名枚举映射），这类实现属于安全的预定义逻辑，扫描工具不会判定为注入风险。

注意：表名无法通过PreparedStatement的参数化占位符实现，所以必须添加显式的校验逻辑才能从代码层面彻底规避注入风险，同时满足静态扫描规则要求。

内容的提问来源于stack exchange，提问作者Kunal