基线检查是依据预定义安全标准核查系统配置，确保满足最低安全要求；核心在于持续闭环验证，涵盖策略匹配、关键配置人工核验、扫描—修复—再验证流程及ci/cd卡点嵌入。
定期用漏洞评估工具检查 Web 环境安全基线是否达标，核心不是“扫完就完”，而是把扫描动作变成可重复、可验证、可归档的运维习惯。重点在于：用对策略、盯住配置、闭环验证。
选对工具并配置匹配的基线策略
不要直接跑默认全量扫描。先明确你用的是什么技术栈——比如 Nginx + PHP + MySQL + Redis，就应在工具中启用对应组件的基线模板（如 CIS Nginx 1.18 Benchmark、MySQL 8.0 CIS Level 1）。主流工具如 OpenVAS、Nessus、Tenable.sc 都内置了等保2.0、CIS、PCI DSS 等合规基线包。操作时注意：
- 禁用与业务无关的检测项（例如不启用 Windows 域控策略检查）
- 将“配置类检查项”单独归为一类任务，和漏洞扫描分开执行
- 导出策略配置为 JSON 或 XML，版本化存入 Git，便于回溯和团队共享
聚焦关键配置项，不靠工具“猜”
工具只能比对已知规则，但基线是否真达标，得看它能不能反映真实运行态。以下 4 类配置必须人工核验或加脚本辅助验证：
-
HTTP 响应头：确认是否返回
Strict-Transport-Security、X-Content-Type-Options: nosniff、Content-Security-Policy -
目录与文件权限：Web 根目录下不应有
.env、config.php.bak、backup/等敏感路径可被直接访问（可用curl -I http://yoursite.com/.env快速试） -
中间件管理端口：Redis 的 6379、Elasticsearch 的 9200、Tomcat 的 8005 等是否监听在
127.0.0.1而非0.0.0.0 -
数据库账号权限：应用连接数据库的账号是否仅授予
SELECT, INSERT, UPDATE，而非GRANT ALL或DROP
建立“扫描—比对—修复—再验证”闭环
单次扫描结果只是快照，真正体现基线持续达标的是趋势。建议按周执行固定节奏：
- 每周一凌晨自动触发基线扫描（使用 cron + CLI 工具如
openvas-cli --scan config-baseline.yaml） - 扫描后自动比对上次报告，只输出“新增不合规项”和“已修复项”
- 对高风险配置偏差（如 HTTPS 未启用、目录列表开启），触发企业微信/钉钉告警，并关联到运维工单系统
- 修复后 24 小时内，用 curl 或 Postman 手动复测关键项（例如访问
/phpinfo.php应返回 404，而非页面内容）
把基线检查纳入上线卡点
在 CI/CD 流水线中嵌入轻量级基线校验，比上线后再扫更有效。例如：
- 在 Docker 构建阶段，用
docker run --rm -v $(pwd):/app aquasec/kube-bench:latest install检查容器镜像是否符合 CIS Docker Benchmark - 在 Nginx 配置提交前，用
nginx -t && nginx -T | grep -E "(ssl|listen|autoindex)"自动校验关键指令 - 部署脚本末尾加入
curl -s http://localhost:8080/actuator/env | grep -q "dev" && exit 1，防止测试配置误入生产
