TL;DR: Cloud misconfigurations and compromised credentials remain the dominant cloud attack paths, with SentinelOne citing examples ranging from public S3 buckets exposing data to leaked API keys enabling lateral movement and exfiltration across cloud and supply chain environments. Basic hygiene still matters because attackers increasingly chain minor issues into broader compromise.
NHIMG editorial — based on content published by SentinelOne: Cloud misconfigurations and credential theft still drive cloud breaches
By the numbers:
- 86.9% of responders confirm they face challenges validating and prioritizing alerts and cloud events.
- 67.7% of organizations agree they generate so much cloud security data that their teams struggle to reach actionable insights.
Questions worth separating out
Q: What breaks when cloud credentials are exposed in developer environments?
A: Exposed cloud credentials break the assumption that development systems are low-risk staging areas.
Q: Why do cloud misconfigurations remain dangerous even with CSPM in place?
A: CSPM can identify many configuration issues, but it does not automatically determine which combination creates a viable attack path.
Q: How should teams reduce the risk from exposed NHI secrets?
A: Teams should combine secret discovery, immediate revocation, enforced rotation, and tighter access controls around repositories, logs, and collaboration tools.
Practitioner guidance
- Map misconfiguration chains, not isolated findings Correlate public exposure, insecure roles, storage settings, and function permissions into one review workflow so weak links are assessed as a path to compromise, not as separate tickets.
- Expand secret discovery into development and runtime Scan source control, build artefacts, environment files, and cloud workloads for exposed API keys, tokens, and certificates, then revoke the credential before it is reused.
- Apply lifecycle controls to cloud credentials Assign owners, expiry rules, rotation cadence, and revocation triggers to every service account and API key so cloud secrets are managed as identities with defined boundaries.
What's in the full article
SentinelOne's full cloud risk report covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of cloud credential theft, lateral movement, and exfiltration patterns across real attack themes
- The survey breakdown behind CSPM, secret scanning, and misconfiguration prioritisation findings
- Use cases showing how attacker-driven misconfigurations are created in cloud environments
- The report's fuller treatment of AI services as a new cloud attack surface
👉 Read SentinelOne's analysis of cloud misconfigurations and credential theft →
Cloud misconfiguration chains and credential theft: what teams are missing?
Explore further
Cloud misconfiguration is now a governance problem, not just a posture problem. The article shows that organisations can own CSPM tooling and still fail to stop real-world exposure because alert volume, validation friction, and poor prioritisation leave the highest-risk issues unresolved. The named concept here is misconfiguration chain risk, meaning several low-severity issues combine into a practical breach path. Practitioners should manage cloud posture as a connected control system, not a queue of individual findings.
A question worth separating out:
Q: Who should own cloud secret and role governance?
A: Cloud secret and role governance should be shared across IAM, PAM, cloud security, and platform teams because the risk crosses boundaries. IAM owns identity lifecycle, PAM governs elevated access, and cloud teams control the configurations that expose or overextend those identities. Shared ownership is the only way to close the loop on exposure, privilege, and revocation.
👉 Read our full editorial: Cloud misconfigurations and credential theft still drive cloud breaches