← Back to news 17.08.2026

Fine alone, critical together

The severity of a cloud misconfiguration comes from the catalog. But the catalog does not know the resource the check fired on. How we resolved that, and why a single risk factor raises nothing.

A report on cloud misconfigurations is first of all a sorted list. What is critical sits at the top, the rest below. That order decides what gets worked on come Monday, which makes it the most important thing in the whole report.

But where does the severity come from? From the check catalog. It records how heavily a violation weighs for each check. The catalog, however, does not know the resource the check fired on.

Same check, two situations

An unencrypted storage bucket in an isolated test project is a defect. It should be fixed, but nobody needs to work late over it.

The same unencrypted bucket, publicly reachable, is a different matter. The check is the same, the catalog entry is the same, the situation is not.

Severity, then, is not a property of the check. It is a property of the resource the check fires on.

Four factors, and none counts on its own

We therefore track four context factors on every recorded resource: internet-exposed, privileged, sensitive data, unencrypted. They come from the inventory, not from manual upkeep.

The point that took longest to settle while building: a single factor raises nothing. An internet-exposed resource is not inherently a heavier case, otherwise every web server would be a permanent problem. A finding is raised only when two factors meet. Three pairs ship by default, all three with exposure as one of the two halves: exposed and unencrypted, exposed and privileged, exposed with sensitive data.

And the raise moves exactly one level, not straight to critical. That is a deliberate decision against the obvious alternative. Jump to the top level on every dangerous combination and after two weeks you have a list where everything is critical. The ordering is then worthless again, and the report is exactly where it would have been without any context at all.

A silent raise would be worse than none

A severity that changes along the way without being traceable is no progress. So the finding carries both: the catalog severity and the effective one after context. Plus the rule that raised it, in plain words.

What you read on a finding is therefore not just "high", but: the catalog says medium, here it is high because this resource is exposed and unencrypted. That is the difference between an assessment you can argue with and a number you have to accept.

For the same reason the rules are not hard-wired logic but data. There is an editor for them. What counts as a dangerous combination in your environment is something you know better than we do.

What changes in practice

The list gets neither longer nor shorter. It gets sorted differently. At the top sit the cases where several things coincide, and those cases carry their justification with them.

More on the CSPM module page.

Matching solution isidaten for BSI IT-Grundschutz

Questions about this update?

Talk to us – we are happy to show you this feature in a demo.