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，再基于报告精准修复