The commit passed, but something was off. A single over-scoped OAuth token had slipped into the pipeline, granting far more power than it ever should. That’s how breaches start.
OAuth scopes management in GitHub CI/CD controls is not optional. Every token, every app permission, every scope in your automation chain can become an attack surface. The more granular the scope, the less damage an attacker can do if compromised. The problem is that many GitHub Actions and integrations still request repo or admin:org level access when they only need read:packages or write:repo_hook.
Start with a full inventory of tokens, apps, and GitHub Actions in your repository and organization. Map the OAuth scopes each component uses. Restrict them to the minimum set needed. Use fine-grained personal access tokens or GitHub App permissions instead of classic access tokens wherever possible. In CI/CD pipelines, only inject tokens during the precise job steps that require them, and never leave them available across the entire workflow run.
Audit GitHub’s “Third-party application access policy” settings at the org level. If an action or tool requests broader scopes than you allow, block it unless it’s proven essential. In GitHub Actions, combine permissions at the workflow and job level to override defaults and cut down accidental overexposure. Rotate credentials frequently and revoke unused tokens the moment they’re no longer required.