Traefik Hardened Secure Image
Distroless Means Less. We Ship Zero.
Every hardened gateway image is at best "distroless": someone else's C substrate underneath and bolt-on FIPS, a swapped crypto module with no application changes behind it. Traefik ships as the Distro Zero image: one memory-safe Go binary with FIPS 140-3 enforced inside it, inert data, and zero third-party executable content.
Distro ZeroImage
Memory-Safein Go
FIPS 140-3Validated Crypto
Airgap-Ready
One Binary, Proxy to Platform
TRAEFIK LABS IS TRUSTED BY LEADING ENTERPRISES WORLDWIDE





















































The Directive
Why Runtime Security Matters Now
The vulnerability curve is no longer a background trend, and 2026 is bending it steeper. 35,364 CVEs were published in the first half of 2026 alone, already more than any year before 2024 and a 49.5% jump over the same period last year. A new CVE now lands every 7.4 minutes, and the year is projected to close near 66,000, the largest total in history. Attackers have closed the gap from the other side: exploitation now routinely begins before a patch even exists, with roughly a third of known-exploited vulnerabilities attacked on or before their disclosure day.
Meanwhile, regulatory clocks are running on both sides of the Atlantic. CISA and the FBI named memory-unsafe languages a product security bad practice for software serving critical infrastructure, prioritizing network-facing code and code that handles cryptography. A gateway is precisely both. And FIPS 140-2 certificates are moving to the NIST Historical List, forcing a re-validation of the cryptography underneath regulated workloads. In Europe, the Cyber Resilience Act's (CRA) requirements make documented due diligence on every third-party component a legal obligation.
You cannot out-patch a curve like this. The durable answer is to shrink what must be patched at all: remove the inherited OS layer where most findings originate, remove the memory-unsafe substrate that produces the severe ones, and keep what remains small enough to actually defend.
Four Dates, One Runtime Decision
January 1, 2026
Passed
CISA and FBI date for software manufacturers to publish memory safety roadmaps. Vendors on memory-unsafe cores now face years of public migration.
September 11, 2026
Imminent
EU Cyber Resilience Act (CRA) vulnerability and incident reporting obligations begin.
September 21, 2026
Imminent
FIPS 140-2 modules move to the NIST CMVP Historical List. Stacks resting on 140-2 certificates must re-validate their cryptographic story.
December 11, 2027
Near Future
Full CRA compliance becomes mandatory, with fines up to 15 million euros or 2.5% of global turnover.
35,364
CVEs published in H1 2026 alone, more than any full year before 2024
7.4 Minutes
Between new CVEs in 2026, a 49.5% jump year over year
~66,000
Projected CVEs in 2026, the largest year on record
Sources: CVE Program H1 2026 data · FIRST 2026 Mid-Year Vulnerability Forecast · Mandiant M-Trends 2026 · CISA · NIST CMVP
The Challenges
Distroless Alone Is Not Enough
The market is converging on smaller images, and that is the right direction. But stripping a container only changes what surrounds the code. It cannot change what the code is made of. Even the flagship "distroless" images still ship glibc, libssl, and Debian base files. Generic hardened rebuilds inherit the same limit.
Less is progress. Zero is the goal.
Hidden Substrate
A Distribution in Miniature
A runtime built in C or C++ stripped of its operating system must still carry the OS substrate to run: a full C library, the dynamic linker, a system cryptographic library, and a dozen supporting shared components. None written by the vendor, all memory-unsafe, each with its own upstream, cadence, and CVE feed. In January 2026 alone, OpenSSL patched twelve vulnerabilities in a single release, one of them a critical pre-auth stack overflow in certificate parsing.
Vulnerability Class
Memory-Unsafe Cores
Studies at major software companies have repeatedly linked roughly 70% of severe vulnerabilities in large C and C++ codebases to memory safety defects. A smaller image around a memory-unsafe core is a smaller box around the same class of risk.
Compliance Risk
Bolt-On FIPS
Most gateway images delegate every cryptographic operation to a system OpenSSL the vendor neither writes nor patches. Many still rest on FIPS 140-2 certificates headed to the NIST Historical List. And "FIPS-ready" too often means exactly one change: the crypto module was swapped, and the application above it was never adapted or enforced against it.
40+
OpenSSL CVEs patched since January 2025, including a CVSS 9.8 stack overflow exploitable before any authentication
11+
glibc CVEs in the same window, including privilege escalation through the dynamic loader
0
of them ever applied to a Distro Zero image: no OpenSSL, no glibc, no substrate
Sources: OpenSSL Security Advisories · GNU C Library security advisories · NVD
The Solution
One Hardened Binary from Proxy to Platform
Every security property of the Traefik hardened runtime traces to a single architectural fact: the entire data plane is one static, memory-safe binary. The cryptography is inside it. The dependencies are compiled into it. Nothing beneath it belongs to someone else.
A Typical "Distroless" Gateway Image
The OS is gone. Its substrate isn't.
gateway core (written in C)
glibc + dynamic linker
libgcc / libstdc++
system OpenSSL (all cryptography)
pcre2 (regular expressions)
zlib (compression)
libyaml (configuration)
ncurses + libedit (terminal)
libxcrypt, locale, baselayout…
A dozen-plus shared C components, patched by third parties on their own schedules.
The Traefik Distro Zero Image
The image is a single Go binary.
$ docker export traefik-hub-image | tar tv | grep '^-..x'-rwxr-xr-x ... traefik-hub
That's the whole image. Written, hardened, and supported by the same team, end to end.
Memory-Safe
FIPS 140-3 Inside
Vendor-Built
One SBOM
Distro Zero*, Not Distroless
Distroless removes the package manager and the shell, then keeps the C substrate underneath. The Distro Zero image keeps nothing: one binary, one trust bundle, zero third-party executables. What a scanner reports maps to code we wrote and stand behind.
Memory-Safe by Construction
Written entirely in Go since the first commit a decade ago. The vulnerability class that dominates severe findings in C-based network software does not exist at the language level, and there is no C substrate beneath the binary. No roadmap needed. No debt carried.
FIPS 140-3 at the Application Layer
Cryptography routes through the Go Cryptographic Module v1.0.0, FIPS 140-3 validated (CMVP #5247), implemented inside the binary and maintained in the source by the team that builds the proxy. The FIPS boundary and the memory-safe boundary are the same.
Proxy to Platform by License
The same hardened binary runs as a drop-in proxy and unlocks API Gateway, AI Gateway, MCP Gateway, and API Management by license. No binary swap, no migration, no re-validation. The posture your security team approved carries unchanged as you grow.
* distro zero (adj.)
A container image that ships zero third-party executable content. No shared objects, no libc, no dynamic linker, no shell, no package manager: nothing a distribution would supply. One vendor-built binary, plus inert data such as the standard trust bundle.
Key Benefits
A Posture That Holds Everywhere You Run
Secure by Construction
Clean posture from day one: a scanner surface stripped to code the vendor writes, audits, and supports, with no inherited OS findings to triage away.
Memory safety end to end: from the network socket to the cryptographic boundary, with no memory-unsafe substrate anywhere in the image.
Validated cryptography at the source: FIPS 140-3 enforced at the application layer, not repackaged from public inputs by a third party.
One answer to the regulatory questions, from CISA to the CRA: the memory safety roadmap is one sentence, and the FIPS 140-2 sunset is already answered.

Secure Wherever It Lands
Airgap-ready by design: a self-contained artifact with offline licensing, no runtime fetches, no SaaS control-plane dependency, delivered through a private channel rather than a public registry.
One artifact across the estate: statically linked, taking nothing from the host. The VM deployment and the container deployment are the same file, with the same memory safety, the same FIPS boundary, one SBOM, one provenance.
No dependency surface added to the host: deployment on a virtual machine is a single signature-verifiable file, with no package tree pulled into the OS.
Any cloud, any datacenter, the edge: no dependency on a particular distribution, kernel module, vendor cloud, or connectivity assumption, ready for sovereignty and data residency requirements.

Supported Like It Matters
A person, not a prompt: a distroless runtime intentionally has no shell for live debugging, so that capability is replaced by a named team on standby.
Prioritized remediation of severe vulnerabilities, from the team that writes the code, on the vendor's timetable rather than an upstream's.
Upgrade and cutover validation scheduled against your own environment, plus release-candidate validation ahead of general availability.
Reference architecture review so the hardened posture is deployed the way it was designed to run.

The Comparison
Assembled Security vs Intrinsic Security
| Assembled runtime | Traefik hardened runtime |
|---|---|
| Beneath the app | |
| Borrowed minimal distribution supplying a C substrate of shared libraries | Nothing. Distro Zero: the image is the binary. |
| Application code | |
| Memory-unsafe C or C++ core, now subject to public memory safety roadmaps | Memory-safe Go, end to end, since the first commit |
| Cryptography | |
| Delegated to a third-party system library, often on aging FIPS 140-2 certificates | Go Cryptographic Module v1.0.0, FIPS 140-3 validated (CMVP #5247), inside the binary |
| Who fixes a CVE | |
| The library's upstream, relayed through the distribution, eventually the vendor | The team that wrote the code, in the next build |
| Disconnected operations | |
| Strains against cloud control planes and runtime fetches | Same binary, same posture, offline licensing, private delivery |
| VM estate | |
| Links the host's C and crypto libraries; posture varies with every host | The same statically linked binary, taking nothing from the host; memory safety and the FIPS boundary travel with it |
| Capability growth | |
| New artifact, new validation cycle | Same binary, unlocked by license: API, AI, and MCP Gateway plus API Management |
You install one hardened, supported binary, you get a clean security posture from day one, and you unlock what you need over time with a license, not a migration.
Sudeep Goswami
Chief Executive Officer, Traefik Labs
Ready to Ship Zero?
Get the Distro Zero image and a security posture that stays clean from your first proxy to a full API, AI, and MCP platform.


