How to audit GitHub Apps and OAuth apps in an organisation: Inventory, review and remove third-party access

Every GitHub App installed on an organisation and every approved OAuth app is a standing non-human identity with access to your source code, and most organisations have never reviewed the full list. These integrations survive the people who installed them, often hold write or administration permissions on all repositories, and act with tokens that nobody inside your organisation can see. This runbook shows organisation owners how to inventory GitHub Apps through the UI and the REST API, review OAuth app approvals, read the audit log events that matter, and suspend, narrow or remove access safely. It covers GitHub.com organisations, with notes where a feature needs GitHub Enterprise Cloud. For the wider governance picture across SaaS platforms, see the SaaS and OAuth App Governance Guide.

Key takeaways

• GitHub Apps and OAuth apps are audited in different places. Installed GitHub Apps sit under Settings > Third-party Access > GitHub Apps; OAuth app approvals sit under OAuth app policy.
• The API gives you the full permission picture. GET /orgs/{org}/installations returns each installation's permissions, repository_selection, events and suspended_at; it needs an organisation owner.
• Suspend first, uninstall second. Suspension blocks access and can be reversed with Unsuspend; uninstalling removes the installation for this organisation only.
• Keep OAuth app access restrictions on. They are on by default for new organisations and stop members authorising OAuth apps against organisation resources without owner approval.
• The audit log is your evidence. Events such as integration_installation.create, integration_installation.version_updated and org.oauth_app_access_approved show who added access and when, for the last 180 days.

When you need this

• Periodic access review: a quarterly or annual review of third-party access to source code, often needed for SOC 2 or ISO/IEC 27001 evidence.
• After an integrator breach: in the GitHub OAuth Token Breach 2022, stolen OAuth user tokens for the Heroku Dashboard and Travis CI apps were used to list organisations and clone private repositories. GitHub advised victims to remove unneeded OAuth apps and check audit logs, tokens, OAuth apps and SSH keys.
• Abandoned apps with live keys: the Leaked GitHub App Private Keys 2026 research found 474 leaked GitHub App private keys that still authenticated, some with repository write or organisation administration permissions. Every installation of such an App is exposed until the key is revoked or the App is removed.
• Organisation clean-up: mergers, reorganisations or a move to a new enterprise account.

Before you start

You need to be an organisation owner. For API work, use a token with organisation Administration read permission (a fine-grained personal access token or GitHub App token), keep it short-lived, and revoke it after the review. Export the current state before you change anything; the audit log covers only the last 180 days, and REST or GraphQL access to it is available only to organisations on GitHub Enterprise Cloud.

Step-by-step

Steps 1 to 4 are read-only. Steps 5 and 6 change access; suspension is reversible, uninstall and deny are not reversible without the app owner or member re-requesting.

1. Export installed GitHub Apps. In the UI, open Your organizations > organisation Settings > Third-party Access > GitHub Apps. For a complete record, call the REST endpoint (maximum 100 results per page):

   gh api --paginate "/orgs/<org>/installations?per_page=100" \
     --jq '.installations[] | [.app_slug, .repository_selection, .created_at, .updated_at, .suspended_at, (.permissions|tostring)] | @tsv'

   Record app_slug, repository_selection (all or selected), permissions and events.
2. Export approved OAuth apps. Open Settings > Third-party Access > OAuth app policy. The "Third-party application access policy" page lists approved and denied applications. Confirm that restrictions are enabled; if they were turned off, any member can authorise an OAuth app against organisation resources.
3. Pull the history from the audit log. Open Settings > Archive > Logs > Audit log and filter with qualifiers, then use Export for JSON or CSV:

   action:integration_installation
   action:org.oauth_app_access_approved
   action:org_credential_authorization
   created:>=2026-05-01

   The table below lists the events to collect.
4. Score each integration. Rank by risk: write or admin permissions (for example contents write, workflows, administration), access to all repositories, no named internal owner, no recent use the team can confirm, and publisher no longer maintaining the app. An App installed on all repositories with administration permission and no owner goes to the top of the list.
5. Narrow or suspend. For GitHub Apps, open the app, click Configure, and under Repository access choose Only select repositories and Save, or click Suspend to block access while you confirm with owners. Suspension keeps the installation and can be reversed with Unsuspend, unless the app's owner suspended it.
6. Remove what is not needed. For GitHub Apps, click Uninstall. For OAuth apps, on the OAuth app policy page click the pencil icon next to the app and choose Deny access. Ask members who authorised removed apps to revoke them under Settings > Applications > Authorized OAuth Apps, because uninstalling from the organisation does not remove authorisations the app holds in other accounts.

Audit log events to collect

Verify it worked

• Inventory matches intent: re-run the installations call; removed Apps are absent and suspended ones show a suspended_at value.
• Audit trail: the audit log shows integration_installation.suspend, integration_installation.destroy or integration_installation.repositories_removed for each change, and org.oauth_app_access_denied for OAuth removals.
• Owners confirm no breakage: CI, deployment and code review flows that depended on approved apps still run.
• Restrictions on: the OAuth app policy page shows restrictions enabled.

Rollback and common errors

Hardening afterwards

• Limit who can request and install: use the organisation settings for limiting OAuth app and GitHub App access requests and installations, and add GitHub App managers deliberately, since they can manage Apps for the organisation.
• Prefer GitHub Apps over OAuth apps and PATs: GitHub Apps use fine-grained permissions and per-repository selection; OAuth apps act with a member's full authorised scope.
• Own your own apps: for organisation-owned Apps, rotate private keys and client secrets, keep at least one named owner, and delete Apps that are no longer used. See the GitHub and GitHub Actions Security Guide.
• Alert on new access: forward integration_installation.* and org.oauth_app_access_approved to your SIEM and require a ticket reference for each. The GitHub Audit Log Detection Guide covers detection rules built on these events, including alerts when an App gains permissions or repositories outside a change window.
• Prepare for a token leak: keep the OAuth Token Theft Incident Playbook ready, since an integrator breach is outside your control.

Metrics

Small organisation or enterprise

A small organisation with a handful of integrations can do this review in the UI in an hour each quarter. An enterprise with many organisations should script the installations call per organisation, stream audit logs (Enterprise Cloud) to a SIEM, and set approval policies centrally, because a single owner reviewing dozens of organisations in the UI will miss scope changes.

Framework mapping

Practitioner checklist

• Export installed GitHub Apps with permissions and repository selection via the API.
• Export the OAuth app policy page and confirm restrictions are enabled.
• Pull 180 days of integration and OAuth audit events and export them.
• Assign a named owner to every remaining integration.
• Narrow all-repository Apps to selected repositories where possible.
• Suspend before uninstalling, and deny OAuth apps no one claims.
• Ask members to revoke personal authorisations for removed apps.
• Forward installation and approval events to the SIEM.

Standards and references

• GitHub Docs: Reviewing and modifying installed GitHub Apps
• GitHub Docs: Reviewing GitHub Apps installed in your organization
• GitHub Docs: List app installations for an organization
• GitHub Docs: About OAuth app access restrictions
• GitHub Docs: Denying access to a previously approved OAuth app
• GitHub Docs: Reviewing the audit log for your organization
• GitHub Docs: Audit log events for your organization
• GitHub Docs: Reviewing your authorized OAuth apps

Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · GitHub and GitHub Actions Security Guide · OAuth Token Theft Incident Playbook · NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments