Repository access controls determine which users or teams can read, write, or administer code. Third-party app access governs which external applications can connect to the organization and act on its behalf. Both matter, but they address different trust boundaries. One limits human and team permissions, while the other limits the blast radius of integrated tools and services.
How repository permissions differ from app permissions in GitHub
Repository access controls govern what a user, team, or automation can do inside a specific repo. Third-party app access governs what an external integration can do after you grant it access to the organization or repositories. The difference is not just who clicks “allow”, it is which trust boundary you are extending: direct repository authority versus delegated application authority.
That distinction matters because the control point, audit trail, and revocation path are different. A repo permission change affects an account or team relationship; an app grant affects a separate software principal that may touch multiple repositories, metadata, or workflows depending on the scope it was issued.
What each control actually limits
Repository access controls are the familiar read, write, maintain, or admin decisions that determine whether a principal can view code, merge changes, manage settings, or administer the repository. In practice, they are the first line of blast-radius reduction for code access, branch protection, and day-to-day collaboration. They are also the control most teams review when a person joins, moves, or leaves a project.
Third-party app access is broader in shape and narrower in purpose. A GitHub App, OAuth app, or other external integration is not a teammate, but it can still act on behalf of the organization within the scopes it received. That can include reading repositories, posting statuses, opening pull requests, or reaching connected services. The real question is not whether the app is “trusted” in general, but whether the granted scope matches the minimum task it must perform.
GitHub security problems often arise when teams confuse these layers. A repo permission review may look clean while an over-scoped integration still has a path to the same code or related systems. For that reason, mature access governance treats repository grants and app grants as separate inventories, separate approvals, and separate review cycles.
Why the trust boundary changes the risk
Repository permissions constrain people and teams, so the main risk is excessive human or team authority inside the codebase. Third-party app permissions constrain delegated software access, so the main risk is that a compromised or overprivileged integration can bypass normal user expectations and operate at machine speed across many repositories or linked services.
That difference is material when you evaluate blast radius. A human account usually produces a smaller and more traceable change pattern. A third-party app can automate bulk reads, writes, or status changes and may persist until its token, installation, or connected authorization is removed. If the app is compromised, the attack path often looks like trusted automation rather than obvious account misuse, which makes review and detection harder.
IAM and IGA Basics is useful background here because the same access-governance principles apply to both people and software principals. GitHub repositories are the asset, but the governance question is still who or what should have which entitlement, for how long, and under what review process.
Third-Party, B2B and Contractor Access Guide also maps well to this distinction because app access behaves like delegated third-party authority, not ordinary internal role assignment. If you would require sponsorship, expiry, and periodic review for a contractor, the same discipline belongs on external integrations.
How to manage both without mixing them up
Start by separating inventories. One list should cover repository membership, team grants, and admin rights. A second list should cover installed apps, OAuth grants, webhooks, tokens, and any external automation that can reach GitHub or connected systems. If those inventories are merged, review quality usually drops because teams cannot tell whether they are approving a person, a team, or a software integration.
Then apply different approval logic. Repository access should be driven by role, project need, and least privilege. Third-party app access should be driven by scope, data exposure, token lifetime, publisher trust, and the ability to disable the integration quickly if something looks wrong. If the app needs broad repository visibility to function, that should trigger stronger justification and tighter monitoring, not informal acceptance.
Authorisation Models Guide is relevant because the same permission question can be modelled differently for people and integrations. RBAC may work for repo membership, while app permissions often need a more explicit scope-based or policy-based view to avoid granting more than the integration actually requires.
GitHub OAuth token breach 2022 shows why third-party app access deserves separate scrutiny: a stolen OAuth token can be enough to reach private repositories even when ordinary user access looks controlled. That is a delegation problem, not a repository-permission problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Repository and app access both need minimal permissions to limit blast radius. |
| IA-5 — Authenticator Management | GitHub app and token lifecycle depends on credential issuance, rotation, and revocation. | |
| Recommendation — Apply AC-6 to scope repo and app access to the minimum required permissions. Manage tokens and app credentials with IA-5 rotation, expiry, and revocation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is fundamentally about separating and governing two access boundaries. |
| Recommendation — Define separate access-control rules for repository rights and third-party app grants. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This is an access-management distinction between user permissions and app permissions. |
| Recommendation — Inventory and review repository and app access separately under CIS-6. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Third-party app access relies on delegated auth paths and tokens that can be abused if weakly controlled. |
| Recommendation — Harden delegated app authentication and revoke compromised tokens quickly. | ||
Practitioner Guidance
What to verify: Confirm whether each access path is a direct repository grant or a delegated app grant. If the answer is “app”, verify the scopes, token lifetime, install owner, and revocation process before approving it.
Decision rule: If the access is needed for collaboration, keep it in repository permissions. If the access is needed for automation, isolate it as an app grant and review it like a third-party dependency, not like a user role.
Common mistake: Teams often tighten repository membership while leaving broad app scopes untouched. That creates a false sense of control because the more powerful path is often the integration, not the human account.
Practitioner takeaway: Treat repository permissions as direct code access and third-party app access as delegated operational authority, then govern them with different reviews, different evidence, and different revocation expectations.
Related resources from NHI Mgmt Group
- What is the difference between repository security controls and third-party integration risk in developer platforms?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between third-party risk management and access control in supply chain security?
- What is the difference between repository-level GitHub security controls and organisation-wide governance for code security?