TLDR;

Endor Labs is introducing full-stack reachability for application code AND container images that can cut false positives by up to 90%. If you think that might save you time and money, contact us to arrange a PoC. If you want to know the ‘what’ and ‘how’, read on; it’s quite interesting.

Introduction

Endor Labs was founded to eliminate the developer productivity tax that security tools impose on engineering teams. We proved this with function-level reachability for SCA, which slashed noise from false positives by up to 95% by giving security and engineering teams evidence about which vulnerable functions they code uses—not just which CVEs are present. Once we convincingly solved that problem, our customers started sharing a familiar frustration: container vulnerability scanning was drowning them in the same kind of noise.

The root cause is container bloat. Base images pull in general-purpose operating system components and libraries to support a wide range of use cases. Your application uses a small fraction of what's installed, but traditional scanners treat everything as equally important. Most of those findings—often 70% or more—turn out to be irrelevant because they affect code that never actually runs. 

For teams pursuing compliance frameworks like FedRAMP, this noise isn't just annoying—it's expensive. FedRAMP mandates strict SLAs for vulnerability remediation, but when your scanner flags 400+ vulnerabilities and you can't tell which ones actually matter, you're forced into a painful choice: waste engineering time investigating irrelevant findings, or risk missing something critical.

So we dug deep to solve the hard problems, as we're known to do. The result is full-stack reachability for application code and container images—extending our proven approach to reachability analysis from application code down through the container runtime and OS layers. This gives you what you actually need: evidence-based answers about which vulnerabilities can affect your running application across the entire stack.

Noise reduction that saves developer time

We tested full-stack reachability against well-known open source container images commonly used in enterprise environments to quantify the noise reduction. The results speak for themselves:

In the best case—HashiCorp Consul—full-stack reachability eliminates 90% of reported vulnerabilities as unreachable. Even in the more conservative cases, you're filtering out 46-82% of findings that don't require remediation under strict SLA guidelines for compliance standards like FedRAMP.

This isn't just about reducing alerts. It's about making compliance achievable. When you can quickly identify which vulnerabilities actually affect your runtime environment, you can focus remediation efforts where they matter and confidently document your risk posture for auditors.

Moving from inventory to understanding

The reason full-stack reachability delivers these results is that it solves a fundamental problem with how we think about application security.

Applications are not simply collections of components, just like people are not simply collections of body parts. Yet for some reason, that is how we in security often treat applications. We scan what is installed, produce inventories and SBOMs, and end up with long lists of packages and CVEs. Then we ask engineers to decide what matters.

This inventory-centric model simply does not scale. It floods engineering organizations with noise, and it makes triage and remediation expensive even when there is enough engineering capacity. The expensive part is not only fixing. It is figuring out relevance. Each investigation often turns into complex manual work reconstructing the missing context: how the application is structured, how its parts connect, and whether a reported vulnerability can affect the running system.

This problem will get even worse as AI-generated code becomes normal. There will be more code, but also more change and more third-party dependencies pulled in to build features quickly. At the same time, the shared understanding of application internals will decline. When understanding becomes more expensive, a model that depends on humans repeatedly reverse-engineering context will break completely. This is what happens today in application security, where figuring out relevance depends exclusively on humans to provide context.

To have a fighting chance, we need to transition from a primitive, inventory-centric model to a model that captures how applications are structured and how they actually run. The goal is simple: engineers should not have to recreate the same knowledge each time they investigate a new vulnerability.

In other words, we need to move from standalone dots to a connected graph, because inventory gives you information while a connected model explains how the system executes, which components are involved, and where vulnerabilities are relevant in the real deployment.

Start with the application source code, but do not stop there

To understand an application's structure, you start with its source code. This is where Endor Labs started with its SCA product and its application model based on dependency trees and call graphs. That model enables function-level reachability analysis for application-layer vulnerabilities, making triage significantly more practical. Instead of "this vulnerable library is present," you can often answer "this vulnerable code path is reachable from our application" or "we found no path."

Source code reachability only helps secure the application layer, but application source code does not run on its own. When an application is deployed in production, it executes on a runtime and an operating system. Those layers bring in additional components that can matter for security, even if they are not visible in the code repository.

What you see in the repository is not what you ship

Applications are like icebergs. There's more to them than meets the eye. The application source code in a git repository is just the tip of that iceberg. Below the waterline are components that are easy to ignore until they show up in a vulnerability report: runtime internals, shared libraries, native extensions, and operating system components.

Running an application activates those hidden layers. They become part of how the application works in practice. They extend the effective dependency tree and call graph of what the application relies on at runtime.

Containers bundle the application iceberg into a single unit

If we look at the modern tech stack, containers represent a construct that bundles all the different layers into one artifact. In a container, you typically have the application itself, its dependencies, the runtime, and operating system dependencies.

This bundling creates an opportunity. A container is not just a package list; it is a packaged execution unit. It can give us a full-stack view of what the application actually runs with, and how higher-level application behavior ties to lower-level runtime and OS components.

Traditional container security solutions do not take advantage of this opportunity. What you normally get is an inventory or SBOM-centric view of container vulnerabilities. Container scanners enumerate packages in the image and match those packages against known vulnerabilities. The output contains plenty of information, but it largely presents each component in isolation.

These package-centric container reports do include vulnerabilities across the lower layers, including runtime and OS components. The problem is that they lack application context. Without that context, you cannot determine which vulnerabilities are relevant to the running application, so you end up paying the reverse-engineering cost anyway.

Just like with application source code, analyzing containers requires an application model to make sense of findings. In fact, you need it even more with containers because containers include many unrelated general-purpose operating system components by default.

Full-stack reachability requires both structure and observation

Parts of the required model can be determined by observing how applications run, but runtime information is not enough on its own. Observation tells you what happened in a specific run, not necessarily what is possible, and it often lacks the higher-level structure needed to explain why a path exists.

This is where there is an opportunity to extend the application model created with SCA. The SCA model provides a detailed application context. When combined with container information and extended downward into runtime and OS layers, it becomes possible to deliver full-stack reachability that covers application, runtime, and OS vulnerabilities.

The existing Endor Labs SCA product provides a perfect foundation for full-stack reachability. It provides the most detailed application composition context with the most accurate dependency tree and application call graph data. Its core application model can be extended and augmented with additional component information available in containers, but doing that requires additional static and dynamic analysis. This is exactly what we are building with the new container security product.

Redefining container security with static and dynamic application data together

For this new full-stack application model, we combine detailed application context from Endor Labs SCA with dynamic analysis data by collecting runtime information from containers. The ultimate source of truth is which libraries are loaded and which files are read when the application runs.  By instrumenting the container in a sandbox, what the application actually uses across application, runtime, and OS layers is definitively revealed. Together, these capabilities provide the missing bridge from application-level context to lower-level runtime and OS components.

This combination creates something genuinely new, and, as we’ve shown above, exceptionally useful. Instead of yet another container scanner that just produces a bigger list, it builds a full-stack application model that extends Endor Lab’s powerful SCA reachability by using the container analysis engine I built to connect application context to the full containerized execution environment. 

That context is especially important for customers pursuing FedRAMP, which explicitly calls out container vulnerabilities as an area of scrutiny; by proving which vulnerabilities are actually reachable, we dramatically reduce the number that must be remediated for compliance, making FedRAMP authorization and ongoing audits significantly easier.

Building the future of application security

This is why I'm extremely excited to be part of the effort to build the new Endor Labs container security product. We are making history by redefining what container security is. It is no longer a vulnerability report that treats a containerized application as a collection of unrelated components and leaves engineers to do the heavy lifting of reconstructing context. Full Stack Reachability gives that missing context by connecting findings back to how the application actually runs, across the application layer, the runtime, and the operating system.

It replaces inventory with understanding and eliminates the reverse-engineering step from triage. It shows which vulnerabilities matter across the full stack and why. For teams navigating compliance requirements, managing container bloat, or simply trying to ship secure software faster, this changes everything.

Ready to see how full-stack reachability can reduce vulnerability noise in your containers? Schedule a PoC to put it to the test in your environment.