Build an AAP Self-Service Template: Emergency CVE Patch Playbook

Zero-day disclosures do not wait for change advisory boards. When a critical CVE drops, the gap between "we know about it" and "it's patched everywhere" is where breaches happen. At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demonstrated exactly how AAP 2.7 closes that gap: a self-service CVE Patch template surfaced directly in the new Automation Portal, ready to run with a single click.

This article walks through what that template is, why it belongs in a self-service catalog rather than behind a ticket queue, and how you'd structure the underlying playbook and job template to make it safe enough to hand to operators who aren't Ansible experts.

Why CVE Patching Needs a Self-Service Template

Traditional patch workflows route emergency fixes through the same change-management process as routine maintenance. That's appropriate for scheduled patching, but it's the wrong shape for an active CVE. The Automation Portal shown in the AAP 2.7 demo solves this by presenting a gallery of pre-approved templates — each with a "Start" button — so the person responding to the vulnerability doesn't need to know which playbook to run, where it lives in source control, or what extra variables it expects.

The CVE Patch template sits alongside other operational templates in the same catalog, including RHEL - Patch Servers (Maintenance Window), Network - Firewall Remediation, and Branch - Network Health Check. The difference is intent: RHEL - Patch Servers assumes a scheduled window and routine cadence, while CVE Patch is built for the moment a specific vulnerability identifier needs to be closed out immediately, on demand, against a scoped set of hosts.

See also: Build an AAP Self-Service Template: After Hours Branch Access Report

What the CVE Patch Template Does

Per the demo catalog, CVE Patch is described simply as a playbook to run a patch for a given CVE. Functionally, that means the job template accepts a CVE identifier as a survey input, resolves it to the affected package(s) on the target inventory, applies the fix, and reports back — all without the operator touching the CLI, a Git repository, or Tower/controller internals directly.

Designing the Underlying Job Template

Behind that one-click "Start" button in Automation Portal is a standard AAP job template with a survey. The survey is what turns a generic patch playbook into a scoped, safe, self-service action. A minimal survey for this template would prompt for:

• the CVE identifier (free text, validated against a pattern like CVE-\d{4}-\d{4,7})
• the target inventory group or host pattern
• an optional "dry run" flag to check applicability before applying

---
- name: Emergency CVE Patch
  hosts: "{{ target_group | default('all') }}"
  become: true
  vars:
    cve_id: "{{ cve_identifier }}"
    check_only: "{{ dry_run | default(false) }}"

  tasks:
    - name: Refresh package metadata
      ansible.builtin.dnf:
        update_cache: true
      when: ansible_facts['os_family'] == "RedHat"

    - name: Identify packages affected by CVE
      ansible.builtin.command:
        cmd: "dnf updateinfo list security --cve {{ cve_id }}"
      register: cve_lookup
      changed_when: false

    - name: Apply security update for the CVE
      ansible.builtin.dnf:
        name: "*"
        security: true
        state: latest
        update_only: true
      when:
        - not check_only
        - cve_lookup.stdout | length > 0

    - name: Report patch outcome
      ansible.builtin.debug:
        msg: "CVE {{ cve_id }} remediation {{ 'simulated' if check_only else 'applied' }} on {{ inventory_hostname }}"

This is illustrative rather than exhaustive — a production version would branch on ansible_facts['os_family'] for non-RHEL estates, integrate with a vulnerability scanner or patch management source of truth, and emit structured results back to whatever ticketing or SIEM system triggered the response. The point for the Automation Portal integration is that none of that complexity is exposed to the person clicking "Start" — they supply a CVE ID and a target, and the template handles the rest.

See also: Build an AAP Self-Service Template: Backup Network Switch Configs to Git

Guardrails That Make Self-Service Safe

Handing emergency patching to a self-service button only works if the guardrails are enforced by the platform, not by operator discipline. A few practices carry over directly from how AAP job templates are normally hardened:

• Scoped credentials: the job template's machine credential should be limited to the inventory it's meant to touch, so a mistyped host pattern can't fan out beyond intended scope.
• Survey validation: constrain the CVE ID field and the target group field with regex or choice lists rather than free text where possible.
• Check mode first: default the dry-run flag to true, or require an explicit confirmation step, so the first click on an unfamiliar CVE reports impact before it changes anything.
• RBAC on the template, not the playbook: Automation Portal's launch permission is what governs who can click "Start" — keep it aligned with who is actually authorized to make emergency changes.
• Audit trail: every launch through the Automation Portal still produces a standard AAP job run, so the emergency patch is logged exactly like any other automation job.

Key Takeaways

• AAP 2.7's Automation Portal, demoed at Red Hat Tech Day Netherlands 2026, exposes a self-service template gallery where operators click "Start" without knowing playbook internals.
• The CVE Patch template is purpose-built for on-demand, survey-driven remediation of a specific vulnerability — distinct from scheduled templates like RHEL - Patch Servers (Maintenance Window).
• A survey collecting the CVE identifier, target scope, and a dry-run flag is what makes the underlying playbook safe to self-serve.
• Guardrails — scoped credentials, survey validation, check mode, and RBAC on the launch permission — are what let organizations trust operators with a one-click emergency patch button.
• Every self-service launch still produces a standard, auditable AAP job run, so speed doesn't come at the cost of traceability.