CVSS scores tell you how bad a vulnerability could be in the worst case. Red team findings tell you what attackers actually use when they have access to a real containerized environment. These are different datasets, and the prioritization they produce is often substantially different.
Blue teams that prioritize based on CVSS spend remediation cycles on vulnerabilities that attackers rarely reach and deprioritize the specific weaknesses that red team exercises find exploitable consistently.
The Gap Between Theoretical Severity and Actual Exploitation
A critical CVSS score means a vulnerability has the potential for significant impact under the right conditions. It doesn’t mean an attacker in your specific environment can reach it, trigger it, or use it to achieve their objectives.
Red team engagements against containerized environments consistently reveal that the vulnerabilities actually exploited in engagements are not always the highest-CVSS ones—they’re the ones reachable from the initial foothold the red team established, the ones in packages that the application actually loads and uses, and the ones that enable the attacker’s specific objective in that environment.
The mismatch creates a prioritization problem: blue teams triaging hundreds of CVEs by CVSS score are not triaging by exploitability.
Theoretical severity and actual exploitability are different properties. A CVSS 9.8 vulnerability in a package that’s never loaded is less relevant to your defense than a CVSS 6.5 vulnerability in a library that processes every user request.
What Red Teams Find in Container Environments?
Package manager presence enables post-exploitation persistence
One of the most consistently finding-producing weaknesses in container environments: the container image ships with package managers (apt, yum, pip, npm) that the application doesn’t need for runtime. An attacker who achieves code execution in the container uses the package manager to download additional tools, establish persistence, and expand access.
A container that has curl removed and pip removed cannot trivially download attacker tooling after initial compromise. The package manager isn’t the initial vulnerability—it’s what enables everything that comes after. Container vulnerability scanner and hardening outputs that identify and remove package managers from production containers directly address this post-exploitation vector.
Lateral movement via environment variables and mounted secrets
Red teams consistently find credentials in environment variables and mounted secret files that enable lateral movement to databases, cloud services, and internal APIs. Container environments that pass secrets as environment variables—rather than using secrets management with short-lived tokens—give the red team credentials to pivot after any container compromise.
The attack doesn’t require exploiting a high-CVSS CVE. It requires reading an environment variable that’s visible to any process inside the container.
Shell presence enables escalation of any code execution
When application-layer vulnerabilities give the red team code execution, the presence of bash or sh in the container image enables escalation—the attacker moves from “can execute one command” to “has an interactive shell.” Containers that have removed shells as part of hardening limit this escalation path: code execution that can’t be converted to shell access is significantly harder to use for subsequent attack stages.
Old CVEs in base image packages provide reliable initial access
Red teams targeting containerized environments frequently find exploitable CVEs in container OS packages that have been known for months or years. These are not zero-days—they’re disclosed CVEs that haven’t been patched because nobody owns the remediation workflow for container OS packages.
Container CVE accumulation in base images that aren’t regularly updated is one of the most consistent findings in container red team engagements. The CVEs exist, they’re publicly known, and they’re reliably exploitable.
Practical Steps for Defending Against Real Attack Patterns
Remove package managers from production container images. This is a high-impact, low-effort change: identify which containers ship with apt, pip, npm, or similar tools, and remove them during the hardening process. The application doesn’t need them at runtime. Attackers use them heavily post-exploitation.
Remove shells from production containers. bash, sh, and other interactive shells are development and debugging tools, not runtime requirements. Containers that don’t ship shells limit an attacker’s ability to convert code execution to interactive access. This change requires testing to confirm the application functions without a shell, but it’s achievable for most production container workloads.
Treat credential exposure as a red team target, not just a compliance finding. Run periodic exercises specifically looking for credentials reachable from container context: environment variables, mounted files, instance metadata APIs accessible from the container network. The red team will find these. Finding them first is cheaper.
Prioritize CVE remediation by runtime reachability, not CVSS score. A CVE in a package that the runtime profiling shows is actually loaded and used is a higher remediation priority than a CVSS 9.8 in a package that’s never called. Reachability data from runtime profiling should inform the priority queue, not just theoretical severity.
Track time-to-remediation for CVEs in actually-exploited package categories. Red team exercises reveal which package categories are consistently targeted: interpreters, package managers, network utilities, compression libraries. Track remediation velocity separately for CVEs in these categories versus CVEs in packages not historically exploited in your environment.
Frequently Asked Questions
What are the most common sources of vulnerabilities that attackers actually exploit in container environments?
Red team findings from container environments consistently show that the most exploited vulnerabilities are not necessarily the highest CVSS-scored ones. Attackers most reliably exploit old CVEs in base image OS packages that haven’t been remediated because no one owns the container OS patch workflow, the presence of package managers (apt, pip, npm) that enable post-exploitation tool download, interactive shells (bash, sh) that escalate code execution to interactive access, and credentials exposed in environment variables that enable lateral movement. These findings share a common characteristic: they are addressed by container hardening, not by application-layer security controls.
Which red team activity helps organizations identify vulnerabilities in container environments by testing live systems?
Red team penetration testing exercises that simulate realistic attacker behavior against containerized environments—including attempting code execution, post-exploitation persistence via package managers, lateral movement via exposed credentials, and container escape via kernel and runtime CVEs—are the most valuable for identifying exploitable weaknesses. Unlike vulnerability scanners that report theoretical severity, red team exercises reveal which vulnerabilities are actually reachable from realistic entry points in the specific environment. The findings directly inform prioritization: which CVEs are in packages the application actually loads, and which post-exploitation paths are available in unhardened containers.
What are the four most common vulnerability types attackers exploit in container environments according to red team findings?
Red team exercises against container environments consistently surface four exploitable weakness categories: unpatched CVEs in base image OS packages (known for months or years but not remediated), package manager presence enabling post-exploitation tool download, interactive shell availability that escalates limited code execution to full interactive access, and credential exposure through environment variables and mounted secrets. Notably, these are infrastructure-layer weaknesses—not application-layer vulnerabilities that RASP addresses. The most impactful defensive action is container hardening that removes package managers, shells, and unused OS packages before deployment.
How should container security teams prioritize CVE remediation based on red team findings?
Red team findings should drive a shift from CVSS-based prioritization to reachability-based prioritization. A CVE in a package that runtime profiling confirms is loaded and called on every request is a higher remediation priority than a CVSS 9.8 in a package the application never uses, regardless of theoretical severity. Security teams should track time-to-remediation separately for CVEs in package categories that red teams consistently target—interpreters, package managers, network utilities, compression libraries—versus CVEs in packages not historically exploited in their environment. This reallocation produces security improvements that reduce actual compromise rates, not just CVE counts.
Why Offensive Research Changes Defense Strategy?
The most valuable thing about red team findings isn’t that they identify specific vulnerabilities—scanners do that. It’s that they reveal how vulnerabilities are chained together to achieve attacker objectives in real environments.
A CVE in a package that can’t be reached from any realistic entry point may never need to be remediated. A package manager that isn’t technically vulnerable but enables every post-exploitation step is critical to remove. Red team findings make this distinction concrete in ways that CVSS-based prioritization cannot.
Blue teams that incorporate red team findings into their prioritization frameworks end up defending differently: fewer resources on theoretical high-severity CVEs that aren’t reachable, more resources on the specific weaknesses that produce attacker success in practice.
That reallocation is what separates container security programs that reduce risk from those that reduce CVE counts without changing outcomes.
