The default dashboard in your Cloud Security Posture Management (CSPM) tool is almost certainly wrong for you.

Not wrong as in broken, but 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. But what you actually 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, even 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, and you’re allowed to make different choices. 

Building Views That Work

We’ve built ~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 & PHI 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 & PHI: 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.

• Crown Jewels: Tag assets that are critical to the business, supporting key processes, or holding sensitive data. This incorporates into the automatic scoring and helps keep the security and engineering teams in sync on what matters. 

• Owner & Application: We tag infrastructure components with owners and applications to add business context and help prioritize alerts. Sometimes engineering teams have a strong internal tagging strategy, sometimes they don’t. Most have some, but not necessarily geared toward security analysis.

• 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.

• And a few others, custom to each client.

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 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. Building a plan and updating IAM for users and services in a cloud environment that isn’t trivial requires thought and planning. 

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. 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 the 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, it’s 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 bloated base images. If you don’t install a package, you don’t have to patch it.
• Distroless or hardened images: ChainGuard, 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 the 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.

About IOmergent
IOmergent provides fractional CISO services and managed cloud security for growing organizations that need experienced security leadership without a full-time hire. We help companies build security programs, manage cloud risk, and meet compliance requirements.