Ansible自动化修复漏洞的关键是构建可重复、可验证、可回滚的标准化流程。需按漏洞类型选择适配方式：软件包升级用yum/apt模块，配置加固用copy/template+backup:true，二进制替换校验SHA256，临时封堵加状态检查；Playbook必须含前置检查、主操作block、rescue兜底、后置验证四段；配合ComplianceAsCode/content生成可信剧本，并分批执行、禁用冗余facts、防注入。
用 Ansible 自动化修复系统漏洞，关键不是“跑命令”，而是把安全响应变成可重复、可验证、可回滚的标准化动作。几百台机器靠人工打补丁不现实，但盲目推送脚本更危险——一次路径写错或配置填错，可能批量中断服务。
明确漏洞类型，匹配对应修复方式
不同漏洞需不同处理逻辑，Ansible 本身不判断 CVE，但必须适配落地手段：
-
软件包升级类（如 OpenSSH、Polkit、OpenSSL）：优先用
yum、apt或dnf模块，依赖自动处理、版本锁定可靠；避免手动编译覆盖，除非官方源确实无更新包 -
配置加固类（如禁用 pprof、限制 SSH 登录、调整 PAM 策略）：用
copy替换配置文件，或template动态生成；配合systemd模块 reload/restart 服务，务必启用backup: yes -
二进制替换类（如 node-exporter 热修版、自研 agent 补丁）：用
copy+file设置权限，必须通过checksum参数校验 SHA256，并保留原文件备份 -
临时封堵类（如 iptables 封 IP、禁用内核模块）：用
iptables或modprobe模块；执行前加command检查当前状态，防止重复操作或误封
Playbook 必须包含验证与回滚机制
只写“安装→重启”是生产环境大忌。一个可用的漏洞修复 Playbook 至少含四段：
-
前置检查：用
command或uri检查服务是否运行、端口是否监听、关键进程是否存在；失败则用failed_when跳过该节点 -
主操作块：用
block包裹所有变更任务（如下载包、安装、改配置、重启） -
失败兜底：在
rescue中恢复备份文件、回退服务、发送告警；所有copy和template都启用backup: true -
后置验证：调用
uri访问健康接口，或用shell执行ss -tlnp | grep :22确认 SSH 仍存活；验证失败触发fail模块并标记节点为 failed
分批执行，降低风险与负载
全量并发会压垮控制机，也可能触发目标机 SSH 连接限流或服务雪崩：
- 按业务角色分组执行，例如：
ansible-playbook fix-openssh.yml --limit web_servers，再切db_servers - 每组内设
serial: 3，每次只操作 3 台；全部通过验证后再推进下一批 - Playbook 开头加
gather_facts: false（除非真需要 facts 判断系统类型），跳过耗时的事实收集 - 关键任务加
timeout: 30和retries: 2，防网络抖动误判 - 避免用
shell模块拼接变量执行敏感命令，防止注入；需管道/重定向时，优先用script模块传本地脚本
借助合规项目快速生成可信 Playbook
ComplianceAsCode/content 提供了经安全专家编写和测试的现成方案：
- 克隆项目：
git clone https://gitcode.com/gh_mirrors/cont/content - 构建对应系统的 Playbook，例如为 RHEL 9 生成 CIS 合规修复剧本：
./build_product --ansible-playbooks rhel9 - 生成的 Playbook 位于
build/ansible/目录下，可直接用于扫描后修复，也可按需裁剪 - 配合 OpenSCAP 扫描：
oscap xccdf eval --profile cis --results scan-results.xml --report scan-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml，再基于报告精准修复
