Container security is moving from vulnerability detection to attack surface reduction

Container security has spent years operating around a familiar cycle: scan, identify vulnerabilities, patch and repeat. But as the volume of vulnerabilities grows and regulatory requirements move deeper into software delivery workflows, that model is becoming increasingly difficult for engineering teams to sustain.

TheCUBE Research’s 2026 research found that 58% of respondents use vulnerability scanning as a software supply chain security control. At the same time, 47% identify software supply chain security as a top investment priority, signaling that organizations recognize the problem but are still heavily dependent on detecting vulnerabilities after they enter the software stack. 

In the latest episode of theCUBE Research’s AppDevANGLE podcast, I spoke with Sudeep Goswami, chief executive officer of Traefik Labs, about an alternative approach: reducing the software included in container infrastructure so that fewer vulnerabilities exist in the first place. Traefik is pursuing that strategy through Distro Zero, an approach designed to strip away operating system components and dependencies that aren’t necessary to run the application.

“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,” Goswami said. “You can buy a faster mop, but somebody has to stop and ask: Where is the water coming from in the first place?”

Reducing vulnerabilities before they reach the scanner

Vulnerability scanners remain an important part of software supply chain security, but scanning does not change the size of the underlying attack surface.

That distinction becomes increasingly important as vulnerability volumes rise. Every dependency packaged into a container can introduce another component that must be scanned, tracked, patched and documented.

Traefik’s approach starts by asking whether all of those components need to exist in the production artifact at all. 

Application binaries are traditionally packaged alongside operating system libraries, shells, package managers, utilities and other supporting components. According to Goswami, many of the vulnerabilities Traefik encounters originate from that surrounding software rather than the application binary itself.

“What we’re finding is that the noise factor is huge,” he said. “It’s almost like that 80/20 analogy … 80% of the CVEs that are coming out are noise, and the 20% is what’s really relevant.”

Distro Zero attempts to remove that surrounding dependency surface and deliver the application as a self-contained binary. The goal isn’t to make vulnerability scanning obsolete, but to reduce what scanners and security teams must manage.

Distroless does not mean dependency-free

The distinction between traditional distroless containers and what Traefik calls Distro Zero is important.

Distroless container images already reduce attack surface by removing tools such as shells, package managers and common Linux utilities. That can make it more difficult for an attacker to operate inside a compromised container.

But those images may still depend on components such as C libraries, dynamic linkers and cryptographic libraries. Those dependencies remain part of the runtime environment and can introduce their own vulnerabilities.

“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.”

For platform engineering and application security teams, that changes the conversation from simply minimizing tooling inside an image to understanding the complete runtime dependency chain.

It also reflects the growing attention around memory safety. Goswami pointed to guidance encouraging organizations to adopt memory-safe languages where possible as software supply chain security increasingly focuses on preventing entire classes of vulnerabilities rather than continually detecting individual instances.

Compliance moves into the software delivery pipeline

Attack-surface reduction is becoming more relevant as regulatory requirements increasingly intersect with engineering workflows. Fifty-four percent of organizations cite NIST frameworks as a regulatory pressure affecting release engineering, while 46% point to the European Union Cyber Resilience Act.

That means compliance can no longer remain isolated inside security and legal organizations. Developers and platform teams increasingly need to account for cryptographic requirements, software dependencies, vulnerability management and artifact provenance as part of CI/CD.

Goswami pointed specifically to the transition toward FIPS 140-3 requirements and the EU CRA as examples of why enterprises need to think beyond solving individual compliance requirements independently.

Rather than selecting separate infrastructure for cryptographic compliance, vulnerability reduction and other regulatory requirements, the larger architectural opportunity is to consolidate those requirements where possible.

“If there was a way to start with the right Distro Zero framework, which also gives FIPS 140-3 compliancy and lets you deal with other regulatory guidelines like the EU CRA, that would be a great architectural choice,” Goswami said.

The underlying issue is operational complexity. Every additional security product, runtime dependency and infrastructure artifact creates another lifecycle for engineering and security teams to manage.

The hidden operational cost of software artifacts

The operational complexity becomes particularly visible through software bills of materials.

Each additional artifact introduces its own SBOM, dependency inventory, vulnerability-management process and potentially another security or compliance review. As enterprises add API gateways, AI gateways and Model Context Protocol infrastructure, those requirements can multiply quickly.

This is where Traefik’s broader architecture becomes relevant. The company is consolidating ingress, API gateway, AI gateway and MCP gateway capabilities into a common binary rather than treating them as separate infrastructure products.

Goswami described a model in which organizations deploy and certify the binary once and then activate additional functionality through licensing as their architecture evolves.

“What if there was a unified binary that you deploy once, you certify once, you understand the SBOM, all the dependencies initially upfront?” he said. “As you go through this journey of incremental capabilities, that just becomes a license unlock rather than a binary upgrade.”

For enterprise platform teams, the potential benefit is not simply having fewer binaries. It is reducing the number of security reviews, dependency inventories and operational processes that accompany them.

AI is redefining the gateway

The timing matters because the role of application gateways is also expanding. Historically, ingress controllers and API gateways served as the front door to applications and APIs. AI introduces two additional types of traffic: models and agents.

Organizations are beginning to deploy AI gateways for model interactions and MCP gateways for connections between agents, tools and enterprise data. Each new layer creates another potential security enforcement point and another infrastructure component to operate.

“Traditionally, it’s been APIs, but now you are adding two more characters to this play, which are agents and models,” Goswami said.

That evolution makes consolidation increasingly relevant. Rather than building separate gateway stacks for APIs, models and agents, organizations may look for common policy and security layers capable of governing all three.

It also expands the meaning of software supply chain security. The concern is no longer only which packages are bundled into an application. Teams must consider the infrastructure through which APIs, AI models and autonomous agents communicate.

The bottom line

The vulnerability scanner isn’t going away. But relying on scanning as the primary answer to software supply chain security is becoming increasingly difficult as dependency counts, regulatory requirements and application architectures expand.

Attack-surface reduction offers a complementary strategy: remove unnecessary components before they become vulnerabilities that security teams need to discover, prioritize and patch.

For developers and platform teams, the larger lesson extends beyond containers. Every dependency and infrastructure artifact creates operational and security obligations throughout its lifecycle. As APIs, models and agents converge on shared infrastructure, minimizing that surface could become as important as monitoring it.

Traefik’s Distro Zero approach represents one attempt to shift the security model upstream, from finding vulnerabilities faster to eliminating portions of the software surface where those vulnerabilities can exist.

Here’s the complete conversation I had with Sudeep Goswami, part of theCUBE Research’s AppDevANGLE podcast series:

Image: SiliconANGLE