Your CSPM Won't Save You — Why Cloud Security Is a Governance Problem

I keep seeing the same pattern across large enterprise accounts: a company deploys a world-class CSPM, checks the “cloud security” box, and then gets hit by an IAM credential leak that their tooling never caught. The problem isn’t the tool. It’s what happens between the tool producing a finding and someone actually fixing it.

The Problem

A global manufacturing enterprise — multi-account AWS landing zone, hundreds of workloads across EMEA, LATAM, and APAC — invested in a leading third-party CSPM. Wiz, Prisma, Orca — the specific vendor doesn’t matter. They had full visibility into misconfigurations, vulnerability scanning, and risk prioritization. On paper, their security posture looked solid.

Then, within six months, they faced three major security incidents:

1. Access key exfiltration from a public Git repository — a developer committed AWS credentials to a public repo. Automated scanners (TruffleHog, GitLeaks) found them within minutes. The attacker used the keys before anyone on the security team even knew they were exposed.

2. Credential compromise via endpoint malware — malware on an external contractor’s laptop harvested cached AWS credentials. The compromised keys were used from an anomalous geographic location, but no alert fired in time.

3. A third IAM-related incident in the same timeframe, following the same pattern: a valid credential used in an unauthorized way, detected too late.

Three incidents. Same root cause every time: a credential existed where it shouldn’t, and nobody was watching the signals that would have caught it.

The CSPM detected misconfigurations. It flagged overly permissive IAM policies. It scored risks. But it didn’t aggregate signals across accounts. It didn’t correlate a new API call pattern with a known leaked key. It didn’t auto-disable the compromised credential. And critically, there was no workflow connecting “finding generated” to “finding remediated.”

The enterprise had a detection tool. What they lacked was security governance — the ability to aggregate, correlate, and act on security signals in real time, across all accounts, with automated remediation.

The Solution

The answer isn’t replacing the CSPM. It’s adding a native governance layer underneath it — one that operates at the AWS control plane level, sees every API call, and can act autonomously when something goes wrong.

The architecture has three components:

1. AWS Security Hub — aggregates findings from all sources (the third-party CSPM, GuardDuty, IAM Access Analyzer, Config, Inspector) into a single pane with normalized severity scores. Cross-account, cross-region, org-wide.
2. Amazon GuardDuty — detects anomalous API behavior (unusual geolocations, impossible travel, known malicious IPs) on every API call via CloudTrail. This is what catches a leaked key being used from a new location.
3. IAM Access Analyzer — continuously monitors for unused credentials, overly permissive policies, and external access paths. Finds the keys that shouldn’t exist before they get leaked.

Tied together with EventBridge + Lambda for automated remediation: when a critical finding fires, the key gets disabled, the security team gets paged, and an incident ticket gets created — all without human intervention.

How It Works

Why a CSPM Alone Isn’t Enough

A CSPM scans your cloud environment on a schedule (typically every few hours) and produces a prioritized list of findings. It’s excellent at answering: “What’s misconfigured right now?”

But it doesn’t answer:

• “Is someone actively exploiting this misconfiguration?”
• “Did the access key we flagged last week just get used from an IP in a country we don’t operate in?”
• “Across our 200 accounts, which findings are related to the same root cause?”

This is the gap. A CSPM is a scanner. Governance is an operating system — it aggregates, correlates, and orchestrates.

Capability	CSPM	Governance Layer
Misconfiguration detection	Yes	Yes (via Config rules)
Real-time threat detection	No (periodic scan)	Yes (GuardDuty, every API call)
Cross-account aggregation	Partial	Native (Security Hub org-wide)
Signal correlation	Basic (risk score)	Deep (finding relationships, attack paths)
Automated remediation	No (findings only)	Yes (EventBridge + Lambda)
Credential lifecycle monitoring	No	Yes (IAM Access Analyzer)
Time to detect a leaked key in use	Hours (next scan)	Minutes (GuardDuty)

Anatomy of an IAM Key Leak — With and Without Governance

Here’s what the access key exfiltration incident looked like, and what would have been different with a governance layer in place.

Without governance:

1. Developer pushes code with hardcoded AWS access key
2. Automated scanner (TruffleHog) finds key in public repo (minutes)
3. Attacker uses key to call AWS APIs
4. CSPM detects "overly permissive key" in next scheduled scan (hours later)
5. Finding sits in CSPM dashboard with 200 other findings
6. Security team triages manually (next business day)
7. Key is finally revoked (12-48 hours after compromise)

With governance:

1. Developer pushes code with hardcoded AWS access key
2. IAM Access Analyzer had already flagged this key as unused (preventive)
3. Attacker uses key — GuardDuty detects anomalous API call pattern (minutes)
4. Security Hub receives GuardDuty finding, correlates with CSPM's
   "overly permissive" finding, elevates severity to CRITICAL
5. EventBridge triggers Lambda → key is auto-disabled (seconds)
6. SNS notifies security team + creates incident ticket
7. Total exposure time: minutes, not days

The difference is an order of magnitude. Not because the CSPM was bad — it correctly identified the overly permissive key. But identification without action is just a to-do list.

The Three Pillars of Cloud Security Governance

After working through this pattern with several enterprise accounts, I’ve landed on a framework for what “governance” actually means in practice:

Pillar 1: Aggregate Everything Into One Place

Security Hub is the aggregation layer. It ingests findings from:

• Third-party CSPM (Wiz, Prisma, etc. — they all have Security Hub integrations)
• GuardDuty (threat detection)
• IAM Access Analyzer (credential and access risks)
• AWS Config (compliance rules)
• Inspector (vulnerability scanning)
• Firewall Manager (network security)

All findings get normalized to the AWS Security Finding Format (ASFF), scored consistently, and visible org-wide. Without this, your security team is tab-switching between six dashboards.

Pillar 2: Correlate Signals to Identify Active Threats

A misconfiguration finding alone is low urgency. A misconfiguration finding + an anomalous API call from a new IP + a recently rotated key = an active compromise. Correlation is what turns noise into signal.

Security Hub’s finding relationships and GuardDuty’s behavioral analysis do this natively. The CSPM provides the posture data. GuardDuty provides the runtime threat data. Security Hub connects them.

Pillar 3: Automate the Response

This is where most enterprises stall. They aggregate, they correlate, they even prioritize — but remediation is manual. Someone has to log in, find the key, disable it, check for lateral movement, file a ticket.

Automated remediation via EventBridge + Lambda closes this gap:

# Example: Auto-disable compromised IAM access key
import boto3

def handler(event, context):
    # Security Hub finding via EventBridge
    finding = event['detail']['findings'][0]

    # Extract the compromised access key
    resource = finding['Resources'][0]
    access_key_id = resource['Details']['AwsIamAccessKey']['AccessKeyId']
    principal = resource['Details']['AwsIamAccessKey']['PrincipalName']

    iam = boto3.client('iam')

    # Disable the key immediately
    iam.update_access_key(
        UserName=principal,
        AccessKeyId=access_key_id,
        Status='Inactive'
    )

    # Notify via SNS
    sns = boto3.client('sns')
    sns.publish(
        TopicArn='arn:aws:sns:eu-west-1:123456789:security-alerts',
        Subject=f'ACCESS KEY DISABLED: {access_key_id}',
        Message=f'Compromised key for {principal} auto-disabled. '
                f'Finding: {finding["Title"]}'
    )

This Lambda fires within seconds of GuardDuty detecting the anomalous behavior. The key is dead before the attacker finishes their reconnaissance.

Making It Work With Your Existing CSPM

This isn’t about replacing Wiz or Prisma. Most third-party CSPMs have native integrations with Security Hub — they push findings directly into it. The architecture becomes:

• CSPM handles posture scanning, risk prioritization, and developer-facing dashboards
• Security Hub handles aggregation, correlation, compliance standards, and remediation orchestration
• GuardDuty handles runtime threat detection that the CSPM can’t do (it doesn’t watch API calls)
• IAM Access Analyzer handles credential lifecycle that the CSPM doesn’t cover

They’re complementary layers, not competing tools. The CSPM tells you what’s wrong. The governance layer makes sure something happens about it.

What I Learned

• Security tooling without governance is just a dashboard — the enterprise had full CSPM coverage and still got hit three times in six months. The gap was never detection. It was aggregation, correlation, and automated response.

• IAM is the most undermonitored attack surface — access keys sitting in repos, unused credentials with admin privileges, overly permissive roles. CSPMs flag these as “medium” findings. In practice, they’re the #1 vector for account compromise.

• The CISO conversation should be about governance, not tools — when a new security leader comes in, the instinct is to evaluate new tools. The higher-leverage conversation is: “Can you aggregate signals across all accounts, correlate them in real time, and auto-remediate critical findings today?” If the answer is no, that’s the gap to close first.

Do It Yourself

Key takeaways:

• Detection without response is just a to-do list — CSPMs identify misconfigurations, but the gap between “finding generated” and “finding remediated” is where breaches happen. Automated remediation via EventBridge + Lambda closes this gap from hours to seconds.
• IAM credentials are the #1 attack vector — Leaked keys in repos, unused credentials with admin privileges, overly permissive roles. CSPMs flag these as “medium” findings, but in practice they’re the primary path to account compromise.
• Governance is aggregation + correlation + automation — Security Hub aggregates findings from all sources into one view. GuardDuty correlates runtime behavior with posture data. EventBridge automates the response. All three together form a governance layer your CSPM alone cannot provide.

Try it now:

1. Enable Security Hub org-wide — Follow the Security Hub multi-account setup guide to aggregate findings across all accounts in your AWS Organization from a central administrator account.
2. Deploy GuardDuty with automated key disabling — Use this sample Lambda function to auto-disable compromised IAM keys when GuardDuty detects anomalous usage. Test it by triggering a known GuardDuty finding type.
3. Integrate your CSPM with Security Hub — Check if your CSPM (Wiz, Prisma, Orca) supports Security Hub integration and enable it. This lets you correlate CSPM posture findings with GuardDuty threat detections in one pane.