The default dashboard in your CSPM tool is almost certainly wrong for you.

Not wrong as in broken. Wrong as in optimized for someone else's environment, someone else's priorities, someone else's risk tolerance. Out of the box, you get a generic view designed to look impressive in a demo. What you need is a view designed to help you actually fix things.

Here's what we typically see when we first log into a CSPM that hasn't been tuned: hundreds, sometimes thousands of critical and high-risk alerts. You can't even make sense of it. The dashboard is a wall of red and orange that's been that way for months. Alert fatigue is a design choice. You can make different choices.

Building Views That Work

We've built 25 to 35 custom discovery views for every environment we manage. That's not overkill. That's what it takes to see what matters. Some examples:

Publicly exposed cloud services: HTTP/HTTPS listeners across your environment. Simple inventory of web servers.

Non-web services: Anything not on ports 80 or 443. SSH servers, database interfaces, custom APIs. This list is always worth reviewing because non-web services often get less scrutiny.

Internet-facing data storage: S3 buckets, Azure storage accounts, RDS instances with public exposure. These deserve dedicated attention because the blast radius of a misconfiguration is significant.

Untagged PII locations: Assets detected with sensitive data that haven't been confirmed as legitimate. This inverse view (show me what's flagged but not yet validated) drives investigation rather than just alerting.

Each view answers a specific question. Who's exposed? What changed? Where are the gaps in our understanding?

The Tagging System

Views become powerful when combined with consistent tagging. We preload custom tags across every environment:

Known Admin: Tag identity groups, IAM roles, and individual accounts that have legitimate administrative access. Once tagged, these stop generating repetitive alerts. The interesting alert becomes "new admin access that's not on the known list."

Known PII: Tag assets confirmed to contain personal or health information. The database holding customer records should have PII. The development server shouldn't. The interesting alert is untagged PII in unexpected places.

Accepted Risk: Tag findings that represent conscious decisions not to remediate immediately. Maybe the system is being decommissioned. Maybe the fix breaks other things. The risk is acknowledged, tracked, and periodically reviewed.

This flips the default model. Instead of dismissing alerts after you've seen them enough times, you acknowledge them explicitly up front. Your monitoring then surfaces what's genuinely new or unexpected.

IAM: Where Signal-to-Noise Hits Hardest

Identity and Access Management is where the noise problem is most acute. IAM is complex, constantly changing, and critical to get right.

The patterns we see repeatedly:

The "Developers" group with full admin: Someone created an IAM group and attached admin permissions because it was faster than figuring out exactly what developers need. Now every engineer who joins gets dropped into that group. The scanner flags it every day, and everyone ignores the alert.

QA teams with IAM permissions: We've seen outsourced QA teams granted permissions that enable privilege escalation. Not because anyone intended to give them that access, but because someone attached an AWS managed policy without understanding what was in it.

AWS managed policy surprises: You might think AWS managed policies are safe because Amazon made them. But these policies contain permissions like iam:PassRole that enable privilege escalation. Attaching "Lambda Full Access" grants the ability to pass admin roles to functions, potentially escalating from developer to admin. And these policies can change without notice.

CSPM tools flag all of this. But the flags are overwhelming unless you know which access is intentional and which is accidental.

The Long-Lived Credential Problem

IAM access keys deserve special attention because they tend to persist far longer than anyone intended.

We've found API keys that have existed for years. In one case, 15-year-old admin keys. God only knows where they're living at this point. Keys created for a specific integration that's long gone. Keys attached to users who left the company months or years ago.

The solution is layered:

SSO integration: Connect your identity provider with AWS. When someone leaves the company and their account gets deactivated, their cloud access goes away automatically.

Short-lived sessions: AWS SSO CLI tools make it easy to use temporary credentials instead of static keys. You authenticate, get a session that expires, and keep working. If credentials leak, they're useless within hours.

Tag what remains: For the keys you can't eliminate, tag them with owner and business unit. When you're investigating or doing periodic reviews, you can actually trace accountability.

Container Bloat: Another Source of Noise

The noise problem extends to attack surface itself.

A pattern we see everywhere: developers install everything including the kitchen sink into container images because they don't want to troubleshoot missing dependencies. If you're not sure what the application needs to run, easier to include everything than debug what's missing.

The result is bloated images with hundreds of packages, most of which the application never touches. Every package is a potential vulnerability. Your scanner dutifully reports all of them. Now you're triaging CVEs for software you don't even use.

The solutions exist:

Slim base images: Start with minimal distributions instead of full operating systems. If you don't install a package, you don't have to patch it.

Distroless or hardened images: Chain Guard, Google's Distroless, and Docker's hardened images strip out everything except what your application actually needs. Fewer packages, fewer vulnerabilities, less noise.

Same pattern as IAM: reduce the surface area, and the signals that remain are more likely to matter.

The Takeaway

Alert fatigue is a symptom of generic configuration applied to specific environments. The cure is building views that match how you think about risk.

Tag what you know. Build views that surface what's new. Track what you're accepting. Reduce attack surface so there's less noise to begin with.

If your dashboard has been showing hundreds of critical alerts for months and nobody knows which ones actually matter this week, you're not alone. Sometimes you just need someone who's done this across dozens of environments to set things up so the tools actually work for you.

---

Jon Rose runs IOmergent, advising engineering-led companies on security strategy and managed cloud security operations.