Delivering Precision Container Security with Function-Level Reachability

Containers Without Context

The container ecosystem has evolved fast. Hardened images from providers like Chainguard, Docker Hardened Images, Iron Bank, Minimus, and Wiz OS have raised the baseline with curated, minimized, and continuously maintained base images that reduce OS-level vulnerabilities. Teams today can pull images that ship with fewer CVEs, tighter provenance, and hardened configurations baked in from the start.

But even the strongest base image cannot address what lives inside the application layer. The moment developers add their own code, package managers, frameworks, or third-party artifacts, the risk profile changes completely. A typical service might include dozens of direct dependencies and hundreds of transitive ones, none of which appear in OS-level scanning. These application-level issues are often the most difficult and time-consuming to patch due to compatibility constraints, breaking changes, and the need for full testing cycles. Hardened images secure the foundation, but not the application code and libraries that actually run on top of it.

This is the industry’s blind spot. We have made progress on securing what containers are built from, but not what containers actually execute. That is where real, exploitable risk still hides.

Hopper is addressing this gap. By extending function-level reachability to containers, we give teams visibility into which application-level vulnerabilities inside the image are truly exploitable.

From Layers of Noise to Reachable Risk

A container image is built from multiple layers. Each layer serves a purpose: base operating system, runtime libraries, application frameworks, and the application itself. Vulnerabilities can appear at any of these layers, but not all are equal.

• System vulnerabilities are often tied to OS packages or runtime libraries. Many of these have little impact on application logic, though some can matter if the container runs with elevated privileges or the system component is invoked.
• Application vulnerabilities live in frameworks, third-party libraries, dependencies, and custom code. These are the issues most likely to create direct business risk.

Traditional scanners can show which layer a vulnerability belongs to, but they cannot determine whether an application actually uses the vulnerable function inside that component. The result is alert fatigue, wasted engineering cycles, and critical risks buried under thousands of irrelevant findings.

‍

Hopper takes a different path. We analyze containers holistically, but apply function-level reachability where it counts: the application layer. By extracting packages and artifacts, scanning for vulnerable functions, and tracing real code paths using context that Hopper auto-detects or users supply, Hopper separates vulnerabilities that are truly exploitable from those that are not. 

The outcome is clarity: every vulnerability in the container is mapped, and only the application risks proven reachable rise to the top.

How Container Reachability Works

Container Registry Integration

Before you can start scanning, connect your desired container registry to Hopper. We currently support:

• Amazon ECR (Elastic Container Registry)
• GitLab Container Registry
• Custom Container Registry - Every container registry 

Configuring Container Reachability Scanning

To enable Container Reachability Scanning, add the relevant configuration in Hopper:

1. Choose your repository: Select which container repository to analyze.
2. Choose tags: You can specify a single tag or multiple tags to target.

Hopper automatically infers the Code location and Entrypoint using our auto-configuration algorithm. Alternatively, you can define these manually by the Set Code location and Entrypoint fields if applicable. 

 Once connected, Hopper automatically scans the configured container images for both system-level and application-level vulnerabilities. 

Container Scanning Flow

System Vulnerabilities

Hopper starts by generating a detailed inventory of all packages and dependencies contained in a container image. This includes full support for hardened images from providers such as Chainguard, Docker Hardened Images, Minimus, and WizOS, ensuring accurate detection even when the base image has been minimized or rebuilt for security.

This is achieved by:

• Inspecting the filesystem layers
• Identifying package managers
• Extracting package metadata (name, version, location)
• Detecting language runtimes and libraries within compiled binaries

Each package and dependency is then checked against our vulnerability databases.

Application Vulnerabilities

For application-level analysis, the input includes:

• The container image
• Code location and Entrypoint if applicable

As mentioned above, the Code location and Entrypoint  can be auto-detected or manually configured for finer control. Hopper then extracts all relevant packages, data, and artifacts from the container image. Hopper supports all kinds of artifacts. For example, in Java there are JAR, WAR, EAR, etc. 

Shading Support

For Java, Hopper supports shading inside the container image and analyzes the shaded dependencies as well. 

Static Code Analysis

At the function level, Hopper performs precise and context-aware static analysis:

• Constructs the full application execution flow across first- and third-party code
• Locates vulnerable functions inside third-party libraries
• Traces reachable paths from real entry points to those functions
• Records evidence such as method chains, files, traces, and call graphs

‍

Exploitability Context

Each vulnerability is then validated for real-world exploitability*:

• Verifies required preconditions and anti-patterns
• Analyzes data flow, parameters, and configuration
• If preconditions are missing, the vulnerability is marked as not exploitable

*Exploitability validation is available for paid Hopper plans.

Results and Insights

Hopper organizes container analysis results into two views:

1. Regular Container Scanning

This view reports system-level vulnerabilities found in the base OS and runtime layers of the image.

2. Container Reachability Analysis

This view focuses on the application layer. Within it, Hopper separates:

• All vulnerabilities, which includes the system vulnerabilities present in the container image and application-layer vulnerabilities
• Application-layer vulnerabilities proven reachable

To avoid confusion, Hopper deduplicates any vulnerability that appears in multiple categories, so nothing is double-counted.

Each analyzed container also includes clear fix guidance for issues that can be remediated.

Why Container Reachability Matters

Hopper’s approach transforms container security for both AppSec and engineering teams:

Clear separation of system vs application vulnerabilities
Teams can quickly see which issues are tied to the OS and which affect the application layer, without drowning in undifferentiated alerts.

Reachability filtering for containers
Rather than treating every vulnerability as equal, Hopper determines whether the vulnerable code paths inside a dependency are used by the application, so teams only fix issues that are truly reachable.

Actionable remediation paths
Developers receive evidence-backed insights tied to call graphs and real code usage, along with the exact patched or backported version needed to fix the issue, whether the affected component comes from a third-party image such as Kafka or Flink or from code built in-house.

Compliance for image attestations and audits
Security leaders can demonstrate that vulnerability management decisions are evidence-based and risk-driven, showing auditors that the organization is fixing the issues that matter most and maintaining a consistent, defensible remediation process.

Limitations in Container Environments

Function-level reachability is powerful, but it is not a silver bullet. Its precision applies to the application layer of containers, not every component inside the image.

• OS layer not covered: Reachability does not extend to the base operating system or runtime libraries in the container image. These issues still need to be managed through patched or updated base images from hardened providers such as Chainguard, Minimus, Docker Hardened Images, and Wiz OS, or through other system-level remediation processes.
• Application-focused scope: Reachability applies only to the application layer of the container image. System-level vulnerabilities remain outside the scope of this analysis and require separate remediation.
• Container reachability is currently available for Java applications only. Support for additional languages is coming soon.

By being clear about scope, Hopper helps teams build realistic layered defense strategies that combine precise application risk reduction with broader container hygiene. 

Why Hopper Is Different

No other vendor applies function-level reachability to containerized applications at rest. Hopper is the first to close this gap, delivering clarity in one of the noisiest areas of modern security.

By combining automatic asset discovery, multi-layer analysis, and reachability precision, Hopper ensures security teams see containers for what they really are: a powerful delivery mechanism that should accelerate development, not overwhelm it.

Talk to our team to see how container reachability can cut through the noise in your environment.