Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Gig-economy / Workforce SaaS Platform |
| Cloud Environment | AWS |
| Workloads | EKS (multiple clusters) and EC2 |
| Code & CI | Bitbucket for SCM, Jenkins for CI |
| Prior Tooling | A cloud-first tool that included Docker image vulnerability scanning |
| Focus Area | Container image vulnerability scanning |
The Situation: The Old Tool Scanned Docker Images — The Team Noticed When It Was Gone
When this team was comparing Cloudanix against the cloud-security tool they were moving off, one capability they explicitly valued in the incumbent was vulnerability scanning for Docker images. They run EKS clusters and EC2 workloads on AWS, and their platform ships as container images — so image vulnerability scanning was not a nice-to-have, it was part of how they understood their runtime risk. A team that has had image scanning and then loses it feels the gap immediately: the images running in production become an unscanned layer between their code and their cloud.
The deeper issue is that code scanning and cloud posture, on their own, leave the container in the middle unexamined. An SCA scan tells you about dependencies declared in the repo. A CSPM scan tells you about the EKS cluster configuration. Neither tells you what is actually baked into the image that is running right now — the base-image CVEs, the secrets accidentally layered in, the packages added during the build that never appear in a manifest.
The Core Tension
The container image is where code becomes a running artifact, and it is precisely the layer that pure code scanning and pure cloud scanning both miss. A vulnerability can enter through the base image or a build step without ever touching the repo’s dependency manifest — so a team that scans only source and only cloud configuration has an unexamined gap exactly where their workloads actually run. Image scanning, tied to the running workload, is what closes it.
Where the Gaps Were
Base-Image and Build-Time CVEs Invisible to SCA
SCA reads manifests and lockfiles — the dependencies the team declared. But a container image also carries its base image, OS packages, and anything added during the build. CVEs in those layers never show up in a repo-level dependency scan, so they are invisible until something scans the image itself.
Secrets Baked Into Image Layers
A credential can be layered into an image during the build — copied in, set as a build arg, left in an intermediate layer — and never appear in the source the team reviews. Only scanning the image catches secrets that live in the artifact rather than the repo.
No Link Between the Image and the Running Workload
Even an image scan in isolation leaves a question: which of these images is actually running, where, and how exposed is it? A list of image CVEs with no connection to the EKS workloads and EC2 services running them is just another queue to guess at.
How Cloudanix Addresses This
Build-Time and Runtime Image Scanning
Cloudanix scans container images at both build time and runtime for EKS workloads — producing SBOMs for each image, detecting CVEs, secrets, and license issues, and flagging fixability and exploitability. The image, the layer the team was missing, becomes a scanned surface rather than a trusted black box.

Workload Inventory and Runtime-Activity Correlation
Beyond scanning images in a vacuum, Cloudanix builds a workload inventory and correlates image findings with runtime activity — so the team sees which images are actually running in their EKS clusters, not just which exist in a registry. A CVE in an image that is deployed and internet-facing is distinguished from one in an image that is built but idle.

Severity From Fixability and Exploitability, Not Raw Count
Image scans are notorious for returning hundreds of base-image CVEs, most of which have no available fix or no real-world exploit. Cloudanix weights findings by fixability and exploitability so the team acts on the image CVEs that are both patchable and dangerous, rather than drowning in the inherited noise of a base image. (See how to prioritize which CVEs to fix.)
The Image as the Link Between Code and Cloud
Because image scanning sits on the same asset graph as Bitbucket code findings and AWS posture, the container becomes the connective tissue it is supposed to be: a dependency CVE in a repo, the image built from it, the EKS workload running that image, and the role that workload assumes are one connected path. The layer that pure code and pure cloud scanning both skipped is now the bridge between them. (Code-to-runtime context applies when the code, image, and runtime layers are connected for a given workload.)

Platform Impact
| Dimension | Code + Cloud Only | With Image Scanning |
|---|---|---|
| Base-image / build CVEs | Invisible | Scanned in each image |
| Secrets in layers | Missed | Detected in the artifact |
| Running vs idle | Unknown | Runtime-correlated workload inventory |
| Severity | Raw CVE count | Fixability + exploitability weighted |
| Code-to-cloud link | Gap at the container | Image bridges repo to workload |
Why the Image Is the Layer You Cannot Skip
Teams often assume that scanning source and scanning cloud configuration brackets their risk — but the running artifact sits between those two, and it is assembled from more than the source. Base images carry their own CVEs, build steps add packages and sometimes secrets, and none of that is visible to a manifest scan or a cluster-config scan. The container image is simultaneously the thing attackers actually run against and the natural join between code and cloud. Scanning it — at build time to catch issues before deploy, and at runtime to know what is truly exposed — is what makes a code-to-cloud story complete rather than a story with a hole in the middle.
Key Outcomes
- ✅ Build-Time + Runtime Scanning: CVEs, secrets, and licenses across EKS images.
- ✅ Workload Inventory: Which images are actually running, correlated to runtime activity.
- ✅ Exploitability-Weighted Severity: Act on patchable, dangerous CVEs, not base-image noise.
- ✅ The Missing Layer: The container surface that code and cloud scanning both skip.
- ✅ Bridges Code to Cloud: The image connects a Bitbucket repo to its EKS workload.
Lost Image Scanning in a Tooling Switch — or Never Had It?
If your platform ships as containers on EKS and your code and cloud scanning leave the image in the middle unexamined, Cloudanix scans images at build and runtime and ties them to the workloads actually running them.
Book a Free Assessment to see container image scanning across your EKS workloads, or explore the interactive demo on the Code Security page.
Related Resources
- How Code-to-Cloud Correlation Works
- How to Prioritize Which CVEs to Fix
- What is Software Composition Analysis (SCA)?
- What is Code Security?
- Correlating Bitbucket Code Findings With AWS EKS and EC2 Posture: Code-to-Cloud
- Code Security for Bitbucket: SAST, SCA, Secrets, and Real-Time Workspace Threat Monitoring