Topic starter
01/08/2026 8:55 pm
TL;DR: Truffle Security found 140 verified secrets in 1,225,736 public DotNetFiddle snippets plus a context-only Zendesk SSO HMAC key that format-based scanning missed, showing how public code shares can outlive remediation and defeat verification-only secret scanning. Static secret detection and post-publication cleanup both leave dangerous gaps in secrets governance.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Scanning 1.2 Million DotNetFiddle Snippets for Secrets”.
Key questions
Q: What breaks when live secrets are saved in public code snippets?
A: The main failure is that publication becomes disclosure.
Q: Why do public code snippets turn secrets into authentication risk?
A: Because many secrets are not just data, they are credentials.
Q: How can security teams detect context-only secrets more reliably?
A: Use detectors that understand code context, not only token format.
Practitioner guidance
- Implement save-time secret blocking Prevent live credentials from being committed into public snippets by scanning on save, not only after publication, and reject content that contains tokens, keys, or connection strings.
- Add context-aware secret detection Extend scanning to evaluate nearby signing calls, algorithm references, and token-construction patterns so HMAC keys and other non-prefixed secrets are detected.
- Treat public playgrounds as risky publishing surfaces Set policy that production credentials must never be used in public code-sharing tools, even for short-lived testing or demonstration code.
Bottom line: Public DotNetFiddle snippets can turn working credentials into durable disclosures, and the risk does not disappear when the snippet is deleted later.
What's in the full report
Truffle Security's full analysis covers the operational detail this post intentionally leaves for the source:
- The step-by-step DotNetFiddle scanning approach used to collect and triage more than 1.2 million public snippets
- The manual review method that separated obvious tokens from context-only signing keys and other non-standard secrets
- The breakdown of secret types by platform, including Azure, SQL Server, Office 365, SharePoint, and other enterprise services
- The examples of raw regex hits that were retained, rejected, or reclassified during analysis
👉 Read Truffle Security’s analysis of public .NET snippets and live secret exposure →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:03 pm
Public code sharing has become a secrets governance control surface. The article shows that snippet repositories are not neutral collaboration spaces once live credentials are pasted into them. They behave like public distribution channels for identity material, which means the control objective is prevention at save time, not just retrospective discovery. For IAM and AppSec teams, this shifts code-sharing governance into the same risk category as source control leakage and exposed CI artifacts.
A few things that frame the scale:
- A May 2025 Gartner poll of 147 CIOs and IT leaders found that 24% had already deployed AI agents, 50% were experimenting and 17% planned to deploy by the end of 2026.
A question worth separating out:
Q: Should organisations allow production credentials in public developer playgrounds?
A: No. Public playgrounds should be treated as uncontrolled publishing surfaces, not test benches for live credentials. If developers need working authentication material, they should use isolated non-production secrets and protected environments. Once production secrets reach a public snippet, the organisation should assume exposure and rotate them immediately.
👉 Read our full editorial: Public .NET snippets leak live secrets faster than teams can fix them