Container Security: Creating an Effective Security Program with Reachability Analysis

Containers have taken over the world of software development. According to Gartner analysts, “90% of global organizations will be running containerized applications in production by 2026,” up from 40% in 2021. Containerized applications provide enterprises with an agile, modern approach in the age of cloud computing; safeguarding these technologies from existing and future threats requires equally modern methods. Securing containers goes beyond the code — it extends across kubernetes security, image governance, and runtime protection to ensure workloads remain resilient throughout the lifecycle.

One significant container security challenge stems from the common use of publicly available open source images. Developers often pull public images with known flaws or fail to update Docker images quickly enough to remediate CVEs, creating a growing backlog of vulnerabilities within registries and pipelines. Software companies that build and operate containers spend thousands of hours annually on vulnerability management — triaging docker container vulnerabilities that span both application and OS layers. However, identifying, triaging, and patching CVEs found in your container images is a lengthy, cumbersome process that introduces a lot of toil and friction for organizations that need to move fast and ship new products and services to customers.

‍Conducting robust and accurate CVE triage requires dedicated staff and a significant time investment, translating into higher operational costs and potential delays in addressing critical vulnerabilities. Teams often become inundated with these tasks, which distracts them from more important tasks like product and business innovation. This blog post is part of a series about container security.

‍Reachability: A new security paradigm 

Reachability has become a must-have feature for application security scanners because it helps separate exploitable risks from false positives — a crucial capability when managing complex, multi-layered microservices security and containerized workloads. Reachability analysis takes vulnerability prioritization to the next level. It identifies relationships between software functions, so you can understand open source library vulnerabilities in their real-world context. Reachability analysis also enhances the effectiveness of container security tools by prioritizing vulnerabilities that actually impact production, reducing noise across scans.
By linking dependencies, you can trace forward through application code to see if an attacker could potentially access a given software flaw. Reachability can answer questions like:

• Is my code actually invoking this library with vulnerable code within it?

Reachability analysis lets you smoke out those vulnerability scanner findings for issues that pose minimal risk in your product or network. It also enables you to evaluate the safety of library upgrades and the elimination of unnecessary dependencies.

Effective reachability for container scanning¹

Before analyzing reachability technology for container scanning, it’s important to distinguish between Software Composition Analysis (SCA) and container scan processes — both detect vulnerabilities but focus on different layers of the stack. These are distinct but commonly confused tools. 

SCA

SCA is a tool that analyzes open source code (from other repositories, which are most commonly public but can also be internal dependencies) that have been imported by a developer and used in applications. he purpose of an SCA tool is to create a Software Bill of Materials (SBOM), surface vulnerabilities and risks in open source packages, and provide remediation recommendations — a foundation that complements docker image scanning for containers.

Container scanning

Container vulnerabilities affect libraries that are installed onto the operating system layer of an image — a key difference from application-level dependencies analyzed by SCA. Similar to an SCA tool, the container scanner looks for vulnerabilities in those imported images. Because containers include both the application and the OS layer, the number and severity of discovered CVEs is significantly higher. Continuous Container Security Scanning can help surface and prioritize those OS-level risks early in the lifecycle.

For example, let’s take a look at Redis, a popular open source key-value store that functions as a data structure server. Scanning Redis source code (https://github.com/redis/redis) reveals the following results:

Scanning Redis’ official container image (https://hub.docker.com/_/redis) reveals:

Examining the results reveals that almost all CVEs are coming with the Debian OS (version 12.5) and that without this layer, the accumulated CVE results are minimal (7 CVEs).

Similar results can be seen with other popular open-source container images like Postgres. When scanning its source code (https://github.com/postgres/postgres) you can’t detect any known vulnerabilities. However when scanning its docker-hub official image (https://github.com/docker-library/postgres) build on Debian OS, you find more: 

Here, too, all CVEs come with the OS level.

But it’s not just Debian OS that adds multiple vulnerabilities to container images. Let’s take a look at another popular CNCF project called Buildpack using Ubuntu OS. Scanning its source code (https://github.com/paketo-buildpacks/go) reveals the following results:

Scanning its official container image (https://hub.docker.com/r/paketobuildpacks/build) shows the following:

Many of these OS-level CVEs also overlap with issues identified through docker image security, emphasizing the need for layered protection that combines image validation, patching, and runtime enforcement.

Adequate reachability for containers²

Let’s examine the different reachability technologies to assess which one has the best results for container-security scanning. 

Function-level reachability (SCA)

unction-level reachability (SCA) focuses on source code, tracing whether vulnerable functions are actually called. But it doesn’t extend to OS-level vulnerabilities or orchestration contexts such as kubernetes security best practices, which are essential in containerized environments. An SCA tool with source-code reachability analysis scans your code to check if the vulnerable library is being used in a way that can be exploited by the detected CVE. It can trace entire application contexts to verify if the vulnerable circumstances can happen outside of simple code execution flow. With function-level reachability, if CVE exists in the code but can’t be exploited, then the CVE is a false positive that you don’t need to send for remediation.

There are some inherent challenges with this methodology, because multiple CVEs don’t contain the function-level data needed for the reachability analyzers, and some CVEs require the general application context to validate if an exploit is possible. Nevertheless, reachability in the SCA context provides a great solution for application source-code analysis.

In container images, the vulnerable libraries are installed onto the operating system. SCA reachability doesn’t cover the OS layer and consequently does not identify the vast majority of CVEs reported for container images.

Consequently, it’s not suitable for container security. 

This is where runtime-focused Docker container security and orchestration-layer controls provide the missing context for comprehensive defense.

To avoid last-minute surprises in production, many teams apply these runtime insights earlier in CI/CD pipelines, combining predictive analysis with container security tools and pre-deployment validation.

Package used in image (Container)

A common method to detect reachability for container image vulnerabilities utilizes runtime methods. Equipped with technologies like eBPF, modern runtime security tools extract loaded packages during execution. This enables runtime assessment to identify which components are actually in use — strengthening container security best practices and reducing patching overhead.

Examining the previous Redis container example deployed in AWS EKS cluster, we see the following results:

A first glance shows great results: between 7-15 CVEs are in use while the container is running, no need to fix the other 265 CVEs.

However, a deeper look into the result reveals fluctuations in the number of reachable CVEs, which is based on the actual usage of the container while it’s running. This method is actually a runtime snapshot of the loaded packages, which might change based on the container usage. Hence, there’s a potential for CVEs to be missed with the “in use” methodology that captures current usage status. 

There are also some practical aspects that might limit the “in use” methodology. A common argument is that when the container is deployed, it’s too late to identify which code parts need to be changed/modified due to code vulnerabilities. Additionally, the cost implications of addressing security issues in a running application, rather than earlier in the development cycle, cannot be overstated. Remediation at this stage often entails significant operational disruptions and resource allocations, as fixes may require rolling back production environments, comprehensive system audits, and extensive testing to ensure that patches do not negatively impact functionality or introduce new vulnerabilities.

Runtime prediction—Container images reachability

To bridge the gap between function-level reachability and package-in-use for running images, one may use a static reachability analysis for container images. his approach analyzes compiled code and configurations within the container’s filesystem to determine which packages are actually usable at runtime versus dormant. When integrated into CI/CD workflows, it can complement kubernetes security and Container Security Scanning frameworks for earlier, more efficient prioritization.

In contrast to runtime solutions, this analysis can be used in the classical shift-left (pre-production) scanning points of containers images (e.g., CI or image registries) or in Git repos (with adequate build option).It requires no additional setup and is significantly faster than runtime analysis — unlike post-deployment scanning, which often delays response times and complicates update Docker images cycles.

There’s also an often-overlooked value in this case. Because SCA and container teams are sometimes separated, AppSec managers may find themselves in between SDLC stages, just to figure out way too late (in production) or too early (code without the OS context) about security risks and their actual reachability status. Looking back at the Redis example with runtime prediction analysis, we get an 84% reduction before deploying anything to our running environment.

Reachability-based prioritization can also feed directly into orchestration policy enforcement through kubernetes security best practices, giving DevSecOps teams unified visibility from image to runtime.

Conclusion

Reachability has become an essential capability in modern container security tools. It identifies truly exploitable risks, separating them from false positives and supporting better remediation prioritization. Reachability analysis allows efficient prioritization by identifying relationships between code components and understanding library vulnerabilities in their real-world context. 

In container images, reachability-based prioritization is crucial, as the amount of detected CVEs is typically skyrocketing. However the classical reachability used in SCA isn’t adequate for container security usage, it requires a reachability analysis that addresses the OS level CVEs. By integrating reachability with docker image scanning, layered Docker container security, and proactive kubernetes security best practices, organizations can finally balance speed with control — securing containers from build to production with precision.

¹The following security scanning results were done by Mend’s SCA and Mend’s Container solution but were compared to other commercially available and open-source scanners that reveal similar (but not identical) results.

²The reference for this section is from the remarkable research work by James Berthoty (5 types of reachability analysis: https://www.endorlabs.com/learn/5-types-of-reachability-analysis-and-which-is-right-for-you).