Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

DotNetFiddle secrets exposure: what IAM and AppSec teams need to know


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 13010
Topic starter  

TL;DR: A scan of 1,225,736 public DotNetFiddle snippets found 140 verified live secrets, plus a context-aware HMAC signing key that could authenticate as any user in Zendesk SSO, according to Truffle Security. The finding shows why format-based secret detection and post-publication cleanup both leave dangerous gaps in secrets governance.

NHIMG editorial — based on content published by TruffleHog: Scanning 1.2 Million DotNetFiddle Snippets for Secrets

By the numbers:

Questions worth separating out

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.

Q: Why do secrets scanners miss some high-risk credentials?

A: Scanners often miss secrets that have no fixed format or no provider verification endpoint.

Q: How can security teams tell whether secret management is actually working?

A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems.

Practitioner guidance

  • Implement save-time secret prevention for public code surfaces Block or warn when developers paste credentials, tokens, or signing keys into playgrounds, gists, and shared snippets before publication.
  • Add semantic detection for signing keys and token flows Extend scanning beyond format-based regex and provider verification so it inspects surrounding code for HMAC algorithms, signing calls, and token construction.
  • Accelerate rotation for any secret exposed in public code Create a response path that assumes exposure first and verification second, then rotates the secret immediately and checks for downstream use across Azure, Microsoft 365, SaaS, and internal services.

What's in the full report

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

  • The scanning method used to collect 1.2 million public DotNetFiddle snippets and separate retriable from deleted entries.
  • The context-aware detection logic that identified a live HMAC signing key beyond the verified-secret results.
  • The full inventory of credential types found, including Azure, Office 365, SharePoint, Mailgun, SendGrid, and SQL Server access.
  • The comparison between regex-only matching and TruffleHog verification across the same corpus.

👉 Read Truffle Security's scan of public DotNetFiddle snippets for live secrets →

DotNetFiddle secrets exposure: what IAM and AppSec teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 12594
 

Public snippet exposure is a secrets governance problem, not a developer hygiene issue. The article shows that credentials and signing keys can survive in public code long enough to be discovered by scanners, even when the original task was temporary. That shifts the control question from user behaviour alone to save-time prevention, lifecycle control, and detection across public-sharing surfaces. For identity programmes, the key conclusion is that exposed machine credentials behave like unmanaged NHI assets the moment they leave the intended boundary.

A few things that frame the scale:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
  • Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.

A question worth separating out:

Q: Who is accountable when leaked secrets remain active after discovery?

A: Accountability sits with the team that owns secret lifecycle governance, not just the team that found the leak. If tokens, API keys, or certificates remain valid after exposure, the organisation has failed at revocation and ownership. That failure belongs in PAM, IAM, and cloud operations governance, not only in incident response.

👉 Read our full editorial: Public .NET snippets leak live secrets faster than teams can fix them



   
ReplyQuote
Share: