Repository Secret Scanning Is a Backstop, Not a Vault

A secret scanner can catch a provider key before or after it reaches a repository. It cannot make a committed credential safe, prove that every secret format is detectable, or replace the system that issues and revokes credentials.

GitHub describes push protection as a way to block supported secrets before they are pushed. Its guidance on credentials in GitHub Actions recommends minimum permissions and, for automation, considering a GitHub App with fine-grained permissions and short-lived tokens instead of a personal token. Together these controls illustrate a useful sequence: prevent exposure, reduce credential authority, and retain a response path for anything that gets through.

Prevent secrets from entering the workflow

Start before the commit hook. Give developers and CI a documented way to obtain credentials without copying them into source files:

• load local secrets from an ignored environment file or approved secret manager;
• use environment-specific credentials rather than a shared production key;
• inject CI secrets only into jobs that need them;
• keep untrusted pull-request code away from privileged secret contexts; and
• use short-lived workload identity where the provider supports it.

Add representative dummy values to example files so documentation does not encourage people to paste a real key. Test fixtures should use obviously fake tokens that cannot be confused with live credentials.

Configure scanning as a gate

Enable repository push protection where available, then decide who may bypass it and how exceptions are reviewed. A frictionless “bypass and continue” path turns a preventive control into an alerting tool.

Coverage matters. Provider-recognized patterns are useful, but internal token formats and connection strings may require custom patterns. Generic detection can generate false positives, so route findings to an owner with enough context to decide quickly. Do not close an alert merely because the secret was removed in a later commit; repository history, forks, caches, and build artifacts may still contain it.

Revoke first, investigate second

When a live credential reaches source control:

1. Disable or revoke it at the issuing system.
2. Identify its permissions, workload, and exposure window.
3. Review usage for unauthorized activity.
4. Issue a replacement through the normal secure path.
5. Remove the value from current code and, when justified, clean historical copies and derived artifacts.
6. Find the process gap that allowed the disclosure.

Rewriting Git history does not revoke a credential. Rotation also needs care: if both the old and new keys remain valid, the exposed key still works.

Prefer bounded workload credentials

The strongest secret is one that has little value outside its intended context. Give each automation a separate identity, minimum permissions, an expiry, and usage constraints when the enforcement point can apply them reliably.

Till provides a hosted beta control layer for AI-provider connections. Its scoped tokens can reduce the number of upstream keys distributed to repositories and add activation or optional usage constraints per workload. Till does not scan GitHub, protect every CI secret, revoke credentials at unrelated services, or establish compliance. A leaked Till token is still a bearer secret and should be revoked promptly.

Secret scanning works best as a guardrail in a broader credential lifecycle. The real objective is not a clean security dashboard; it is ensuring that an accidental commit cannot become durable, high-authority access.

← Back to blog