SQL注入在云原生环境中依然高发，根本原因在于用户输入与SQL代码仍被直接拼接，而容器化、Service Mesh等新技术既不自动过滤输入，也不阻止动态SQL执行；大量微服务DAO层仍使用${}、+或String.format拼接SQL，PreparedStatement在多租户路由、动态ORDER BY、不定长IN列表等场景下根本无法应用，WAF和Service Mesh对JSON字段操作、文件路径拼接、ConfigMap模板注入等非标准上下文失效，且CI/CD流水线普遍缺失静态扫描与白名单校验机制。
因为云原生没改变SQL注入的根本成因：用户输入和SQL代码依然被混在一起拼接，而开发者仍在用${}、+、String.format往SQL里塞变量——容器化、Service Mesh、K8s Ingress这些新东西，既不自动过滤输入，也不阻止Statement.execute()执行拼出来的语句。
云原生应用照样拼SQL字符串
很多人误以为上了K8s或用了Sidecar就“安全了”，其实只是部署方式变了，业务代码没变。大量微服务在DAO层仍直接拼接SQL：
-
String sql = "SELECT * FROM " + tableName + " WHERE id = " + req.getId();—— 表名+ID全来自请求参数 - MyBatis里写
SELECT * FROM ${tableName} WHERE status IN (${statusList})——${}不走预编译，等同于+拼接 - Spring Boot + JPA中调用
entityManager.createNativeQuery(rawSql).getResultList()，而rawSql是拼出来的
PreparedStatment在云原生上下文里照样失效
云原生常见动态场景，让PreparedStatement根本用不上：
- 多租户系统按
tenant_id路由到不同库/表，FROM user_tenant_123中的数字必须拼接，不能参数化 - 监控报表服务支持任意字段排序：
ORDER BY ?会报错，只能拼"ORDER BY " + sanitize(sortField) - 批量导出时IN列表长度不确定：
WHERE id IN (?, ?, ?, ...)需提前知道个数，而前端传来的ID数组长度是运行时才知道的
WAF和Service Mesh无法拦截非标准上下文注入
云环境里WAF常部署在Ingress层，但它只拦URL和Body里的典型payload（如' OR 1=1），对以下情况完全无效：
- PostgreSQL JSON字段操作：
WHERE data->>'name' = 'admin' || '1'='1'，||是合法连接符，不是注入关键词 - MySQL
LOAD DATA INFILE '/tmp/' || @user_input，文件路径拼接绕过所有WAF规则 - K8s ConfigMap挂载的SQL模板文件里含
${env}占位符，启动时由initContainer替换——这发生在WAF之后、DB连接之前
CI/CD流水线里缺静态扫描和白名单校验环节
很多团队把安全左移挂在嘴上，但流水线里既没跑semgrep查execute(.*\+)，也没强制要求动态表名列名必须走白名单校验：
- 没配置
checkmarx或sonarqube扫描Statement/createNativeQuery调用点 - ORM中误用
text()（SQLAlchemy）、raw()（Django）后，没有配套的正则校验：Pattern.compile("^[a-zA-Z_][a-zA-Z0-9_]*$").matcher(input).matches() - helm chart里用
{{ .Values.db.tableName }}注入SQL模板，却没做required校验或枚举约束
真正卡住防线的，从来不是“会不会用PreparedStatement”，而是“哪段代码根本没法用它”——云原生放大了这类场景，也放大了校验缺失的后果。
