Ask any security engineer running a CSPM tool about their biggest daily frustration, and a common answer is some version of: “everything is Critical, so nothing is.” This is not a complaint about the tool finding too many problems. It is a complaint about the tool being unable to tell the difference between a problem that matters and one that doesn’t — and that inability has a specific, fixable cause: flat, per-rule severity scoring.
What Flat Severity Actually Does
Most cloud security tools assign a severity level to a rule, not to the specific instance of a finding. The rule “S3 bucket allows public read access” might be tagged Critical. Every time that rule fires — on any bucket, in any account, for any reason — the finding inherits that same Critical label, regardless of what is actually in the bucket, who can reach it, or what else is true about the surrounding environment.
This sounds reasonable until you consider two buckets side by side:
- Bucket A: An internal, dev-environment bucket holding build artifacts, in an account with no internet-facing services, accessible only to a small, tightly-scoped engineering role.
- Bucket B: A production bucket holding customer records, sitting behind a public-facing application, reachable by a broadly-privileged service role.
Flat severity scores both of these identically: Critical, because the rule is the same. But the actual risk they represent is not remotely comparable. Bucket A’s misconfiguration is a real issue worth fixing, eventually, in a routine cleanup. Bucket B’s misconfiguration is an active, exploitable path to customer data that should be the first thing anyone looks at this morning.
Why This Causes Alert Fatigue, Not Just Annoyance
Alert fatigue is often described as a volume problem — too many findings. It is more precisely a signal problem. When severity does not correlate with actual risk, engineers learn, correctly, that the severity label is not a reliable guide to what to do next. Once that lesson is learned, the label stops functioning as a prioritization tool at all. People either work through findings in an arbitrary order (oldest first, alphabetical, whatever the dashboard defaults to) or they stop trusting the tool’s output altogether and fall back on gut instinct.
Both outcomes are bad. The first wastes time on low-risk findings while high-risk ones wait their turn. The second discards the tool’s actual value — its ability to see across the whole environment — in favor of whatever a tired engineer happens to remember to check.
The Core Idea: Severity Is a Property of the Asset, Not the Rule
The fix requires a different starting assumption. A misconfiguration’s severity is not an intrinsic property of the rule that detected it. It is a function of the specific asset it sits on, and the world that asset exists in. The same rule violation, on two different assets, can and should score differently — because the risk genuinely differs.
Getting this right requires recomputing severity per finding, using several inputs together:
- Exposure. Is the resource reachable from the public internet, or only internally? A misconfiguration on an internet-facing resource is categorically more dangerous than the identical one on a resource nothing outside the VPC can reach.
- Environment. Is this production, staging, or a personal dev sandbox? The blast radius of a compromised production resource dwarfs that of a throwaway dev one, even for the same underlying flaw.
- Data sensitivity. What does the resource actually hold? A misconfigured bucket of public marketing assets and a misconfigured bucket of customer PII should never wear the same severity badge.
- Identity and reachability. This is the input most tools omit entirely. Who — which roles, which users, which services — can actually reach this asset, and how privileged are they? A misconfiguration reachable only by a tightly-scoped internal role carries far less risk than the identical one reachable by a broadly-privileged identity or an unauthenticated public endpoint.
What Good Contextual Severity Looks Like in Practice
A well-implemented contextual severity model does three things a flat model cannot:
-
It differentiates identical rule violations by real-world context. The same rule can produce a Low finding on one asset and a Critical finding on another, and both scores are defensible because they reflect the actual situation.
-
It shows its reasoning. A number alone is not actionable. A good system explains why a finding scored the way it did — this asset is public-facing, holds sensitive data, and is reachable by an over-privileged role, for example — so the team can trust the ranking and explain it to others.
-
It reduces noise without hiding anything. Nothing disappears from the list. Findings are simply ordered by genuine risk, so the top of the queue is reliably where the real problems are, and lower-priority items are visible whenever there is time to address them, rather than competing for attention they do not deserve yet.
Why Identity Is the Missing Piece Most Often
Of the four inputs above, identity is the one most frequently absent from cloud security tooling, because it requires correlating posture findings with an entitlement model — often a separate product category (CIEM) that many CSPM tools do not integrate natively. This is a meaningful gap: exposure and data sensitivity describe how bad a compromise could be, but identity describes how likely a compromise is to actually reach the asset in the first place, and whether the entity that reaches it can do meaningful damage once there. A misconfiguration that is technically exposed but reachable only by an identity that can do almost nothing is a materially different risk from the same misconfiguration reachable by an identity with broad write access.
The Practical Test
If your current tooling assigns the same severity to a rule regardless of the asset it fires on, you have flat severity — and you are very likely experiencing some version of alert fatigue as a result, whether or not you have named it that. The test is simple: pick any Critical finding from your dashboard and ask whether you can explain, in one sentence, why it is more urgent than another Critical finding from the same rule elsewhere in your environment. If the honest answer is “they’re both Critical because the rule says so,” the ranking is not doing its job, and the fix is not fewer rules — it is scoring that finally accounts for where each finding actually lives.
People Also Read
- What is an Attack Path, and Why Isolated Findings Mislead You
- Correlating Identity with Misconfigurations: Why Contextual Severity Needs the IAM Graph
- Top 10 Challenges of Cloud Security Posture Management
- CIEM Solution: How Cloud Infrastructure Entitlement Management Reduces Breach Risk
- What is CSPM (Cloud Security Posture Management)?
