If you've been following the AppSec space at all and my prior writing, you know we're drowning in vulnerabilities. The CVE landscape has become a sprawling challenge that nearly no organization can keep pace with, with year-over-year growth consistently in the double digits. In 2025, we saw over 48,000 CVE’s, which was a 20.6% increase over 2025 and 2026 is showing no signs of slowing down. See below from one of my favorite vulnerability researchers, Jerry Gamblin.

Organizations have rightly focused on the application-level dependencies in terms of scanning, and rightfully so, as we see application exploitation be a leading attack vector in key reports. That said, we’ve largely ignored a massive attack surface that has downstream ramifications that are hiding in plain sight, container OS libraries.

When a vulnerability surfaces in a base container image, it doesn't just impact one application; it can propagate across hundreds or thousands of running containers in an enterprise environment. A single CVE in an OS library embedded in your container images can have a far broader blast radius than a vulnerability in an application dependency due to the distributed and multi-tenant nature of containers and microservices. 

We’ve seen many innovations in the SCA space, includingreachability analysis and efforts to drive down the toil associated with vulnerability management. However, the tooling and methodologies we've applied to application-layer SCA have been largely absent at the container OS level. This is a gap I’ve been thinking about a lot as we head into 2026, and so has the team at Endor Labs, which is why it is an issue we’re addressing head-on now with a release of our new features.

The Complicated AppSec Landscape We've Created

I previously wrote about what the Verizon 2025 Data Breach Investigations Report (DBIR) called the “vulnerability era”. Exploitation of vulnerabilities has surpassed phishing as the primary attack vector, and attackers are having a field day with the porous and problematic attack surfaces organizations have due to runaway vulnerability backlogs, complexity, and challenges with remediation capacity. Meanwhile, defenders are stuck in an endless cycle of vulnerability scanning, triaging, and remediation that feels more like treading water than making progress. This is supported by data too, with research finding the organizations struggle to sufficiently patch known exploited vulnerabilities (KEV), let alone lower priority findings.

The problem isn't just the volume of CVEs, it's also the signal-to-noise ratio, with teams chasing vulnerabilities that aren’t known to be exploited, likely to be exploited, or even reachable. This is what Endor Labs has referred to as the “developer productivity tax”, something security imposes on our development peers, bolstering silos between security and development and being an impediment rather than an enabler to the business. 

Research consistently shows that only about 5% of CVEs in a given year are actually exploited in the wild. Organizations waste insane amounts of engineering time forcing developers to remediate vulnerabilities that pose little actual risk. Is it any wonder developers dread engaging with security teams? We've created a system where we beat engineers over the head with massive lists of findings, many of which are functionally irrelevant to applications' actual risk posture and just serve to be a drain on the business.

This is where reachability analysis has been a game-changer for application dependencies. By understanding whether a vulnerability is actually reachable by an application's code paths, organizations can reduce their noise by upwards of 70-90%. Instead of remediating everything with a "Critical" CVSS base score, teams can focus on vulnerabilities that are actually exploitable in their specific context, which can enable development velocity while still mitigating organizational risks.

This is something Endor Labs has prided themselves on, with one recent CISO customer stating “Endor Labs is like noise cancelling headphones for vulnerability management and AppSec”, which I thought was awesome.

The Container Blind Spot

While the community has made a lot of progress on application level vulnerabilities, we’ve still got a lot of room for improvement. This reachability innovation and emphasis has been largely absent at the container OS layer. When you pull a container image from Docker Hub or any public registry or even internal private registries, you're not just getting your application, you're inheriting an entire operating system's worth of libraries, many of which your application never actually touches.

Studies have found that 96% of container images in public registries contain vulnerabilities, with 91% having at least one critical or high finding. That's an enormous attack surface, and most organizations have no way to distinguish the signal from the noise. While we are and have seen the rise of innovative offerings around “hardened images” and “zero CVE” offerings, there are still many cases where those aren’t adopted or in place, or organizations make changes that may introduce new dependencies and risks.

Think of a base image like a standardized toolbox provided to every developer in your organization. You can't know which tools are actually "reachable" and actually needed until you understand what specific application is being built on top of it. 

A vulnerability in a library that's installed but never loaded at runtime is fundamentally different from one that's in the critical path of your application's execution, something we’ve tried to show the community at the Application Layer for the last several years. Yet traditional container scanners treat them identically, dumping massive finding lists on platform teams without the context they need to prioritize effectively, essentially recreating the developer toil but on internal platform teams who are looking to enable and scale development teams through centralized offerings and capabilities in large enterprise environments.

Enter AI-Driven Development

This challenge is only being amplified by the rise of AI-driven development. We're seeing projections of double-digit productivity boosts from coding assistants, with some organizations reporting that AI is writing 40% or more of their new code. These metrics jump even higher for organizations embracing “Vibe Coding”, or that lack deep human involvement with the SDLC and instead implicitly trusting the outputs of AI-generated code. The pace of software delivery is accelerating, and with it, the velocity of containerized deployments, code and vulnerabilities. Endor Labs covered this rising complexity and its implications in our 2025 State of Dependency Management Report, where we had an emphasis on AI Coding Agents, MCP and Software Supply Chain Risks.

But here's the uncomfortable reality: research shows that AI-generated code is vulnerable somewhere between 25-75% of the time, depending on the complexity of the task. Developers inherently trust these outputs for the sake of velocity and convenience, and that trust extends to the container images and dependencies that AI suggests. As I've written before in my blog “Why AI Code Gets Less Secure With Every Prompt”, AI-generated code actually becomes less secure with each iteration, even when using security-focused prompts. This means the container vulnerability problem is only going to compound as AI-driven development becomes the norm.

Closing the Gap with Container Reachability

This is why I'm excited about what Endor Labs is doing with container reachability analysis. Rather than just scanning container images and producing yet another list of findings for platform teams to drown in, we're applying the same innovative reachability analysis that transformed application SCA to the container OS layer.

The approach combines static analysis with dynamic runtime profiling to determine which OS packages are actually exercised by your application at runtime. During scanning, the image is executed to collect runtime signals, allowing us to distinguish between dependencies that are merely installed versus those that are actually loaded and used. The result is a container dependency graph that helps platform teams precisely identify which OS vulnerabilities actually need remediation, and which can be safely deprioritized. This is an example of Endor Labs not only providing innovative SCA capabilities prior to deployment but also accounting for runtime context when it comes to containers to help organizations optimally reduce risks.

Our internal benchmarking shows around significant noise reduction with this approach, which isn’t just a nice to have efficiency gain but is a massive reduction in toil for platform teams that are being buried into thousands of findings that are irrelevant at the end of the day and distract them from focusing on providing organizational value to the developers that depend on them.

What Makes This Different

What’s critical to call out about this approach is that it works with your existing images and doesn't require you to switch distros or adopt a new container ecosystem. Unlike solutions that force you to migrate to hardened base images or mutate your containers through automated patching, container reachability gives platform teams visibility and control while keeping the keys to the kingdom in their hands and avoiding further dependencies on external vendors for things such as hardening, remediation and SLA’s.

The three I want to emphasize here is that it works with your existing container images, it provides a container dependency graph that helps prioritize reachable OS and app vulnerabilities, and it delivers upgrade recommendations that won't break your application. That last point is crucial, and something Endor Labs has tried to stress previously when discussing how breaking changes break trust. We've all experienced the pain of applying a "security fix" that introduces a breaking change, which doesn’t just potentially cause business disruption but further undermines the credibility of security teams as well. Having intelligence about safe upgrade paths is as important as knowing what to fix.

Closing Thoughts

We're at an inflection point in AppSec. The combination of runaway CVE counts, the rise of AI-driven development, and the continued explosion of containerized workloads is creating a perfect storm that traditional approaches simply can't handle. What got us here won't get us to where we need to go.

The path forward requires precision over volume, understanding which vulnerabilities are actually exploitable in your specific context rather than treating every finding as equally urgent. Reachability analysis has already proven its value at the application layer and now we’re extending that intelligence to container OS libraries to close a critical gap that's been hiding in plain sight.

As I often say, security teams need to stop being a developer tax and start being genuine business enablers. That involves more than just talking points, but solutions that are actionable in reality. That means giving teams the context they need to prioritize real risks, not burying them under mountains of noise. Container reachability is a meaningful step in that direction, and one that's long overdue.