Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Gig-economy / Workforce SaaS Platform |
| Cloud Environment | AWS |
| Workloads | EKS and EC2 |
| Code & CI | Bitbucket for SCM, Jenkins for CI |
| Team Structure | Lean DevOps team (3) supporting ~20 engineers |
| Prior Tooling | Moving off a cloud-first security tool |
| Focus Area | Dependency CVE prioritization for a sprint |
The Situation: “We’ll Fix High and Critical Next Sprint” — But Which Ones?
This team runs a gig-economy SaaS platform on AWS, with code in Bitbucket and a lean DevOps function supporting a larger engineering group. Misconfigurations were their primary security focus, with code a close second, and they had made a concrete commitment: in the next sprint, they would prioritize and remediate the high and critical vulnerabilities in their repositories.
It is a reasonable plan — until you run the first dependency scan and the list comes back with hundreds of entries, a large share of them tagged “high” or “critical” by raw CVSS. A lean team cannot fix hundreds of things in one sprint, and “high and critical by severity label” is not a short enough list to be actionable. The real question underneath their plan was never “which findings are high?” — it was “which of these will actually get us breached, and therefore belong in this sprint?”
The Core Tension
CVSS severity labels describe how bad a vulnerability could be in the abstract, not how likely it is to be exploited in this environment. A team that sorts by CVSS alone ends up with a queue that is both too long to finish and wrongly ordered — spending sprint capacity on a theoretically-critical CVE in a dev-only dependency while a genuinely exploited one waits behind it.
Where the Gaps Were
A Severity Label Is Not a Priority
CVSS answers “how severe is this class of flaw?” It does not answer “is anyone exploiting it right now?” or “how probable is exploitation in the next 30 days?” Two CVEs can both be CVSS 9.1 while one is actively weaponized and the other has no known exploit anywhere. Treated identically, the team’s limited sprint time is spread evenly across findings that carry wildly different real-world risk.
Transitive Dependencies Hide the Real Exposure
Most dependency risk does not live in the packages a team chose directly — it lives several layers down, in the transitive dependencies those packages pull in. Without a scanner that resolves the full dependency tree from manifests and lockfiles, the “high and critical” list is incomplete to begin with, and the sprint plan is built on a partial picture.
No Single Feed Sees Everything
Relying on one advisory source (NVD alone, for example) means CVEs that appear first in an ecosystem-specific database or a vendor advisory are missed or arrive late. Coverage gaps become prioritization gaps.
How Cloudanix Addresses This
SCA That Resolves Direct and Transitive Dependencies
Cloudanix Code Security connects to Bitbucket and runs SCA across package manifests and lockfiles, resolving both direct and transitive dependencies and generating a CycloneDX SBOM per repository. The “high and critical” list the team plans against is therefore complete — it includes the deep transitive CVEs that a manifest-only view would miss.
Exploitability-Ranked, Not Just Severity-Labeled
Instead of matching against one feed, Cloudanix matches dependencies against a vulnerability database aggregating 28 upstream feeds — OSV, NVD, CVE, GitLab Advisory, Trivy, and ecosystem-specific databases — and layers CISA KEV (is this CVE in the Known Exploited Vulnerabilities catalog?) and EPSS (what is the statistical probability it will be exploited?) on top. The result is a queue ordered by real-world exploitability, not by abstract severity. A CVE in KEV with a high EPSS score rises to the top; a CVSS-critical CVE with no known exploit and a near-zero EPSS drops down the list. (For the method, see how to prioritize which CVEs to fix and what EPSS is.)
A Sprint-Sized Queue, With Fix Guidance
The practical output is a list short enough to finish: the handful of findings that are high severity and exploitable and reachable. Each carries remediation context — which version to upgrade to and whether it is a breaking change — so the sprint is spent fixing rather than researching, with selective AI-generated fixes for safe cases.
Severity That Reflects Where the Code Runs
Because Cloudanix also covers cloud posture on the same asset graph, a dependency CVE in a Bitbucket repo can be weighted by where the code actually runs on AWS — an internet-facing EKS workload with a broad role versus an internal batch job. The sprint queue then reflects exposure, not just the CVE in isolation. (Code-to-runtime context applies when the code, image, and runtime layers are connected for a given service.)
Platform Impact
| Dimension | Sorting by CVSS Alone | KEV + EPSS Prioritized |
|---|---|---|
| Queue length | Hundreds of “high/critical” | A sprint-sized shortlist |
| Ordering | Abstract severity | Real-world exploitability |
| Transitive deps | Often missed | Fully resolved |
| Feed coverage | Single source | 28 upstream feeds |
| Fix effort | Research per finding | Upgrade path provided |
Key Outcomes
- ✅ Exploitability-Ranked Queue: KEV + EPSS on top of 28-feed vuln intelligence.
- ✅ Complete Dependency Picture: Direct and transitive CVEs from manifests and lockfiles.
- ✅ Sprint-Sized Shortlist: The findings that are severe and exploitable, not the full flood.
- ✅ Actionable Remediation: Upgrade paths and breaking-change flags per finding.
- ✅ Context From the Cloud: Severity weighted by where the code runs on AWS.
Planning a Vulnerability-Fix Sprint and Drowning in “High and Critical”?
If your dependency scan returns hundreds of high and critical findings and your team can only fix a handful this sprint, Cloudanix ranks them by what is actually exploitable — so the sprint is spent on the CVEs that matter.
Book a Free Assessment to see your Bitbucket dependency risk ranked by KEV and EPSS in under 30 minutes, or explore the interactive demo on the Code Security page.
