Just saw the dashboard update. The new "risk score" front and center is giving me AWS Cost Explorer vibes, but at least there I can drill down into line items. This feels opaque.
I get the need for a single metric, but if I'm going to prioritize fixes for my team, I need to know what's driving it. Is it 90% because of one critical flaw? Or 50% because we have a ton of low-severity findings? The documentation mentions "exploitability, prevalence, and age" but doesn't show the math.
Has anyone gotten a clear answer on the actual calculation? Or found a way to reverse-engineer it from the findings list? My main concerns:
* Can a minor finding in a rarely-used endpoint tank the score as much as a major flaw in a public API?
* How does the "age" weighting work? Is it linear or does it ramp up after a specific SLA window?
* Does it factor in context, like if a finding is in a container vs. a lambda function (where the exposure might be different)?
Without transparency, it's hard to trust it for anything more than a high-level trend line. I'd rather build my own risk metric from the raw findings data if this is just a proprietary magic number.
cb
Great points, and that AWS Cost Explorer comparison is spot-on. You've hit on the core issue: a metric you can't decompose for action might as well be decorative.
On the math, I haven't seen them publish the exact algorithm either, which is a common vendor tactic to avoid gaming. But in my experience, the "age" component usually follows a stepped curve, not a straight line. Think of it as a grace period with a minor weight, then a significant multiplier kicking in after, say, 30 or 90 days to mimic SLA breaches.
Your question about context - container vs. lambda - is the real kicker. Most of these platform-level scores don't ingest that depth of architectural context, which is exactly why they can be misleading. A critical flaw in an internal, ephemeral function is not the same business risk as one in a customer-facing monolith, but the score often treats them the same. Have you tried raising this with your account manager? Sometimes pressure for transparency can at least get you a weighted breakdown per finding.
Architect first, buy later
Totally agree on the need to decompose it for action. If you can't see the components, you can't assign a ticket or argue with finance about headcount.
I haven't reversed-engineered the exact math, but I did a messy experiment last quarter by creating a parallel "shadow" score from our exported findings. I weighted severity (CVSS), asset importance (from our CMDB), and days open with a 30-day grace period. The correlation with their score was... weak. Like, a 0.6 at best. That gap tells me they're baking in proprietary data - maybe threat intel feeds or inferred traffic patterns - that we just don't have access to. So it's not *just* about your listed factors.
Your point about building your own metric is the pragmatic path, honestly. It's more work, but at least the levers are visible to your team. Their score might be useful as a lagging indicator for execs, but I wouldn't let it dictate my team's sprint planning.
Pipeline is king.
The stepped curve for age is a solid guess, but vendors also tweak those grace periods based on license tiers or threat intel updates, which adds another layer of opacity. Your account manager suggestion is the right move, though. In my experience, they'll sometimes share a per-finding contribution percentage if you push hard enough, even if they won't give you the formula. It's not perfect, but it turns a decorative score into something you can actually work with.
—AF
Yeah, that question about a minor finding in a rarely-used endpoint vs. a major public API flaw really hits home for me too. I'm new to this and our team was just looking at our own score, wondering the same thing.
It makes it hard to explain to my manager what we actually need to fix first, you know? If the score's a mystery, how do we even start? I like the idea of asking an account manager for the per-finding contribution, that seems like a practical step.
Has anyone had luck with that approach, or do they usually just point you back to the docs?
I feel your pain on explaining it to management - been there! While asking your account manager for per-finding contribution is a solid first move, I've found they often share a dashboard view or a CSV export with a "score impact" column instead of the formula. That can still get you started.
From my own talks with support, the response really depends on your contract size. If you're a big fish, you might get more details. But for most of us, they'll likely give you the factors (exploitability, etc.) without the weights, which brings us back to the black box.
What worked for me was building a parallel "actionable score" in a spreadsheet, using the exported findings. I assigned my own simple weights based on our internal asset criticality (public API vs internal endpoint) and CVSS score. It's not perfect, but it gave me a clear story for my manager that was tied directly to our infrastructure. Maybe try that while you push for more transparency?
— francesc
Your parallel "actionable score" spreadsheet is the only reliable path forward. I've done the same thing, but I automated it. I ingest the CSV export into a small Terraform module that enriches each finding with tags from our cloud inventory, then applies our own internal logic for business criticality and exposure.
The problem with the vendor's "score impact" column is it's still a derived value from their black box. You're just seeing the output, not the function. I've seen that column shift by 15 points overnight after a threat intel update, with zero changes to our own infrastructure. That makes it useless for tracking internal remediation progress.
Push for transparency, but build your own metric in parallel. Treat their risk score like a weather forecast - maybe informative, but you wouldn't stake your compliance reporting on it.