What breaks when GitHub Apps and OAuth Apps are over-permissioned?

Why This Matters for Security Teams

Over-permissioned GitHub Apps and OAuth Apps are not just an access-review problem. They turn a single integration into a standing trust relationship that can read, write, and sometimes act across repositories, issue trackers, CI/CD workflows, and downstream services. That matters because app permissions are often granted for one narrow business use, then left in place long after the original purpose changes. The result is hidden privilege accumulation, weaker revocation discipline, and a much larger blast radius if a token, installation, or connected workflow is abused. Current guidance from the OWASP Non-Human Identity Top 10 treats this as a core NHI governance issue, not an edge case.

NHIMG research shows how quickly that trust can be exploited in practice. The Salesloft OAuth token breach is a reminder that oauth token can become a path into business data far beyond the original app boundary, while the Reviewdog GitHub Action supply chain attack shows how a trusted automation path can expose secrets at scale. In practice, many security teams only discover the overreach after an incident forces them to trace what the app could actually touch.

How It Works in Practice

The mechanics are straightforward, but the failure mode is subtle. A GitHub App may need repository metadata, pull request comments, or release actions. An OAuth App may only need to read user profile data or a specific SaaS connector. Over-permissioning happens when the app is granted broad repository admin rights, organization-wide scopes, or long-lived tokens that outlast the task. Once that happens, the app becomes a reusable credential bridge rather than a purpose-bound integration.

Operationally, teams should treat app permissions as part of NHI inventory, not just developer tooling. That means mapping what each app can access, what it actually uses, who approved it, and when that approval should expire. It also means checking for indirect reach: repository write access can become CI/CD execution, secret retrieval, or lateral movement into deployment systems. The Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference for the broader governance pattern, and the Dropbox Sign breach illustrates how app-connected identity paths can extend into sensitive workflow data when privilege is too broad.

• Prefer the narrowest GitHub App permissions that still satisfy the business workflow.
• Use separate apps for separate purposes instead of one shared integration with broad scope.
• Review installation scopes, token lifetimes, and webhook targets together, not in isolation.
• Revoke unused apps aggressively and require re-approval after material scope changes.

Where this guidance breaks down most often is in large GitHub Enterprise environments with many repository administrators and automated marketplace app installs, because permission sprawl becomes decentralized before anyone can review it consistently.

Common Variations and Edge Cases

Tighter app permissions often increase operational overhead, so organisations have to balance developer velocity against auditability and containment. That tradeoff becomes sharper when teams rely on third-party apps for release automation, dependency updates, or security scanning, because the app may need enough access to perform a task but not enough to become a universal backdoor.

Best practice is evolving toward intent-based approval and zero standing privilege for non-human access, but there is no universal standard for this yet. Some teams implement periodic recertification, others enforce short-lived installation tokens, and others segment apps by repository class or environment. The right model depends on whether the app is read-only, write-capable, or able to trigger downstream automation. The GitLocker GitHub extortion campaign is a good example of why overbroad GitHub access becomes a business risk, not just an IAM concern, and the CI/CD pipeline exploitation case study shows how privilege in one layer can cascade into another.

For governance, align the review process with OWASP Non-Human Identity Top 10, then map that to NIST risk ownership and change control. The practical goal is not to eliminate GitHub Apps or OAuth Apps, but to ensure each one has a clear purpose, a bounded blast radius, and a revocation path that actually gets used.

Related resources from NHI Mgmt Group

• What breaks when AI governance depends on email or OAuth discovery alone?
• What breaks when audit evidence is spread across multiple systems?
• What breaks when access reviews are used as the main risk control?
• What breaks when banking GRC does not include identity governance?