Cloud security in 2025: forgotten permissions and exposed secrets

At a glance

What this is: Orca Security’s 2025 cloud security report maps the most repeated cloud risk patterns, with identity, secrets, neglected assets, and pipeline misconfigurations combining into attack paths.

Why it matters: IAM, NHI, and security architecture teams need to treat cloud risk as a connected control problem because standing privilege, exposed secrets, and automation gaps amplify each other.

By the numbers:

• 93% of organizations have at least one overprivileged service account.
• 85% of organizations have plaintext secrets embedded in their source code repositories.
• 40% have GitHub Actions workflows configured to allow automatic pull request approvals.

👉 Read Orca Security’s 2025 cloud security report on identity, secrets, and attack paths

Context

Cloud security fails when identity, secrets, and deployment automation are treated as separate control planes. In this report, the recurring problem is not a single breach vector but repeated permission drift, exposed credentials, neglected assets, and pipeline shortcuts that expand attacker reach across cloud environments.

For IAM and NHI programmes, the important lesson is that cloud compromise often begins with legitimate access that was never tightened, revoked, or bounded well enough. That makes the issue a governance problem as much as a detection problem, because the attack paths are built from ordinary operational decisions.

Key questions

Q: How should security teams reduce cloud attack paths without slowing delivery?

A: Start with the paths that lead directly to sensitive data, cross-account access, or internet-facing workloads. Then remove the privilege chain that makes those paths possible, rather than chasing low-impact findings one by one. This approach reduces real exposure faster because it targets reachable compromise, not abstract severity scores.

Q: Why do overprivileged service accounts create such a large cloud risk?

A: Because a service account is often reusable, persistent, and able to reach many systems at once. If one credential is over-scoped, compromise of that single identity can expose several workloads, data stores, or accounts. The risk grows when the account is attached broadly and rarely reviewed.

Q: What do security teams get wrong about secrets found in source code?

A: They often treat removal from the current branch as the end of the problem. In reality, secrets can survive in Git history, forks, caches, and clones, and some remain valid after discovery. Effective response means rotation, revocation, and prevention, not just scanning for leakage.

Q: Who is accountable when a cloud misconfiguration exposes production data?

A: Accountability usually sits across security, platform, and application teams because the exposure is created by an operational decision, not a single technical mistake. Governance needs clear ownership for service accounts, repository controls, and access assumptions so that risky combinations are fixed before they become reachable attack paths.

Technical breakdown

Overprivileged service accounts and stale IAM roles

Service accounts are non-human identities that should hold only the permissions needed for their workload. When 93% of organisations have at least one overprivileged service account and 78% have IAM roles unused for more than 90 days, the problem is not just excess access. It is credential inertia. Stale roles remain valid long after ownership has faded, and permissive entitlements can fan out across many systems if one role is attached broadly. That creates a large attack surface even before any exploit occurs.

Practical implication: enforce entitlement review, unused-role retirement, and scope reduction for service accounts before they become reusable compromise points.

Plaintext secrets in source code and Git history

Secrets are credentials such as API keys, tokens, database passwords, and certificates. The report shows that 85% of organisations have plaintext secrets in repositories, 36% of those secrets are active in the current main branch, and 58% remain recoverable in Git history. That means removal from current code is not enough. Once a secret enters version control, it can persist through forks, commits, caches, and cloned workspaces. Exposure is therefore a lifecycle issue, not just a code-review miss.

Practical implication: shift from detection-only scanning to enforced secret removal, rotation, and developer controls that prevent secrets entering repositories in the first place.

Attack paths created by toxic combinations

An attack path is the chain of misconfigurations that turns isolated weaknesses into a route to data or privileged systems. Orca Security’s analysis shows that 13% of organisations have a single cloud asset that creates more than 1,000 attack paths, and the worst case reached 165,142. The technical issue is composition: an exposed credential, a public asset, and a broad role can be combined by an attacker even if each looks tolerable on its own. Security teams miss this when they rank findings individually instead of by reachable impact.

Practical implication: prioritise path-based remediation and blast-radius reduction instead of treating every cloud finding as an isolated ticket.

Threat narrative

Attacker objective: The attacker’s objective is to convert one exposed credential or misconfiguration into access to multiple cloud workloads, data stores, or accounts.

1. Entry begins with exposed secrets, stale roles, or public cloud assets that attackers can discover without needing initial malware or privilege escalation.
2. Escalation follows when overprivileged service accounts, broad IAM roles, or cross-account permissions allow a single credential to reach multiple systems.
3. Impact occurs when attack paths connect those permissions to sensitive data stores, production hosts, or infrastructure controls, turning one weakness into broad compromise.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud attack paths are now an identity governance problem, not just a cloud security problem. The report’s repeated findings on overprivileged service accounts, stale roles, and broad access chains show that the real risk is reachable privilege, not raw asset count. OWASP NHI and NIST CSF both frame this correctly: control what an identity can reach, not just whether the workload is patched. Practitioners should treat cloud blast radius as an IAM outcome.

Secret sprawl is now a lifecycle failure, not a hygiene issue. The fact that plaintext secrets persist in repositories and Git history means removal from active code does not equal removal from the environment. That aligns with the OWASP NHI view of secret exposure as an identity exposure problem, because a secret is a usable identity artefact. The practical conclusion is that governance must follow the secret after commit, not stop at developer education.

Attack-path reduction is the right organising concept for cloud identity security. Individual findings are easy to triage badly because each looks tolerable in isolation. The report shows that a single asset can create more than 1,000 attack paths, which means risk is being manufactured by combination, not just by severity. Identity blast radius: the reachable damage created when permissions, exposed secrets, and public assets intersect. Practitioners should prioritise the controls that collapse that blast radius first.

Pipeline shortcuts are governance decisions, not just engineering conveniences. Automatic pull request approvals and cross-account access without strong secondary checks move risk upstream into the delivery chain. That is why cloud security and IAM governance can no longer be separated from CI/CD policy. The right reading of this report is that software delivery now creates identity risk before production ever sees a workload, so security teams must govern the pipeline as part of the identity estate.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• Internal repositories are 6x more likely to contain secrets than public ones, with 32.2% versus 5.6%, which means private code is not a safe assumption.
• For the control pattern behind that risk, see Guide to the Secret Sprawl Challenge for the lifecycle and remediation angle.

What this signals

Secret sprawl now behaves like an identity inventory problem. If secrets can remain valid after exposure, then detection SLAs matter less than revocation discipline and repository prevention controls. Teams should expect auditors and threat hunters to ask not just where secrets were found, but how quickly they were rendered unusable.

The next maturity jump is to connect cloud findings to reachable impact, especially where service accounts, public assets, and deployment automation intersect. A programme that can surface attack paths will outprioritise generic vulnerability lists and focus effort where compromise can actually move.

The report also reinforces a broader governance shift: pipeline policy is part of the identity perimeter. When approval rules, cross-account trust, and workload permissions are managed separately, organisations create a control gap that attackers can compose faster than teams can patch it.

For practitioners

• Reduce service account blast radius Review every service account and remove permissions that are not required for the current workload. Reassign broad roles that are attached to many instances, then enforce ownership and expiration for any exception that remains.
• Eliminate secrets from repositories Block plaintext secrets from entering source control, then rotate any secret already found in Git history or the main branch. Use scanning plus revocation, because discovery without revocation still leaves active access behind.
• Prioritise attack-path remediation Rank cloud findings by reachable paths to sensitive data, not by severity alone. Fix the combination that creates the route first, especially when a public asset, broad role, and exposed secret appear together.
• Govern the delivery pipeline as identity infrastructure Treat CI/CD settings, repository approvals, and cross-account trust as identity controls. Remove automatic pull request approvals where they bypass human review, and require stronger conditions before a role can be assumed across accounts.

Key takeaways

• Cloud security risk in 2025 is driven by connected identity, secrets, and pipeline failures rather than isolated misconfigurations.
• The evidence is stark: overprivileged service accounts, plaintext secrets in repositories, and broad automation shortcuts create reachable attack paths at scale.
• Practitioners should collapse attack paths first, then tighten secrets lifecycle controls and pipeline governance to reduce blast radius.

Key terms

• Overprivileged Service Account: A service account that has been granted more permissions than its workload needs. In cloud environments, this creates unnecessary blast radius because compromise of one non-human identity can expose multiple systems, data stores, or accounts through inherited or broad entitlements.
• Attack Path: A sequence of connected weaknesses that lets an attacker move from an initial foothold to a valuable target. In cloud security, attack paths are more useful than isolated findings because they show what an adversary can actually reach, combine, and compromise.
• Secret Sprawl: The uncontrolled spread of credentials such as API keys, tokens, passwords, and certificates across code, history, chat tools, and deployment systems. Secret sprawl persists because one exposed secret can survive in many places and remain usable long after teams believe it has been removed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: 2025 State of Cloud Security Report. Read the original.