Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Gig-economy / Workforce SaaS Platform |
| Cloud Environment | AWS (production and non-production accounts) |
| Workloads | EKS and EC2 |
| Code & CI | Bitbucket for SCM, Jenkins for CI |
| Existing Setup | Cloudanix CSPM already onboarded; Bitbucket connected for code |
| Focus Area | Code and cloud, correlated on one graph |
The Situation: Two Halves Already on the Same Platform
This team had both halves of the picture already in place — they just were not connected yet. On the cloud side, they had onboarded Cloudanix CSPM across their AWS production and non-production accounts, with EKS and EC2 workloads. On the code side, they had connected Bitbucket for scanning. Misconfigurations were their top security focus and code was second — but those two priorities were being worked as if they were unrelated lists.
The opportunity here is different from a team starting cold: both the code findings and the cloud posture were already flowing into one platform. What remained was to stop treating “a CVE in a Bitbucket repo” and “an over-permissive EKS workload role” as two separate tickets, and start recognizing when they are two ends of the same exploitable path.
The Core Tension
A vulnerability in code only matters as much as where it ends up running and what it can reach. A cloud misconfiguration only matters as much as what code and data sit behind it. Assessed separately, a dependency CVE and a broad task role each look moderate. Assessed together — the CVE runs in an internet-facing EKS workload whose role can reach a production data store — they are a critical, exploitable path. The risk lives in the correlation, and a team that works code and cloud as two lists cannot see it, even when both lists are on the same platform.
Where the Gaps Were
A Code Finding Without a Destination
An SCA finding in a Bitbucket repo, on its own, cannot answer the questions that set its urgency: which container image is built from this repo, which EKS workload or EC2 service runs it, is it internet-facing, and what can its role reach? Without those answers, the finding is triaged in a vacuum.
A Misconfiguration Without Code Context
The mirror problem. CSPM flags an over-permissive EKS workload role or a publicly exposed service — but is there vulnerable code running in it? Is the exposed workload built from a repo with an unpatched dependency? The cloud finding is also triaged without its other half.
Two Priorities, Worked in Parallel
With misconfigurations as focus one and code as focus two, the same underlying risk generates work in two streams with no shared context — and the combined, genuinely critical path is under-rated by both, precisely because neither stream sees the whole of it.
How Cloudanix Addresses This
Code and Cloud on One Asset Graph
Because Cloudanix runs Code Security and CSPM on the same platform and a single asset graph, a Bitbucket repository, the image it produces, the EKS workload or EC2 instance that runs it, the role it assumes, the account, and the data are all nodes in one graph with typed relationships between them. The two halves this team already had become one connected model.
Following the Path: Repo → Image → Workload → Role → Data
With both ends on one graph, the platform traces the full route:
- A dependency vulnerability is found in a Bitbucket repository.
- The repository builds a specific container image.
- That image runs in a specific EKS workload (or on an EC2 service).
- The workload is internet-facing behind a permissive security group.
- Its role has broad access to a sensitive data store.
Individually, each step is moderate. Traversed as a path, it is a critical, exploitable route from a public endpoint to sensitive data — presented as one correlated risk, not five disconnected ones. (For the concept, see what an attack path is.)
Contextual Severity Computed From the Whole Path
Because contextual severity is recomputed from the graph, it reflects the full route. A dependency CVE that only runs in an internal, low-privilege EC2 batch job is de-prioritized; the same CVE in an internet-facing EKS workload with a broad role is elevated. The team’s two focus areas collapse into one correctly-ordered queue.
One Prioritized Queue Across Both Focus Areas
Instead of working misconfigurations and code findings as parallel lists, both ends feed one correlated view where the top items are the true attack paths — where a code weakness and a cloud exposure combine. For a lean DevOps team, that is the difference between two half-pictures and one clear one. (Code-to-runtime context applies when the code, image, and runtime layers are connected for a given workload.)
Platform Impact
| Dimension | Code and Cloud as Two Lists | Correlated on One Graph |
|---|---|---|
| Code finding context | “A CVE in a repo” | Which image, workload, role, and data it reaches |
| Cloud finding context | “An over-broad role” | Whether vulnerable code runs behind it |
| Severity | Guessed per finding | Computed from the full path |
| Triage | Two parallel streams | One prioritized queue |
| Attack paths | Invisible | Surfaced as single correlated risks |
Why Connecting the Halves Is the Payoff
This team had already done the expensive parts — onboarding CSPM across their AWS accounts and connecting Bitbucket for code scanning. Running them as two separate priorities was leaving the biggest return on the table, because the risks that span code and cloud are exactly the ones attackers use, and they are invisible to either list on its own. The attack path from a vulnerable dependency to a public EKS workload to a broad role to sensitive data is the anatomy of a large share of real cloud breaches. Connecting the two halves they already had — not buying a third program — is what turns their existing investment into attack-path visibility.
Key Outcomes
- ✅ One Asset Graph: Bitbucket code findings and AWS posture on a single model.
- ✅ Full-Path Visibility: Repo → image → EKS/EC2 workload → role → data.
- ✅ Path-Aware Severity: Urgency computed from where code runs and what it reaches.
- ✅ One Prioritized Queue: Misconfig and code focus areas, correctly ordered together.
- ✅ Built on What They Had: CSPM and Bitbucket already onboarded — now correlated.
Running Code and Cloud as Two Separate Priorities?
If your Bitbucket code findings and your AWS EKS/EC2 posture are already in Cloudanix but worked as two lists, the risks that span them — the real attack paths — are slipping through both. Cloudanix puts them on one graph so you can see and rank the full path.
Book a Free Assessment to see code-to-cloud correlation on your own environment in under 30 minutes.
Related Resources
- How Code-to-Cloud Correlation Works
- What is an Attack Path, and Why Isolated Findings Mislead You
- Correlating GitLab Code Findings With AWS Cloud Posture: Code-to-Cloud for ECS Workloads
- What is CNAPP (Cloud Native Application Protection Platform)?
- Code Security for Bitbucket: SAST, SCA, Secrets, and Real-Time Workspace Threat Monitoring
