TL;DR: Truffle Security reports that scanning 22 million public cloud development environment projects across CodeSandbox, StackBlitz, CodePen, and JSFiddle surfaced 8,792 verified unique secrets, including a GitHub employee token with write access to github/github. Public sandboxes behave like an ungoverned secrets surface because they lack native scanning, push protection, and automated revocation.
At a glance
What this is: Truffle Security found that public cloud development environments can hide large volumes of live secrets, with verified exposures spanning browser-based coding platforms and high-impact credentials.
Why it matters: IAM, secrets, and platform-security teams need to treat public sandboxes like exposed production-adjacent assets, because pasted credentials can outlive visibility controls and reach sensitive downstream systems.
👉 Read Truffle Security's analysis of credential exposure across public cloud development environments
Context
Cloud development environments are browser-based coding spaces that let developers prototype and share code without the controls usually found in managed source repositories. In public form, they create a credential exposure surface that sits outside normal secret scanning, push protection, and revocation workflows.
Truffle Security's analysis shows why that gap matters for identity governance. When credentials are copied into publicly accessible projects, the environment itself becomes part of the trust boundary, yet most teams still govern Git platforms more tightly than demo and sandbox tools.
The result is not just accidental leakage, but persistent exposure. If a platform has no native detection or partner revocation path, a secret can remain live until someone manually finds and removes it.
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 sandbox leaks create more risk than the file looks like they should?
A: Because the visible file is only the wrapper around the credential's real permission scope. A single leaked token may open repositories, cloud resources, or SaaS systems far beyond the sandbox itself. The risk comes from the entitlement behind the secret, not just from the project where it appeared.
Q: What do security teams get wrong about secure development environments?
A: They often treat local setup as a purely engineering concern, even though it shapes how people learn to handle trust, credentials, and access paths. If the secure workflow is slow or fragile, developers will work around it. A secure environment only helps when it is also the easiest practical option.
Q: How should organisations decide whether a leaked sandbox credential is urgent?
A: Prioritise credentials with write access, admin scope, or access to production-adjacent systems first. A leaked demo token is serious, but a token that can modify repositories, trigger workflows, or reach high-value SaaS resources demands immediate revocation and scope review.
Technical breakdown
Why public sandboxes become a credential persistence layer
Public cloud development environments often look disposable to developers, but from an identity perspective they behave like permanent content stores. Once an API key, OAuth token, SSH private key, or cloud credential is pasted into a public project, it can remain reachable through the platform's normal sharing and indexing paths. Unlike Git platforms, these environments may not enforce push protection, secret scanning, or coordinated revocation. That means exposure is not a one-time mistake. It becomes a durable access path until the secret is rotated or the project is removed from view.
Practical implication: treat public CDEs as persistent secret reservoirs and not as temporary scratch space.
Why volume changes the risk model for secret discovery
The research matters because scale changes incident handling. When millions of projects are enumerated, the problem is no longer a handful of bad pastes. It becomes a platform-wide governance issue where exposure density, platform capability, and developer behavior combine to create repeatable leakage patterns. More capable CDEs that support backend code, environment files, and third-party integrations tend to surface more sensitive credentials than front-end-only tools. That relationship tells security teams that platform capability influences the sensitivity of what ends up exposed, not just the number of mistakes made.
Practical implication: classify public development platforms by capability and apply stronger controls to those that can hold production-like secrets.
Why downstream access can exceed the apparent blast radius
A leaked credential in a public sandbox is dangerous because the visible file is only the starting point. The true risk is the authenticated scope behind the token or key. In this research, exposed secrets included credentials with repository write access, admin permissions, and access to downstream SaaS and cloud resources. That means the real exposure window extends from the public project into the systems the secret can reach. Identity governance has to care about both the container and the entitlement, because the visible leak and the reachable privilege are not the same thing.
Practical implication: verify the effective scope of every exposed secret, not just whether it was publicly posted.
Threat narrative
Attacker objective: The objective is to convert a public code snippet or sandbox into authenticated access to internal source code, infrastructure, or SaaS resources.
- Entry occurred when developers pasted live credentials into public cloud development environments that were accessible without the protections normally applied to source control.
- Credential access followed because the pasted secrets were stored in publicly retrievable project files and remained valid until manually removed or rotated.
- Impact came from the permissions behind those secrets, which in some cases included repository write access, admin access, or broader SaaS and cloud reach.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Red Hat Consulting GitLab breach 2025: Extortionists copied a Red Hat Consulting GitLab instance, exposing customer tokens, keys and database connection strings held in engagement reports.
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 cloud development environments are now a secrets governance domain, not a side channel: The article shows that browser-based sandboxes can hold live credentials at scale, which puts them inside the identity security perimeter. Teams that govern Git repositories but ignore CDEs are leaving a parallel code workspace outside policy, review, and revocation discipline. The practical conclusion is that public development platforms need the same governance attention as any other credential-bearing surface.
Secret scanning only works where it is deployed: The core gap here is not that credentials exist, but that the platform class has no native enforcement comparable to Git-based controls. When there is no scanning on publish, no push protection, and no partner revocation path, detection becomes manual and late. That means governance based on downstream cleanup will always underperform governance built into the point of exposure.
Credential blast radius is defined by token scope, not by where it was pasted: The article's strongest findings include write access to github/github, admin access to repositories, and access into production-adjacent systems. Those are not minor leaks. They are evidence that a single public paste can bridge straight into privileged systems when entitlement scope is broad. Practitioners should assume that sandbox exposure can become enterprise access unless the credential lifecycle is controlled.
Identity lifecycle for public sandboxes must be shorter than the sharing window: The exposure problem persists because public projects outlive the moment they were created, while secrets inside them remain valid until someone intervenes. That creates a mismatch between content lifecycle and credential lifecycle. Governance teams should treat visibility changes, project publication, and credential rotation as linked events rather than separate controls.
Ephemeral workspace trust debt: Public CDEs accumulate trust debt when developers assume prototype spaces are low-risk even though they can hold production-grade secrets. The article shows that the more capable the platform, the more dangerous that assumption becomes. The practitioner lesson is to stop treating demo and sandbox environments as outside identity governance simply because they are not primary code repos.
What this signals
Public development spaces need to be added to the identity asset inventory: If a platform can store live credentials, it belongs in the same governance model as other non-human identity-bearing systems. Security teams should map where developers create public code, where secrets can be pasted, and which projects are not covered by existing scanning or revocation controls.
The control gap is structural, not accidental: The research shows that the problem is not one repository or one developer. It is a platform class that lacks the enforcement hooks identity teams rely on elsewhere, which means manual review will always lag exposure.
Secret lifecycle has to be shorter than public visibility: If a credential can outlive the demo that exposed it, the control boundary has already failed. Teams should align visibility changes, secret rotation, and offboarding logic so public sharing cannot outrun revocation.
For practitioners
- Audit public CDE projects for live credentials Inventory CodeSandbox, StackBlitz, CodePen, and JSFiddle projects that are publicly reachable, then search for API keys, OAuth tokens, SSH keys, and other secrets before they are copied again.
- Rotate any secret exposed in a sandbox Revoke and replace credentials found in public projects, even when the project was posted for a short-lived demo, because exposure persists until the secret itself changes.
- Apply publication-time secret scanning Add automated checks at the moment a project becomes public so leaked values are detected before the environment is shared externally.
- Classify sandbox credentials by effective privilege Prioritise exposed secrets with repository write access, admin scope, or SaaS and cloud reach, because those are the exposures most likely to create real downstream impact.
- Treat public sandboxes as governed identity surfaces Align demo and prototype workflows with the same access-review and offboarding expectations used for other credential-bearing systems, so visibility changes and secret lifecycle are not disconnected.
Key takeaways
- Public cloud development environments can store live secrets in plain sight, so they should be governed as credential-bearing systems rather than informal scratch spaces.
- The article's examples show that exposed credentials can carry write access, admin privilege, and downstream SaaS reach, which makes scope more important than file location.
- The most effective response is to inventory public projects, rotate exposed secrets, and add secret detection before publication instead of after discovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Public CDE projects exposed live secrets in files visible to anyone with access. |
| NHI-07 — Long-Lived Secrets | The article shows secrets persisted until manual cleanup instead of expiring by policy. | |
| NHI-05 — Overprivileged NHI | Several exposed credentials carried write or admin scope far beyond the demo use case. | |
| Recommendation — Scan public development environments for leaked credentials and revoke exposed secrets immediately. Enforce short-lived credentials and rotate any secret that can persist in a public sandbox. Reduce token scope so public workspace credentials cannot modify repositories or production-adjacent systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and revocation are central to limiting sandbox exposure. |
| Recommendation — Apply authenticator management to rotate and revoke secrets found in public code environments. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Leaked secrets enabled initial credential access and potential movement into downstream systems. |
| Recommendation — Map exposed sandbox secrets to credential access and lateral movement paths in detection and response. | ||
| NIST Zero Trust (SP 800-207) | Least privilege and continuous verification — Least privilege and continuous verification | Public sandboxes need zero-trust assumptions because their contents are externally reachable. |
| Recommendation — Apply least privilege and continuous verification to any credential that can appear in a public workspace. | ||
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.
- Exposure Surface: The set of data, endpoints, and signals that can be observed or queried by an external party. For identity security, the exposure surface is broader than the access surface because publicly visible fields can still be abused for recon and profiling.
- Secret revocation: Secret revocation is the process of invalidating exposed credentials so they can no longer be used. In practice, it must include every system that trusts the secret, because a credential that remains valid after disclosure is still an active attack path.
- OAuth Scope: An OAuth scope is a permission string that defines what an application can do on behalf of a user. In practice, scopes set the blast radius of delegated access, because the token carries the right to read, write, or administer resources until it is revoked or expires.
What's in the full report
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- Enumeration methods used to discover millions of public CodeSandbox, CodePen, JSFiddle, and StackBlitz projects
- Technical scanning workflow with TruffleHog, deduplication, and triage across thousands of verified secrets
- Specific examples of high-impact exposures, including repository write access and SaaS administrative tokens
- Disclosure and revocation handling across multiple providers and platforms
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 programme, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org