Public cloud development environments hide credential exposure at scale

At a glance

What this is: Public cloud development environments are exposing live credentials at scale, and the research shows that the most capable environments tend to leak the most sensitive secrets.

Why it matters: IAM, NHI, and PAM teams need to treat public development sandboxes as a governed credential surface because exposed secrets can outlive visibility, review, and ownership.

By the numbers:

• I scanned 22 million public Cloud Development Environment projects across CodeSandbox, StackBlitz, CodePen, and JSFiddle with TruffleHog, found 8,792 verified, unique secrets, and made over $20,000 in bounties along the way.
• 1, odeSandbox stands out with one verified secret for every 1,299 sandboxes.
• 2025 seeing more than double the verified secrets compared to 2024.

👉 Read TruffleHog's analysis of thousands of live secrets in public cloud development environments

Context

Cloud development environments create a different identity problem from source control because public projects can persist live secrets without the guardrails that Git platforms now increasingly provide. In this environment, the key governance failure is not just exposure, but the absence of automated discovery, revocation, and ownership control for credentials pasted into browser-based workspaces.

For IAM and NHI programmes, that means public sandboxes need to be treated as an externalised secrets surface, not as throwaway developer tooling. Once a credential lands in a public project, manual deletion is often the only control left, and that is too slow for a high-volume, high-sprawl environment.

Key questions

Q: What breaks when secrets are pasted into public cloud development environments?

A: What breaks is the assumption that public sandboxes are harmless sharing spaces. A live credential can remain active long after the project is forgotten, and there is often no native scanning, push protection, or automatic revocation to catch it. The result is a standing access path that can be reused until someone finds and invalidates the secret.

Q: Why do public development environments create more NHI risk than many teams expect?

A: They create more NHI risk because the credential often matters more than the code around it. Public sandboxes can hold API keys, tokens, certificates, and service credentials that retain production-grade access even in a throwaway demo. If teams do not govern those secrets as NHI, they miss the identity lifecycle attached to the exposed credential.

Q: How do security teams know if exposed secrets are actually dangerous?

A: They should evaluate whether the secret is still valid, what scopes it carries, and which systems it can reach. A verified token with repository write access or cloud permissions is materially different from a stale string that no longer authenticates. Risk rises quickly when the credential can modify code, trigger workflows, or access organisation resources.

Q: Who is accountable when a public sandbox leaks a live credential?

A: Accountability should sit with the system that issued the credential, the team that owns the shared workspace, and the security function that defines revocation and detection requirements. The sandbox is only the exposure point. The governance failure is usually upstream, in weak lifecycle controls and unclear ownership of the credential itself.

Technical breakdown

Why public development environments create a secrets governance gap

Cloud development environments are browser-based coding workspaces that often blur the line between prototype and production-like development. Unlike managed Git platforms, many of these services do not provide native secret scanning, push protection, or automated partner revocation. That matters because a secret pasted into a public sandbox can remain live even after the developer forgets it exists. The control failure is lifecycle, not merely detection: the secret has no durable owner, no enforced review point, and no automatic expiration tied to visibility.

Practical implication: classify public CDEs as a credential exposure domain and inventory them alongside code repositories and CI pipelines.

Why verification matters more than raw secret counts

Credential scanning at scale produces noisy outputs unless the findings are verified against the target service. A verified secret is materially different from a pattern match because it confirms that the credential still authenticates or carries active permission. In this research, the difference between detected and verified secrets is what turns discovery into operational risk. For IAM and NHI governance, verified exposure should drive incident handling, rotation priority, and ownership review, while unverified matches remain a lower-confidence hygiene signal.

Practical implication: prioritise verified secrets first, then route them by credential type, scope, and business impact.

Why high-capability sandboxes amplify privilege risk

The more a development environment supports backend logic, environment files, and third-party integrations, the more likely it is to hold high-impact credentials. That creates an identity asymmetry: simple front-end tools tend to leak lower-scope public API keys, while richer sandboxes can expose cloud credentials, service tokens, and repository write access. The article’s GitHub employee token example shows why scope matters more than volume alone. A single credential with repo, workflow, and organisation access can create a blast radius far beyond the sandbox where it was pasted.

Practical implication: rank public environment findings by credential scope, not by where they were found.

Threat narrative

Attacker objective: The attacker aims to reuse exposed developer credentials to gain trusted access, modify code or workflows, and pivot into broader SaaS and supply chain compromise.

1. Entry occurs when a developer pastes a live credential into a public cloud development environment and publishes the workspace.
2. Escalation follows when the exposed secret is discovered and reused with the privileges already embedded in the token or key.
3. Impact occurs when the credential enables repository modification, workflow tampering, or access to downstream SaaS and cloud resources.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

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

NHI Mgmt Group analysis

Public development environments are now a credential governance problem, not just a developer convenience problem. The research shows that browser-based sandboxes can contain live secrets without the guardrails that Git platforms have begun to normalise. That shifts the control question from where code lives to where credentials can be introduced, persisted, and missed. Practitioners should treat public CDEs as part of the identity attack surface, not as an adjacent engineering tool.

Secret scanning without revocation is only partial governance. The article makes clear that many public environments lack native scanning and partner revocation, which means exposed credentials can remain active even after discovery. That is not a detection gap alone. It is a lifecycle gap where ownership, review, and invalidation are disconnected from the place the secret was published. Practitioners should align exposure response with revocation authority, not just alerting.

Credential value is determined by scope, not by platform size or leak count. A single GitHub employee token with workflow and repository access creates a materially larger identity blast radius than thousands of low-scope public API keys. This is why secrets governance must rank findings by privilege, reachable resources, and downstream trust relationships. The implication is straightforward: blast-radius analysis belongs inside every secrets triage workflow.

Public sandboxes expose the limits of manual remediation at scale. The research reports more than 22 million projects scanned and 8,792 verified secrets found, which is well beyond what ad hoc cleanup can absorb. That volume makes the case for policy-based prevention on publish, automated ownership resolution, and cross-platform revocation workflows. Practitioners should stop assuming manual cleanup can keep pace with developer sharing behaviour.

Ephemeral developer intent does not make the secret ephemeral. A temporary demo or prototype can still leave behind a permanent credential with standing privilege. That is the core governance mismatch this research surfaces: the development use case is short-lived, but the identity artifact is not. Practitioners should redesign policy around credential lifetime, not project intent.

From our research:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• For a broader view of NHI exposure, see the 2024 Non-Human Identity Security Report, which shows 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM.

What this signals

Public code-sharing environments are becoming a weakly governed extension of the identity perimeter, not a separate developer niche. That matters because security teams that only track repositories and CI/CD will miss live credential exposure in browser-based workspaces. The practical shift is toward central secrets policy, visibility into all sharing surfaces, and a revocation path that does not depend on the developer remembering to clean up.

Secret sprawl is now inseparable from identity governance maturity. The 2024 State of Secrets Management Survey found that only 44% of organisations are currently using a dedicated secrets management system, which means many teams are still relying on partial or informal controls. For practitioners, the next step is not just scanning more places. It is closing the gap between discovery, ownership, and invalidation across the full credential lifecycle.

For practitioners

• Audit public cloud development environments for live credentials Inventory CodeSandbox, StackBlitz, CodePen, JSFiddle, and similar browser-based environments, then search for verified secrets, environment files, and embedded tokens that have been published publicly.
• Prioritise revocation over clean-up after exposure For each confirmed secret, identify the issuing system, revoke or rotate the credential immediately, and verify whether the token had workflow, repository, or cloud-resource scope.
• Classify findings by effective blast radius Triage exposed secrets by the resources they can reach, not by the platform where they were found, and route high-scope credentials to incident handling rather than routine hygiene.
• Add publish-time guardrails for public sandboxes Where platform controls exist, require secret scanning on publish, block obvious credential patterns, and make environment-variable storage the default for shared demos.

Key takeaways

• Public cloud development environments can expose live credentials without the controls that most Git platforms now provide.
• The research found 8,792 verified secrets across 22 million projects, showing that this is a scale problem rather than an isolated hygiene issue.
• Teams need publish-time prevention, verified-secret triage, and fast revocation paths before public sandbox exposure becomes routine breach material.

Key terms

• Cloud Development Environment: A cloud development environment is a browser-based workspace for writing, running, and sharing code. In security terms, it can become an identity exposure surface when live credentials, environment files, or integration tokens are pasted into public projects and persist beyond the developer’s original intent.
• Verified Secret: A verified secret is a credential that has been checked against the target service and confirmed to be valid or active. This is more actionable than a pattern match because it indicates a real access path, not just a string that resembles a token.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across tools, projects, developers, and environments. It becomes an identity governance problem when no single team can confidently say where secrets exist, who owns them, or how quickly they can be revoked.
• Credential Blast Radius: Credential blast radius is the amount of access a leaked secret can unlock if it is abused. It depends on scopes, downstream trust relationships, and the number of systems the credential can reach, not just on where the secret was originally discovered.

What's in the full report

TruffleHog's full article covers the operational detail this post intentionally leaves for the source:

• The enumeration methods used to discover millions of public projects across four cloud development environments.
• The per-platform detection approach that produced verified secrets instead of pattern matches alone.
• The GitHub employee token case, including the scope values and the downstream access it enabled.
• The disclosure and bounty workflow used to coordinate revocation across multiple SaaS providers and platform owners.

👉 TruffleHog's full post covers the enumeration methods, verified secret findings, and disclosure workflow.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.