Chainguard brings first-party RHEL 9 and RHEL 10 RPM support to Chainguard OS, joins FINOS

Financial institutions operate some of the most critical infrastructure on the planet. The systems that clear trades, move payments, and underwrite risk can’t afford to go down. The teams that build and secure those systems operate under regulatory scrutiny that most industries can't imagine, and they do it well. The uptime and resilience of global financial infrastructure is genuinely remarkable.

They also run on a lot of technology that can be hard to upgrade or migrate from. Long certification cycles, deep dependencies on specific platforms, and applications compiled against specific libraries and toolchains make it difficult to adopt better options. The result is that some of the most security-conscious organizations in the world are stuck patching on quarterly cycles while the threat landscape moves at machine speed.

Today, we're announcing RPM compatibility for first-party packages built for RHEL 9 and RHEL 10 in Chainguard Containers built on Chainguard OS, addressing a major adoption gap between Chainguard and the enterprise Linux environments where many financial services actually run. We're also joining the Fintech Open Source Foundation (FINOS), bringing Chainguard to the table where the world's largest banks collaborate on open source standards and infrastructure.

First-party RHEL 9 and RHEL 10 RPM compatibility in Chainguard Containers

RPM-based Linux distributions (RHEL, CentOS, Rocky, Alma, and even Azure and Amazon Linux) are the default inside many major banks. Applications are compiled against their libraries, internal tooling assumes RPM package management, and compliance frameworks reference their hardening benchmarks. That's a deep dependency, and it doesn't move quickly.

But that deep dependency also means that when banks need to modernize their software delivery by moving from quarterly patch cycles to continuous remediation, eliminating the CVE backlog rather than triaging it, and producing SBOMs and signed provenance for every artifact, they need solutions compatible with the RPM-based ecosystem they already run. Chainguard Containers are built on Chainguard OS, our cloud-native Linux distribution (built on the open source Wolfi project). Chainguard OS uses APK, not RPM. It tracks upstream sources directly and produces minimal, zero-CVE container images with full provenance. It's the right architecture for secure-by-default software delivery. But for organizations with deep RHEL dependencies (and in financial services, that's nearly all of them), the inability to install RPM packages into a Chainguard OS-based image has been a blocker.

Bridging the metadata gap between RPM and APK

Here's a fact that surprises most people: Chainguard OS already ships the same core libraries that RHEL depends on. The same glibc, the same OpenSSL, the same zlib, built from upstream sources, typically at more current versions. When you try to rpm -i a first-party package built for RHEL into a Chainguard OS-based image, the libraries it needs are physically present on disk, but the install fails because RPM doesn't know they're there. RPM's dependency resolver checks its own database, not the filesystem. In Chainguard OS, the libraries are tracked by APK, and the RPM database is empty. Every Requires: check fails, even when the required .so (shared object) is sitting right next to the binary that needs it.

Existing tools like alien solve this by converting packages from one format to another: unpacking the RPM, rewriting the metadata, and producing a .deb or equivalent. That approach transforms the package, often dropping or flattening dependency declarations in the process, and leaves the question of whether the result actually works up to the user.

We took a different approach. Rather than converting packages or rebuilding anything from source, we built a metadata bridge that makes Chainguard OS's existing libraries visible to RPM's dependency system while leaving the RPM-packaged binaries completely untouched.

The system reads what APK already knows about installed packages and their shared library provides, then translates those capabilities into the RPM equivalents that RHEL packages expect to find: soname references like libcurl.so.4()(64bit), package-name capabilities like curl-libs(x86-64), and versioned symbol sets like libc.so.6(GLIBC_2.34)(64bit) derived by scanning the ELF version definitions in each installed .so. All of this is assembled into a synthetic compatibility RPM and installed to seed the database. After that, rpm -i works normally. The dependency check finds everything it needs, and the binary lands on disk and links at runtime against Chainguard OS's actual libraries.

The result is unmodified RPM packages built for RHEL running on a Chainguard foundation. The RPM is the original artifact, byte-for-byte. The libraries underneath are Chainguard OS's: rebuilt from source continuously, with full provenance, at current versions. The metadata bridge is what makes them speak the same language.

What this means in practice

Teams can install first-party RPM packages built for RHEL 9 and RHEL 10 directly into Chainguard's continuously rebuilt, cryptographically signed, zero-known-CVE container images. If your application ships as an RPM, it installs. If it has RPM dependencies on standard system libraries, the bridge resolves them. If a dependency is missing from the base image, the tooling identifies which Chainguard OS package provides the required soname, installs it, re-seeds, and retries automatically.

To be clear about what this is and isn't: this is not a fork of RHEL or a RHEL rebuild. We're not providing a 1:1 binary-compatible distribution, and we can't promise the exact same experience you'd get on a stock RHEL system. The underlying distribution is different: it's more minimal, more current, and more hardened. Where Chainguard OS's ABI surface matches RHEL's (and for the vast majority of standard library interfaces, it does), this is a drop-in. Where it genuinely diverges, the system fails gracefully at install time rather than silently at runtime. For most enterprise workloads, it just works. For some, there will be integration work, such as a dependency on a library function that Chainguard OS's build intentionally omits, a hardcoded library version, or a script that checks /etc/redhat-release.

We want to be upfront about that. The truth is that work is work you need to be doing anyway, and it doesn't have to be manual. Chainguard's The Guardener agent can automatically identify and resolve most compatibility gaps, and if your organization runs its own AI coding agents, they can do the same work in seconds. Auditing what's inside your container images, trimming unnecessary dependencies, and understanding exactly what your workloads rely on at the system level is exactly the kind of supply chain hygiene that customers, regulators, and security teams increasingly expect as AI-driven threats accelerate. The differences between Chainguard's foundation and a stock RHEL may look like friction at first, but they're really part of the modernization work organizations need today anyway.

What we're providing is an onramp to Chainguard’s security posture through unmodified locally built RPMs running on a hardened, continuously patched foundation, so teams can keep the package ecosystem their applications were built on, and developers can keep the RPM packages they already ship. Underneath, Chainguard builds from source, maintains full provenance, and continuously remediates vulnerabilities.

Beyond the base image: SLAs and Libraries

RPM compatibility enables some workloads built for RHEL to run on a Chainguard foundation, but the foundation itself keeps moving. Chainguard provides an SLA for new upstream software versions. When a new major or minor release ships from an upstream project, we commit to rebuilding, testing, and making it available in Chainguard OS on a defined timeline. For financial institutions that have spent years waiting on their distribution vendor to package a new release or maintaining internal forks to get ahead of the vendor's schedule, this changes the calculus. You get current software with the same provenance and security guarantees as everything else in the catalog.

And containers are only part of the dependency surface. Chainguard Libraries extends the same secure-by-default model to the language package layer: Python, JavaScript, Java, and the ecosystems where most supply chain attacks actually land. Libraries are rebuilt from source with CVE backporting, so teams get patched versions of the packages they already use without waiting for upstream maintainers to cut a new release. Our libraries also ship with malware protection. Every package is analyzed against Chainguard's malware detection pipeline before it enters the catalog. In March 2026, when malicious versions of axios, LiteLLM, and Telnyx hit public registries, Chainguard Libraries customers saw zero impact. Not because we detected the malware faster, but because they were pulling from a catalog where it never existed in the first place.

Why now: the Mythos moment

On April 8, Anthropic announced Claude Mythos Preview and Project Glasswing, a consortium including AWS, Apple, Cisco, Google, Microsoft, NVIDIA, and JPMorgan Chase using Mythos to find and fix vulnerabilities in critical software. Mythos autonomously discovered thousands of high-severity zero-days across every major OS and browser, wrote working exploits, and chained vulnerabilities to escape browser sandboxes. The previous frontier model managed two successful Firefox exploits; Mythos achieved 181.

For financial services, this isn't just a threat. Instead, it's the forcing function for a modernization that's been overdue. The industry averages 74 days to remediate critical CVEs, and 45% of vulnerabilities at large enterprises never get fixed. That was already untenable. Mythos makes it impossible to ignore. When AI can discover and weaponize vulnerabilities faster than any team can triage them, the organizations that come out ahead will be the ones that stopped treating patching as the strategy and started building on foundations that are already patched.

Chainguard OS remediates critical CVEs in an average of 20 hours. Because the Chainguard Factory tracks upstream source rather than CVE feeds, fixes often land before a CVE is even assigned. That's the kind of foundation this moment demands, and RPM compatibility now makes it accessible to the organizations whose production environments are built on RPM-based distributions.

Joining FINOS

The product announcement is one half. The other is where we show up.

FINOS is the Linux Foundation's home for open source collaboration in financial services. Its membership includes the world's largest banks — Citi, Morgan Stanley, Goldman Sachs, RBC, Bank of America, BMO — alongside technology providers like Microsoft, AWS, Google Cloud, and Red Hat. More than 100 member organizations contribute to over 50 projects and special interest groups, building open standards for cloud controls, AI governance, desktop interoperability, and regulatory compliance.

For Chainguard, joining FINOS is about meeting financial services where they are. FINOS provides the neutral ground where open source solutions earn the trust of the most regulated industry on earth. We see natural overlap with work already underway: the DevOps Automation SIG's focus on continuous compliance, the Common Cloud Controls project's standardized security baselines, and FINOS's expanding work on AI governance all connect directly to what Chainguard builds.

Putting it together

Mythos and models like it are pulling zero-days forward in time, making the vulnerability landscape more hostile by the month. Regulatory pressure is mounting, not just to patch known vulnerabilities, but to demonstrate provenance, maintain SBOMs, and prove that your software supply chain is trustworthy end to end. Banks need to move from reactive patching to secure-by-default infrastructure, without ripping out the foundations of their production systems.

RHEL 9/10 RPM shared library compatibility means the practical barrier to adoption, the "we can't use this because everything here is RPM" conversation, is resolved. FINOS membership means we're at the table with the institutions navigating these challenges, contributing to the standards that will define how financial services consume open source.

The window between vulnerability discovery and exploitation has already collapsed. AI is accelerating that collapse. Financial services can't patch its way out of this at calendar speed. What it can do is build on a foundation where patches are already in place; where software is rebuilt from source continuously, where provenance is built in at every layer, and where the security posture of your containers doesn't depend on whether your team saw the CVE advisory before the attacker did.

That's what Chainguard delivers. Now it delivers it with the RPM compatibility that makes it production-ready for the environments where financial services actually run.

Learn more about Chainguard's approach to post-Mythos security, and explore the Chainguard Containers catalog to learn more about how Chainguard can help with financial services workloads.

Red Hat and RHEL are trademarks or registered trademarks of Red Hat, Inc. Chainguard is not affiliated with, endorsed by, or sponsored by Red Hat. Compatibility statements refer to Chainguard’s support for installing certain RPM packages built for RHEL 9 and RHEL 10 into Chainguard OS-based container images and do not mean Chainguard OS is a RHEL distribution, RHEL rebuild, or 1:1 binary-compatible replacement.