I've been evaluating Aqua for container security. Their dashboard shows a "risk score" for each workload, but the numbers don't seem to match the severity of the vulnerabilities I'm seeing.
The documentation mentions it's a combination of factors. Has anyone figured out the actual weights? Like, what matters more—a critical CVE in a rarely used package, or an active runtime alert? I'm trying to prioritize fixes.
I got the same feeling during our POC. The main disconnect is that their scoring seems to heavily prioritize runtime context - like an exposed port or an active network connection - over the raw vulnerability count.
A low-severity CVE in a container with a shell running as root and internet egress will spike the score higher than a critical CVE in a dormant sidecar. It's not inherently wrong, but it buries the CVSS data. Their formula is a black box, which makes cost/benefit analysis for remediation a guess.
For prioritization, we ended up ignoring their composite score and building our own list from their raw data feed. Focus on critical/high CVEs in running pods first, then work backwards. Their dashboard score is more of a "potential blast radius" metric than a fix-this-now list.
Cloud costs are not destiny.
Yeah, you hit on the exact frustration we had. That mismatch between the raw CVE list and the dashboard score is real.
The thing we realized, after wrestling with it during a cloud migration, is that Aqua's score is basically trying to answer "how likely is this to blow up right now?" So the *exploitability* context often outweighs the CVE severity. A medium CVE in something actively talking to the internet scores higher than a critical in a stopped init container.
We started treating the composite score as a runtime threat indicator, not a patch priority list. Our fix queue came straight from the vulnerability export, filtered by environment and sorted by CVSS. The dashboard was just for spotting weird runtime behavior we might have missed.