必须用 OpenSCAP + CIS profile，因其符合等保及金融、政务等审计要求的 CIS/NIST/GB/T 标准，内置60+项版本适配规则（如MySQL 5.7/8.0差异），支持XCCDF可审计输出、时间戳报告与OVAL结果追溯，而自写SQL易漏项、无标准基线、难覆盖版本特异性检查。
直接用 oscap 配合 CIS MySQL Benchmark Profile 定时跑扫描，是目前最稳定、可审计、能落地的方案。其他工具如 sqlmap 或 nmap 是攻击向探测，不适用于合规检查；纯 SQL 脚本虽轻量，但覆盖项少、难追溯、无标准基线支撑。
为什么必须用 OpenSCAP + CIS profile 而不是自己写 SQL
因为等保和行业审计（如金融、政务）认的是 CIS、NIST、GB/T 28448 等标准条目，不是“你觉得哪里像漏洞”。oscap 的 mysql57-cis 或 mysql80-cis profile 已把 60+ 项配置要求映射成机器可执行的 XCCDF 规则，比如：
- 检查
skip_networking=OFF是否启用（对应“禁止禁用网络”） - 验证
validate_password.policy是否 ≥ MEDIUM - 确认
mysql.user表中是否存在空密码或匿名用户
自己写 SQL 很容易漏掉版本特异性判断（比如 MySQL 8.0 的 caching_sha2_password 插件是否启用），而 CIS profile 内置了版本分支逻辑。
oscap 扫描必须绕开的三个连接陷阱
oscap 只支持 TCP 连接，不识别 Unix socket，且 cron 环境下无法加载 shell 配置。常见失败就卡在这三处：
- 别用
--socket=/var/run/mysqld/mysqld.sock，必须显式指定--host=127.0.0.1 --port=3306 - 别依赖
~/.my.cnf，cron 不读它；改用--user=root --password=xxx，或更安全的MYSQL_PWD=xxx（注意该变量值不能出现在命令行历史里，且存放密码的文件权限必须是600） - MySQL 账户需有
SELECT权限访问mysql.user、mysql.db、performance_schema——oscap会查performance_schema.variables_info获取动态变量值，没这个库或没权限就直接报错退出
让 cron 任务真正长期有效不掉链子
关键不在“能不能跑一次”，而在“每次跑的结果是否可比、可追溯、不被覆盖”：
- 输出路径必须带时间戳：
oscap xccdf eval --profile xccdf_org.cisecurity.benchmarks_profile_Level_1_Server --results /var/log/mysql-scan-$(date +\%F-\%H).xml --report /var/log/mysql-scan-$(date +\%F-\%H).html mysql57-cis.xml - 加
--oval-results参数导出原始 OVAL 结果，方便后续用 ELK 或自定义脚本做趋势分析 - 在 cron 中加简单健康检查：扫描前先
mysqladmin ping -h127.0.0.1 -P3306 -u root -p$PASS &>/dev/null || exit 1，避免 MySQL 挂了还继续生成空报告 - 别用
@daily，改用0 2 * * *（每天凌晨 2 点），避开备份、归档等高负载时段
最容易被忽略的一点：profile 必须和 MySQL 版本严格匹配。给 MySQL 5.7 装 mysql80-cis，会导致大量误报（比如把 default_authentication_plugin=mysql_native_password 当成违规）；反过来，MySQL 8.0 用 mysql57-cis 又会漏掉 caching_sha2_password 相关检查。版本号得从 mysql --version 和 SELECT VERSION() 双重确认，不能只看包名。
