Container security's cheapest control is shipping less software, not scanning faster

Traefik Labs is arguing that container security has the wrong control point, and that the fix is to ship fewer components so fewer vulnerabilities exist to triage ^[4]. That argument matters because detection is still the default: theCUBE Research's 2026 study found 58% of respondents use vulnerability scanning as a software supply chain security control, while 47% name software supply chain security a top investment priority ^[2][3].

The complaint about the status quo is mechanical, not rhetorical. Scan, identify, patch, repeat has been the operating cycle for years, and rising vulnerability volume plus regulatory requirements pushing deeper into delivery workflows are making it harder for engineering teams to sustain ^[1]. Scanners remain useful, but scanning does not change the size of the attack surface underneath it ^[5], and every dependency packaged into an image adds another component that must be scanned, tracked, patched and documented ^[6]. Sudeep Goswami, chief executive of Traefik Labs, framed it as a plumbing question on theCUBE Research's AppDevANGLE podcast: "You can buy a faster mop, but somebody has to stop and ask: Where is the water coming from in the first place?" ^[19][18] His narrower point is that "the best a scanner is going to be able to do is to tell you faster about a problem that you still have to fix" ^[25].

Application binaries are traditionally packaged alongside operating system libraries, shells, package managers, utilities and other supporting components ^[7]. Goswami says many of the vulnerabilities Traefik encounters come from that surrounding software rather than the application binary itself ^[8], and puts the split at roughly 80% of published CVEs being noise and 20% being relevant ^[9]. Distro Zero is Traefik's attempt to remove that dependency surface and deliver the application as a self-contained binary ^[10]; according to Goswami the aim is not to retire scanners but to shrink what scanners and security teams have to manage ^[11].

The distinction he draws with distroless images is the operationally useful part. Distroless already strips shells, package managers and common Linux utilities, which makes it harder for an attacker to operate inside a compromised container ^[12], but those images can still carry C libraries, dynamic linkers and cryptographic libraries that bring their own vulnerabilities ^[13]. "Fundamentally, what distroless does is it removes the toolkit that an attacker could use once they get into an environment," Goswami said. "It doesn't remove the code base or the set of things that allow them in in the first place." ^[14] It is the same logic as the memory-safe language guidance he points to: eliminate classes of vulnerability rather than chase instances ^[15].

The compliance side reinforces the packaging argument rather than the scanning one. Fifty-four percent of organisations cite NIST frameworks as a regulatory pressure affecting release engineering and 46% point to the EU Cyber Resilience Act ^[16][17], and since every packaged dependency is another item to document, a smaller artifact is a smaller documentation burden ^[24].

Two caveats belong in the evaluation. The published account contains no measured reduction in CVE count, patch load or triage hours attributable to Distro Zero ^[22], and the only person advocating the approach is the chief executive of the company commercialising it ^[21]. Worth watching: independent before-and-after numbers from teams that have migrated, and clarity on which languages and workloads can actually be delivered as a single self-contained binary, which the source does not specify ^[23]. Also worth watching is the gap between the 58% who scan and the 47% who fund supply chain security as a priority ^[20], because attack surface reduction is a build-time change that has to be paid for out of platform engineering time, not a scanner licence.