Software Supply Chain Security Is Becoming an Architecture Problem
For years, enterprise container security has followed a familiar pattern: scan, patch, repeat.
That model made sense when vulnerability volumes were lower and security teams had enough time to respond manually. But the scale has changed. In 2026 alone, more than 35,000 CVEs were reported in the first half of the year, while regulatory requirements such as NIST frameworks and the EU Cyber Resilience Act are pushing security deeper into release engineering.
According to theCUBE Research’s data, 58.4% of respondents said vulnerability scanning is implemented as a software supply chain control. At the same time, 47.4% identified software supply chain security as a top investment priority. The problem is that scanning still happens after risk already exists.
In this episode of AppDevANGLE, I spoke with Sudeep Goswami, CEO of Traefik Labs, about why container security needs to move beyond finding vulnerabilities faster and toward reducing the attack surface before those vulnerabilities can become operational problems.
Our conversation explored the difference between traditional distroless containers and Traefik Labs’ Distro Zero approach, the growing impact of regulatory deadlines on engineering teams, and why gateways are becoming a unified control point for APIs, AI models, MCP traffic, and agents.
Vulnerability Scanning Does Not Reduce the Attack Surface
One of the most important themes from the discussion is that vulnerability scanners are doing exactly what they were designed to do—but that does not mean they solve the underlying problem. As Goswami explained, scanners identify risk after vulnerable components are already present. “The best a scanner is going to be able to do is tell you faster about a problem that you still have to fix,” said Goswami.
He compared the current model to cleaning up water without finding the source of the leak. “You can buy a faster mop,” Goswami said. “But somebody has to stop and ask, where is the water coming from in the first place?”
That framing gets at the core limitation of vulnerability-centric security. Many container images include far more than the application binary itself. They may also include shells, package managers, C libraries, dynamic linkers, cryptographic libraries, and other runtime dependencies. Every additional component creates another potential vulnerability surface.
According to Goswami, much of the CVE volume enterprises manage today comes from this surrounding software rather than the application itself. “What we’re finding is that the noise factor is huge,” he explained. “It’s almost like that 80/20 analogy. Eighty percent of the CVEs that are coming out are noise, and the twenty percent is what’s really relevant.”
The implication is straightforward: removing unnecessary components can reduce both risk and operational noise.
Distroless and Distro Zero Are Not the Same Thing
The rise of distroless containers has already moved the industry in this direction. Traditional distroless images remove common tools such as shells, package managers, and Linux utilities. That significantly reduces what an attacker can do after compromising a container. But Goswami emphasized that distroless does not remove the entire vulnerable runtime surface. “The job is not complete with distroless,” he said.
A distroless image may still contain components such as C libraries, dynamic linkers, system libraries, and cryptographic dependencies. These components continue running as part of the application environment and may still introduce exploitable vulnerabilities.
Goswami drew an important distinction between removing attacker tooling and removing vulnerable code. “What distroless does is remove the toolkit that an attacker could use once they get into an environment,” he explained. “It doesn’t remove the code base or the set of things that allow them in in the first place.”
Traefik Labs’ Distro Zero approach attempts to take that idea further by reducing the container to the application binary itself wherever possible. The objective is not merely to make exploitation more difficult after compromise. It is to reduce the number of vulnerable components that can be exploited in the first place.
That distinction matters as platform engineering and AppSec teams increasingly treat container composition as an architectural security decision rather than simply a packaging preference.
Memory Safety Is Becoming a Software Supply Chain Requirement
The conversation also highlighted the growing role of memory safety in container security. Many high-profile vulnerabilities originate in memory-unsafe components, particularly libraries written in C or other languages where memory management errors can expose exploitable conditions.
Goswami pointed to guidance from government security agencies encouraging organizations to move toward memory-safe development practices. “C is not one of them,” he said. “They explicitly call out C as a memory-unsafe language because it has all of these abilities to exploit memory issues.”
For application teams, that raises a larger question around software supply chain composition. Security increasingly depends not only on the code developers write, but also on the languages, libraries, runtimes, and dependencies that surround that code. This expands the definition of secure software development.
The focus is moving from identifying individual vulnerabilities toward reducing entire categories of vulnerability exposure through architectural choices.
Regulatory Deadlines Are Moving Security Into the SDLC
This shift is becoming more urgent because regulatory requirements are increasingly affecting software delivery directly. 54.7% of organizations have identified NIST frameworks as a regulatory pressure affecting release engineering, while 46.2% have cited the EU Cyber Resilience Act. These are no longer isolated security or legal concerns. They are engineering requirements.
Goswami pointed specifically to the transition from FIPS 140-2 to FIPS 140-3 and the growing impact of EU CRA requirements. “There is a real regulatory driver behind the FIPS initiative,” he said. For teams supporting regulated environments, gateway and infrastructure choices can directly affect whether applications are able to meet certification requirements.
Goswami argued that enterprises should avoid addressing each requirement through separate infrastructure products. “If there was a way to start with the right Distro Zero framework, which also gives FIPS 140-3 compliance and lets you deal with other regulatory guidelines like the EU CRA, that would be a great architectural choice,” he explained.
This reflects a broader change happening across DevSecOps. Compliance is increasingly becoming something that must be designed into the software delivery platform rather than validated after deployment.
SBOM Complexity Is Becoming Its Own Operational Burden
Software bills of materials have become an important mechanism for understanding software supply chain risk, but every additional artifact also creates operational overhead. Another gateway means another SBOM. Another SBOM means another security review, dependency inventory, vulnerability management process, and compliance validation cycle. As organizations deploy separate ingress controllers, API gateways, AI gateways, and MCP gateways, that complexity compounds quickly.
Goswami described the industry’s emerging challenge as one of architectural consolidation. Traditionally, organizations may deploy separate infrastructure layers for APIs, models, and agents. “Every gateway comes with its own set of SBOMs, with its own set of vulnerabilities and all the dependencies,” he said.
Traefik Labs is responding with a unified binary model that allows organizations to deploy and certify one artifact, then unlock additional capabilities through licensing rather than introducing new binaries. “What if there was a unified binary that you deploy once, you certify once, you understand the SBOM and all the dependencies initially upfront?” Goswami asked.
The goal is to reduce the number of components enterprises need to secure, operate, and audit while still supporting increasingly complex application traffic.
Gateways Are Becoming the Front Door for APIs, Models, and Agents
The gateway layer itself is also changing. Historically, gateways primarily managed application and API traffic. Agentic AI adds two new categories: models and agents.
Goswami described these as new “characters” entering the infrastructure architecture. “The front door should be able to handle all these different characters,” he said. “Traditionally, it’s been APIs, but now you are adding two more characters to this play, which are agents and models.”
This changes the strategic role of the gateway. Instead of acting only as a routing layer, it increasingly becomes a policy enforcement point for authentication, security, observability, rate limiting, AI traffic governance, MCP access, and agent interactions.
That convergence could become particularly important as enterprises look to reduce infrastructure sprawl. A single control layer spanning APIs, models, and agents gives platform teams a more consistent mechanism for enforcing security policies across increasingly heterogeneous application environments.
Analyst Take
Container security is entering a phase where architectural simplification may become more valuable than increasingly sophisticated vulnerability detection. Scanning remains necessary, but the industry is beginning to recognize that identifying vulnerabilities faster does not solve the underlying problem if software continues shipping with unnecessarily large attack surfaces.
The more important question is becoming: how much vulnerable software needs to exist in the runtime at all?
That is what makes the distinction between traditional distroless containers and approaches such as Distro Zero important. The security model shifts from detecting and managing risk toward eliminating unnecessary components before deployment.
At the same time, regulatory requirements are pushing these decisions directly into application development and platform engineering. NIST, FIPS, the EU Cyber Resilience Act, SBOM requirements, and software supply chain controls increasingly influence architectural choices before software reaches production.
The gateway layer is also becoming strategically more important. As APIs, AI models, MCP servers, and agents begin sharing infrastructure, enterprises will need common policy and security enforcement points capable of governing all of them consistently.
The larger shift is this: software supply chain security is becoming less about finding every problem after software is built and more about designing systems that contain fewer problems to begin with. Organizations that reduce dependency surfaces, consolidate infrastructure artifacts, and embed compliance into the delivery architecture will be better positioned to keep pace with both vulnerability growth and regulatory pressure.
