Notifications
Clear all
Topic starter
06/06/2026 1:54 am
TL;DR: GitHub environments concentrate machine users, PATs, SSH keys, apps, and secrets in a single collaboration surface, making stale identities, unrotated credentials, and over-permissive integrations the main governance risks according to Oasis Security. The control problem is not automation itself but visibility into what exists, who can use it, and when access should expire.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full announcement
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup of the GitHub integration and how the discovery workflow maps NHIs and secrets.
- The specific checks used to flag stale identities, unrotated secrets, and over-permissive apps.
- The integration’s alerting flow for anomalous activity in sensitive repositories.
- The source’s implementation context for teams that need to connect governance findings to day-to-day GitHub administration.
👉 Read Oasis Security's blog on enhancing GitHub security with NHI visibility and lifecycle control →
GitHub NHI security: what teams need to govern now?
Explore further
06/06/2026 3:16 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: GitHub NHI governance needs visibility, rotation, and app control
