In January 2023, attackers used a stolen session token to breach CircleCI's systems, forcing every customer to rotate every secret stored on the platform. Seven months later, a compromised Microsoft signing key let a China-based actor known as Storm-0558 forge authentication tokens and read email from 25 organizations, including U.S. government agencies. Neither breach started with a zero-day. Both started with identity: a token, a key, a session that should have been scoped tighter, expired sooner, or never existed at all. Cloud identity security is the discipline of getting authentication, authorization, and access controls right across every human and machine that touches your environment. Prisma Cloud, Palo Alto Networks' CNAPP, has built a substantial CIEM practice around this problem. But its lens is the runtime cloud account, not the pipeline that provisions it. This post examines what cloud identity security actually covers, where Prisma Cloud's model holds up, and where the software supply chain exposes a different set of identities entirely.
What is cloud identity security, and why is it suddenly urgent?
Cloud identity security is the set of controls governing who and what can authenticate into cloud resources and what they're authorized to do once inside. It spans three overlapping layers: authentication (proving you are who you claim), authorization (defining what you're allowed to do), and access controls (the policies, roles, and boundaries that enforce both). The urgency comes from a permissions gap that has quietly become the largest attack surface in cloud computing. Unit 42's 2023 Cloud Threat Report found that 99% of cloud users, roles, services, and resources granted excessive permissions they never used, and identity and access misconfigurations were involved in the majority of the incidents Palo Alto Networks' incident response team investigated that year. Verizon's 2024 Data Breach Investigations Report put the number even more starkly: credentials were a factor in 31% of all breaches over the past decade. Identity, not malware, is now the primary way attackers get in.
How does Prisma Cloud approach identity security, and where are the gaps?
Prisma Cloud approaches identity security primarily through Cloud Infrastructure Entitlement Management (CIEM), which maps IAM roles, policies, and effective permissions across AWS, Azure, and GCP to flag over-privileged identities and unused entitlements. That's genuinely useful for runtime hygiene: it catches the S3 bucket policy that grants s3:* to a role that only ever needs s3:GetObject, or the IAM user who hasn't rotated a key in 400 days. The gap is upstream of runtime. Prisma Cloud's identity graph is built from cloud provider APIs, which means it sees identities after they've been created and after a workload is deployed. It has comparatively little visibility into the identity created the moment a GitHub Actions workflow requests an OIDC token, or the service account a Terraform apply mints mid-pipeline, or the personal access token a developer pasted into a CI variable in 2021 and never revoked. Those are cloud identities too, and by the time Prisma Cloud's CSPM scan sees the resulting IAM role, the exposure already happened at build time.
Why do non-human identities matter more than human logins now?
Non-human identities now outnumber human ones by a wide margin, and most organizations can't inventory them, let alone govern them. A 2023 report from identity security vendor Astrix found that non-human identities, service accounts, API keys, OAuth tokens, and CI/CD credentials, outnumber human identities by roughly 45 to 1 in the average enterprise. Unlike a human employee, a service account doesn't go through offboarding when a project ends, doesn't get MFA by default, and frequently carries permissions scoped for convenience rather than least privilege. The 2021 Codecov breach is the canonical example: attackers modified a Docker image to exfiltrate CI environment variables, silently harvesting credentials and secrets from thousands of customer pipelines for two months before anyone noticed. No human ever logged in with stolen credentials in that breach. The compromised identity was a build script's access to environment variables, a category cloud-centric identity tools were never built to watch.
What happens when identity security fails in the software supply chain?
When identity security fails in the software supply chain, the blast radius extends to every downstream consumer of the software, not just the breached company. SolarWinds in 2020 remains the reference case: attackers compromised the build environment and used it to sign and distribute a trojanized update to roughly 18,000 organizations, including multiple U.S. federal agencies, by abusing the trust placed in SolarWinds' code-signing identity. The 2023 3CX attack followed a similar pattern, a compromised employee identity at an upstream vendor led to a trojanized desktop app that was then, in a rare double supply chain attack, traced back to a compromised X_Trader software package. In both cases, the failure wasn't a missing firewall rule; it was an identity, a signing key, a build credential, a developer's session, that had more trust and more reach than it should have. A CNAPP watching cloud IAM roles would not have seen either attack forming, because the compromised identity lived in the build system, not the cloud account.
How should teams evaluate authN/authZ and access controls across the SDLC?
Teams should evaluate identity controls at every stage where an identity is minted, not just where it's consumed, which means auditing source control, CI/CD, artifact registries, and runtime as one continuous identity surface. In practice, that means asking: Which of our 200+ CI/CD service accounts still use static, long-lived tokens instead of short-lived OIDC-based credentials? GitHub, GitLab, and CircleCI have all shipped OIDC federation specifically to eliminate stored cloud credentials in pipelines, yet adoption lags because migrating legacy jobs takes engineering time nobody's prioritized. It also means asking who can approve a merge to main, who can publish to your package registry, and whether those permissions are reviewed on the same cadence as production IAM roles, most organizations review the latter quarterly and the former never. CISA and NIST's SSDF (SP 800-218) guidance, published in 2022 and referenced heavily after the Executive Order 14028 supply chain mandates, explicitly calls out access control over build environments as a discrete control family, separate from cloud infrastructure access. Treating them as separate problems, one for the CNAPP and one for nobody, is exactly the gap attackers have been exploiting since SolarWinds.
How Safeguard Helps
Safeguard was built to close the identity gap that sits between the codebase and the cloud, the exact territory that traditional CNAPP identity tools weren't designed to see. Where CIEM tools like Prisma Cloud reason about IAM roles and cloud entitlements after deployment, Safeguard maps and monitors the identities created earlier in the lifecycle: CI/CD service accounts, OIDC token exchanges, package registry publish tokens, signing keys, and the personal access tokens developers create for one-off scripts and forget about. Safeguard continuously inventories these non-human identities across your pipelines, flags long-lived credentials that should have been rotated or replaced with short-lived OIDC federation, and surfaces excess permissions on build-time identities the same way CIEM tools do for runtime cloud roles, before an over-scoped token becomes the next Codecov.
Safeguard also correlates supply chain identity risk with the artifacts those identities touch. If a CI service account with write access to your package registry also has a stale, unrotated key or was involved in an anomalous authentication event, Safeguard connects that signal to the packages it published, so a security team isn't left reconstructing the blast radius manually during an incident, the way SolarWinds' downstream customers had to. For organizations already running Prisma Cloud or another CNAPP for cloud posture and runtime identity, Safeguard is built to complement rather than duplicate that coverage, extending identity visibility upstream into source control and CI/CD so authN, authZ, and access control decisions are governed consistently from the first commit to the running workload, not just from the cloud account outward. Cloud identity security that stops at the cloud provider's API is only covering half the identity surface attackers actually use.