How SWIFT Governs Ansible Automation and Modernizes 2,000 Playbooks

SWIFT runs Ansible automation that touches roughly one third of global GDP every day, so Ansible automation governance is a baseline engineering requirement for them. At Red Hat Summit 2026, SWIFT shared how they’re rolling it out. The plan has three parts: a 2.9 to 2.16 migration of ~2,000 Ansible Playbooks, risk assessment of third-party collections, and policy checks on every Playbook before it reaches production.

Their environment spans tens of thousands of VMs, network devices in production and elevated privileges across production systems. Every Playbook they run is effectively a software supply chain. SWIFT is the secure financial messaging backbone for 11,000+ financial institutions in more than 200 countries.

Suvasish Ghosh, Product Owner for CI/CD Engineering and DevOps Engineering Services at SWIFT, joined Gregor Berginc, CEO of XLAB Steampunk, on stage at Red Hat Summit 2026 . They talked about how SWIFT is using Steampunk Spotter to govern Ansible automation at this scale.

Why automation at SWIFT scale needs governance by design

For SWIFT, security, availability and auditability are not features added on top — they are baseline engineering requirements. Regulatory frameworks codify the expectations, but as Suvasish made clear on stage, governance is by design at SWIFT, not driven solely by regulation.

That stance reflects a simple truth that more and more platform teams are arriving at: automation is production infrastructure, and it must be governed as such. When you run an Ansible playbook, you are executing a software supply chain — collections, modules, roles, Python packages, system packages, the execution environment, the operating system underneath. The playbook itself is just the tip of the iceberg. Errors propagate fast. The blast radius is large.

And yet, until recently, most of the security and compliance attention in IT organizations went to the applications shipping to production. The automation that built and configured everything around them often slipped through.

Suvasish put it directly during the session:

“We spent a lot of time being compliant and secure in our application, but we often don’t pay too much attention to what’s coming into our development environment via Ansible collections and through badly written Ansible scripts. That’s where we started looking at Steampunk Spotter.” - Suvasish Ghosh, Product Owner for CI/CD Engineering and DevOps Engineering Services at SWIFT

Use case 1: A 2.9 → 2.16 modernization that doesn’t break the bank — or the calendar

The first proof point SWIFT shared is the kind of project every Ansible team eventually faces: a major version migration. There are three common ways to update Ansible Playbooks to the latest Ansible version , and at SWIFT the catch is scale.

SWIFT’s pilot benchmark put the cost of doing it manually in plain terms: 100 playbooks would take roughly 100 hours of engineering time to modernize from Ansible 2.9 to 2.16. Across their full estate of ~2,000 playbooks, the manual path was clearly not viable.

The expensive part, it turned out, was not the fix itself. The fix is usually the simplest step. The expensive parts were:

• Identifying which changes were actually needed
• Finding the correct solution from a sprawling and evolving knowledge base
• Validating that the fix was correct before anyone signed off on it

This is exactly what Spotter automates. Spotter identifies required changes automatically, looks up the right solution, validates the fix before flagging it, and auto-rewrites the playbook in the majority of cases. Engineers review and approve — they don’t rebuild from scratch.

Based on comparable projects the projected outcomes are:

• ~2,000 playbooks targeted
• 75–85% auto-fix rate by Spotter
• ~6,500 engineering hours to be saved
• 3-month target for full migration

A controlled, auditable change at scale — without pulling every team in the company into a multi-quarter modernization project.

What changes in an Ansible 2.9 to 2.16 migration

Teams with RHEL 7 or RHEL 8 hosts often move to ansible-core 2.16 because it’s the last release that supports Python 2.7 and 3.6 on managed nodes. Most of the breakage across those seven releases falls into five categories ( porting guides ):

Each fix is small. The time goes into finding every affected task across hundreds or thousands of files and checking that each fix is correct, which is why migrations at scale need a plan.

How to plan an Ansible 2.9 to 2.16 migration at scale

SWIFT’s approach breaks down into six steps that work for any team with hundreds or thousands of Playbooks:

1. Inventory everything. List every Playbook, role and collection, and give each one an owner. Content nobody owns can’t be migrated safely.

2. Pin the target. Agree on the ansible-core version, the Python versions and the execution environment before anyone touches code.

3. Scan the whole estate. Run one scan against the target version to find deprecated modules, missing FQCNs and removed syntax, so you know the real scope before you estimate.

4. Auto-fix, then review. Let tooling handle the mechanical changes. Engineers focus on what’s left, usually logic that relied on old behavior.

5. Test and roll out in waves. Run --syntax-check and --check --diff against a staging inventory, then migrate one team or repository at a time.

6. Keep the check in CI/CD. Scan every new Playbook against the target version so old patterns don’t creep back in.

Spotter covers steps 3, 4 and 6. It flags what needs to change, rewrites the Playbook automatically in the majority of cases, and runs the same check in your pipeline. For a full walkthrough, see our complete guide to Ansible upgrade and migration.

Use cases 2 & 3: From one-off project to permanent guardrail

The migration win is one story. The more interesting part for any platform team is what happens after.

Spotter is being embedded into two further parts of SWIFT’s automation lifecycle:

Assessing third-party Ansible collections before internal distribution. The goal here is to unlock safe use of community Ansible collections. Spotter generates risk-based reports on Galaxy content — collections like community.mongodb or containers.podman — so SWIFT can approve high-value collections with confidence, demonstrate compliance to internal auditors, and expand their automation footprint without growing the attack surface.

Standardizing and securing internal Ansible usage. Every developer playbook gets scanned by Spotter before it reaches production — continuously, across every repo. The aim is real-time, auditable oversight: vulnerabilities, misconfigurations and standards violations caught proactively, without relying on manual spot-checks. The same security checks, the same policy engine, the same SBOM and vulnerability analysis. Playbooks stay aligned with evolving best practices and Ansible releases. See what we found in AI-generated Ansible Playbooks in our quarterly AI model report.

Feedback loops close the system: blocks and findings flow into Jira and ServiceNow, security signals into SIEM tooling like Splunk or QRadar. Compliance reports map directly to FFIEC, PCI-DSS and SOC 2.

The four pillars of SWIFT’s Ansible automation governance

If you take one framework away from the session, take this one. SWIFT’s approach to automation governance rests on four pillars — and they are reusable far beyond financial services:

1. Visibility. Know what is actually executed, dependencies included. Remove the blind spots.
2. Consistency. Same rules for all teams. No special cases. No tribal knowledge.
3. Policy as code. Human memory does not scale. Expectations must be machine-readable, and policies have to evolve with the platform. In practice, that means rules like: only approved collections, no privileged shell tasks in production, no hard-coded secrets and no deprecated modules. Spotter enforces them with 200+ built-in checks and custom policies .
4. Feedback loops. Early, automated signals in developer context — before production, not after.

Framed this way, governance supports velocity: teams ship changes faster when the checks run automatically, before production.

What this means for your automation

A few honest takeaways from the SWIFT story that apply whether you run 50 playbooks or 5,000:

• Automation is production infrastructure — govern it as such.
• Modernization at scale is a controlled, auditable change — not a heroic effort.
• Supply-chain assessment is non-negotiable for third-party Ansible content.
• Standardization and qualification enable safe reuse at scale.
• Spotter enables safe velocity by strengthening automation governance, not slowing it down.

If you are staring at your own version of “2,000 playbooks, three months from now” — or just noticing that the Ansible content in your development environment is getting less attention than the apps it deploys — there is a faster way to find out where you stand.

Get a free Spotter script assessment

Curious what Spotter would find in your Ansible or Terraform scripts? Book a free script assessment and our team will scan your scripts for security risks, compliance gaps and modernization opportunities — and walk you through what we find.

👉 Reserve your free script assessment

Frequently Asked Questions

What is Ansible automation governance?

Ansible automation governance means defining rules for what automation code may do and enforcing them consistently before it runs. Teams usually write these rules as policy-as-code and check them in CI/CD.

How long does an Ansible 2.9 to 2.16 migration take?

It depends on the number of Playbooks and how much of the fixing you can automate. Most of the time goes into finding and validating changes rather than making them. With automated detection and rewriting, SWIFT is targeting about three months for ~2,000 Playbooks.

How do you assess third-party Ansible collections for risk?

Scan each collection for unsafe patterns, risky dependencies and known CVEs before it enters your internal automation hub. Approve it only if it passes.