Cloud vulnerabilities from pipeline to runtime: where to look and what to fix first
Three places to look
- The pipeline. Scanning container images and dependencies (SCA) before deployment stops known-vulnerable software from shipping. It misses anything installed later or images built elsewhere.
- The account. Agentless scanning reads workload disks or snapshots and finds what is installed across the whole estate, including old machines nobody rebuilds.
- The running workload. A sensor sees which packages are loaded into memory, which separates a vulnerable library that runs from one that sits unused on disk.
Why does ranking matter more than finding?
A medium estate can produce tens of thousands of findings, each tied to a CVE. Nobody fixes them all. Useful ranking combines severity with context:
- Is the workload reachable from the internet?
- Does it hold or reach sensitive data?
- Is the vulnerability being exploited in the wild? Public signals such as EPSS estimate this.
- Is the vulnerable package actually running?
How do vendors on this site describe their approach?
On the pages we read, Aqua ranks by reachability, EPSS scores and evidence of active exploitation; Sysdig uses runtime insight into which packages are in use; SentinelOne checks which exposures are exploitable and shows Verified Exploit Paths; Orca lists vulnerability management with attack path analysis; Cortex Cloud ranks with SmartScore. The vulnerability management page shows all nine.
Who fixes what?
Findings stall when nobody owns them. The fix for an image vulnerability is a rebuild in a pipeline; for a host, a patch; for a dependency, a code change. Ask how a finding reaches the person who can make that change: a ticket, a pull request, a message to the repository owner. Code-to-cloud tracing is the feature that answers this.