GitHub NHI governance needs visibility, rotation, and app control

At a glance

What this is: This is an analysis of GitHub non-human identity governance, showing that visibility, lifecycle control, secret rotation, and permission review are the decisive controls.

Why it matters: It matters because GitHub has become a high-density identity plane where NHI, workflow automation, and human collaboration intersect, and IAM teams need a cleaner governance model to prevent hidden access from becoming persistent exposure.

By the numbers:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.

👉 Read Oasis Security's blog on enhancing GitHub security with NHI visibility and lifecycle control

Context

GitHub security fails when teams treat repositories as code-only systems instead of identity systems. In practice, GitHub hosts machine users, personal access tokens, SSH keys, GitHub Apps, OAuth Apps, deploy keys, and repository secrets, all of which can persist long after the business need has changed.

The governance gap is visibility plus lifecycle control. Without a reliable view of what non-human identities exist, where secrets are used, and which integrations have excessive permissions, organisations end up managing GitHub access reactively instead of through an identity programme.

That is why GitHub NHI security has moved beyond simple secrets handling. The relevant question is not whether automation exists, but whether the organisation can bound, review, and retire the identities that automation depends on.

Key questions

Q: How should security teams govern GitHub non-human identities?

A: Security teams should govern GitHub non-human identities as a single entitlement surface, not as separate repository settings. That means inventorying machine users, tokens, keys, apps, and secrets together, assigning ownership, and enforcing expiry and recertification so access can be retired when the workflow changes.

Q: Why do GitHub secrets become a governance risk so quickly?

A: GitHub secrets become a governance risk because they are often embedded in automation that expects continuous access, which encourages long-lived credentials and weak retirement discipline. Once a secret outlives the original use case, the organisation has standing access it may no longer track.

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

A: Over-permissioned GitHub Apps and OAuth Apps create hidden access paths that widen blast radius across repositories and connected services. The breakage is not just excess scope, but the loss of confidence that app access still matches the business purpose that justified it in the first place.

Q: How do I know if GitHub NHI controls are actually working?

A: They are working when you can show a complete inventory, an owner for every identity, a current expiry or rotation schedule for every secret, and a regular review of app scopes. If orphaned tokens and dormant integrations still exist, the control plane is not mature enough.

How it works in practice

GitHub non-human identities and secret sprawl

GitHub NHI governance starts with the fact that repositories, workflows, and app integrations can all carry identity material. Machine users, PATs, SSH keys, deploy keys, OAuth Apps, and repository or organisation secrets each create a different exposure surface. The technical risk is not just theft but persistence, because many of these credentials are long-lived and difficult to inventory once they are embedded in scripts, CI/CD workflows, or third-party integrations. When teams cannot map the full identity graph, they lose the ability to reason about blast radius or to tell which access paths are legitimate.

Practical implication: build a complete inventory of GitHub identities, secrets, and app connections before you try to optimise policy.

Secret rotation and expiration in GitHub workflows

Rotation matters in GitHub because secrets are often consumed by automation that expects uninterrupted access. That makes stale tokens and long expiration periods especially risky: the longer a credential lives, the more opportunity there is for reuse outside its intended context. Rotation only works when it is tied to ownership, expiry, and workflow dependency, otherwise teams simply replace one long-lived secret with another. The operational challenge is to keep automation running while shrinking the time window in which a credential can be abused.

Practical implication: tie secret rotation to workflow ownership and expiry enforcement, not to informal calendar reminders.

Over-permissive GitHub Apps and OAuth exposure

GitHub Apps and OAuth Apps are powerful because they can act across repositories and services, but that same reach makes them a governance problem when permissions drift. Excessive scopes, inactive integrations, and shadow apps create hidden access channels that outlive the team’s original intent. The control issue is not just least privilege at onboarding, but continuous review of what each app can still reach after project changes, vendor changes, or team restructuring. GitHub becomes safer when app permissions are treated as living entitlements, not static configuration.

Practical implication: recertify GitHub Apps and OAuth Apps as entitlements, with a focus on scope creep and unused access.

NHI Mgmt Group analysis

GitHub NHI governance fails first at inventory, not at enforcement. The platform contains multiple identity forms, but most programmes only see a fragment of them because secrets, apps, and machine users are distributed across repositories and workflows. That means remediation starts from an incomplete map, which weakens every downstream control decision. Practitioners should treat identity discovery as the prerequisite to governance, not as a reporting exercise.

Stale GitHub credentials create standing access debt. PATs, deploy keys, and repository secrets can remain valid long after the original use case has disappeared, and that persistence is what attackers exploit. This is a control gap in lifecycle management, not a failure of developer productivity. The implication is that GitHub access should be governed as an active entitlement with ownership, expiry, and retirement logic.

Over-permissive apps turn collaboration into hidden infrastructure access. GitHub Apps and OAuth Apps often inherit more reach than teams realise, especially when they are added for convenience and never re-evaluated. That creates a shadow authorization layer inside the software delivery chain. Security teams should treat app scope drift as a governance defect that widens blast radius across repositories and connected services.

GitHub is becoming a non-human identity control point, not just a source code platform. Once secrets, workflows, and third-party integrations dominate access paths, the security model stops being repository centric and becomes identity centric. That shifts the discipline toward OWASP Non-Human Identity Top 10 and NIST CSF access governance, where visibility, revocation, and recertification matter more than perimeter controls. The practical conclusion is that GitHub must sit inside the enterprise NHI programme.

Stale identities are the named concept this problem deserves. In GitHub, stale identities are not only unused accounts, but also dormant apps, forgotten tokens, and keys that still authenticate after their business purpose has ended. That is a lifecycle failure that accumulates unnoticed because collaboration platforms normalise long-lived access. The practitioner takeaway is that GitHub must be measured by retirement rate as much as by detection rate.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to the State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility at all.
• That visibility gap is why teams should also review The 52 NHI breaches Report when building GitHub governance programmes. It shows how identity drift turns into incident exposure once access is no longer tightly bound to lifecycle and ownership.

What this signals

GitHub is no longer just a development platform, it is an identity plane with its own governance debt. As repositories accumulate machine users, secrets, and app connections, the programme signal to watch is whether access can still be enumerated, owned, and retired at the same speed that engineering adds integrations.

Identity blast radius: when repository secrets, app scopes, and workflow permissions are governed together, the enterprise can actually see how far one compromised credential can travel. That makes GitHub a test case for NHI governance maturity across the broader delivery stack.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the pattern in GitHub is not isolated. It mirrors the wider NHI governance problem: access that cannot be fully observed cannot be confidently certified, and what cannot be certified will eventually become residual risk.

For practitioners

• Inventory every GitHub identity type Map machine users, PATs, SSH keys, deploy keys, GitHub Apps, OAuth Apps, and repository or organisation secrets into one register so owners and expiry dates are visible.
• Enforce expiry on long-lived credentials Set rotation and expiration rules for tokens and keys, then verify that automation can survive a planned rollover without creating emergency exceptions.
• Recertify app permissions as entitlements Review GitHub Apps and OAuth Apps for unnecessary scopes, unused access, and shadow connections, and remove permissions that no longer match the workflow.
• Detect and retire stale identities fast Alert on inactive machine users, orphaned deploy keys, and unused secrets, then require business owners to confirm whether each item still supports an active workflow.

Key takeaways

• GitHub security fails when identity sprawl is treated as a tooling issue instead of a governance issue.
• Stale secrets, over-permissioned apps, and dormant machine users are the main control failures that widen exposure.
• The control model that matters is inventory plus ownership plus expiry, because those three determine whether GitHub access can be governed at all.

Key terms

• GitHub non-human identity: A GitHub non-human identity is any credentialed machine actor used to automate repository or workflow activity. In practice, this includes tokens, keys, apps, and machine users. The governance challenge is that these identities can persist, overlap, and outlive the business purpose that created them.
• Secret rotation: Secret rotation is the planned replacement of credentials before they become too old or too widely exposed to trust. In GitHub environments, rotation must account for workflow dependencies, owners, and expiry so automation keeps working while standing access is reduced.
• Shadow app: A shadow app is an OAuth or GitHub App that exists in the environment without clear ownership or active oversight. These integrations are risky because they can retain broad permissions quietly, making it hard to judge whether the access is still needed or still appropriate.
• Identity blast radius: Identity blast radius is the amount of systems, repositories, or workflows that a compromised credential can reach. In GitHub, it expands quickly when apps, secrets, and permissions are shared across many projects, so governance must focus on reducing reach as well as detecting abuse.

Deepen your knowledge

GitHub NHI inventory, secret rotation, and app recertification are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme for developer tooling, it is worth exploring.

This post draws on content published by Oasis Security: Enhancing GitHub Security with Oasis. Read the original.