Option to opt out of secret scanning for a private Gist?

[cyqsimon]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Secret scanning

Discussion Details

I would like to note down some access tokens in a private Gist. But doing that causes said tokens to be automatically revoked.

I would like an opt-in option that allows me to disable secret scanning on a Gist, much like how it's possible to exclude files from security scanning in a repository.

[P-r-e-m-i-u-m]

I would strongly avoid using a Gist as a token notebook, even if the Gist is “secret”.

The important detail is that secret gists are unlisted, not truly private. GitHub's secret scanning docs explicitly note that secret gists can be accessed by anyone with the URL, and GitHub has also announced that secrets found in unlisted gists are reported to secret scanning partners.

So the auto-revocation is doing what it is meant to do: treating the token as exposed.

Safer alternatives:

• Use a password manager for human-held tokens.
• Use GitHub Actions secrets / organization secrets for CI tokens.
• Use a cloud secret manager if the token is used by infrastructure.
• If you only need notes, store the service name, scope, expiration, and rotation instructions, but not the raw token value.

If GitHub ever offered an opt-out here, it would be dangerous because many users treat “secret gist” as private storage when it is really URL-obscured sharing. For token storage, I would consider the current behavior the safer default.

Docs:

• Secret scanning overview: https://docs.github.com/code-security/concepts/secret-security/about-secret-scanning
• Supported secret scanning patterns, including note about secret gists: https://docs.github.com/code-security/secret-scanning/introduction/supported-secret-scanning-patterns
• Changelog: secrets in unlisted gists reported to partners: https://github.blog/changelog/2025-11-25-secrets-in-unlisted-github-gists-are-now-reported-to-secret-scanning-partners/

[cyqsimon]

The important detail is that secret gists are unlisted, not truly private.

Right. Sorry I didn't know this detail. Yeah given this important context I'm inclined to agree with you.

My actual situation is that a program I use uses a private Gist to sync its settings, which in turn contains some access tokens. Its configuration tool requires an access token to enable this feature, which led me to believe that a private Gist requires authentication. What's actually happening is that an access token is required to write, but unauthenticated viewing is allowed. Given this fact my current opinion is that this specific feature in the program is poorly designed.