堡垒机不检测SQL注入，其核心职责是运维审计与权限控制；SQL注入防护应部署在API网关、反向代理或专用WAF节点，堡垒机仅可作为数据库错误日志的事后分析源。
堡垒机本身不检测SQL注入，别把它当WAF用
堡垒机（如JumpServer、Teleport）核心职责是运维审计、权限控制和会话录制，它不解析HTTP流量、不检查SQL语法、也不拦截UNION SELECT这类payload。强行在堡垒机上加SQL注入检测，等于让门禁系统去查银行卡密码——职能错位，且大概率失败。
真正该介入的位置是：API网关、反向代理层（Nginx/OpenResty）、或专用WAF节点。堡垒机只可能作为日志源，把后端数据库的慢查询、报错日志（如MySQL error: You have an error in your SQL syntax）同步出来做事后分析，但无法实现“持续交付中实时阻断”。
- 如果想在交付链路里加SQL注入防护，优先在CI/CD流水线末尾加
sqlmap -r扫描测试环境接口（见下一条） - 若已部署WAF集群，确保其规则与Jenkins构建版本绑定（例如用
--rule-version=2026.08参数标记规则集），避免测试环境用v4.2而生产用v4.5导致漏检 - 堡垒机日志里出现大量
SELECT * FROM users WHERE id = '1' OR '1'='1'类语句，说明攻击已穿透前置防护，此时该排查WAF配置，而非给堡垒机装插件
sqlmap -r 必须配合真实请求报文，不能只扫URL
Jenkins集成SQL注入检测最可行的方式，是把sqlmap.py作为构建后步骤，用-r req.txt加载实际请求原始报文。仅靠-u "https://test.example.com/api/user?id=1"这种构造式扫描，90%以上会漏掉POST body、Cookie、Header中的注入点。
关键点在于报文必须包含完整上下文：
-
req.txt需含完整的HTTP头（Host、Cookie、Authorization等），否则sqlmap无法复现真实调用场景 - POST请求的body必须保留原始格式（含
Content-Type: application/json及换行），sqlmap依赖此判断参数边界 - 推荐在Jenkins流水线中用
curl -s -D headers.txt -o body.txt "https://test.example.com/api/user?id=1"先抓一次真实响应，再人工补全为合法HTTP报文 - 避免使用
--batch跳过交互——某些注入点需手动确认GET还是POST参数，自动模式可能直接跳过
Jenkinsfile里调用sqlmap要绕过权限和路径陷阱
在声明式流水线中直接写sh 'python sqlmap.py -r req.txt'容易失败，常见卡点有三个：
- Python环境不一致：
sqlmap.py依赖Python 2.7或3.6+，但Jenkins agent默认可能只有Python 3.9且未装pycurl，需显式指定sh 'python3.6 sqlmap.py -r req.txt' - 路径问题：Jenkins工作区是临时目录，
req.txt必须通过archiveArtifacts或copyArtifacts插件提前拉入，不能假设文件已在$WORKSPACE - 超时中断：sqlmap默认超时30秒，复杂注入可能卡住，必须加
--time-sec=120并设timeout: 300防止Jenkins主动kill进程 - 敏感信息泄露：
-v 3会打印完整payload到Jenkins控制台，建议改用--output-dir $WORKSPACE/sqlmap-out并禁止日志归档该目录
检测结果必须关联部署版本号，否则无法追责
sqlmap发现注入漏洞后，输出里只有[*] GET parameter 'id' is vulnerable，但没人知道这是哪个Git commit、哪个Jenkins build触发的问题。必须在调用时强制注入上下文：
- 用
--eval="import os; os.environ['BUILD_ID'] = '${BUILD_ID}'"把Jenkins变量带进sqlmap环境（需sqlmap支持自定义eval） - 更稳妥的做法：在执行sqlmap前，生成
build-context.json，含git_commit、branch、deploy_env字段，让后续报告解析脚本能匹配到具体变更 - 注意：
--risk=3和--level=5虽能提高检出率，但会显著拖慢构建时间，建议仅在nightly构建中启用，非紧急发布走--risk=2 --level=3
真正的难点从来不是跑通命令，而是让每次检测结果能精确对应到某次代码提交——否则修复时连问题引入者都找不到。
