Notifications
Clear all
Topic starter
23/06/2026 7:23 pm
TL;DR: A stale API key pushed to a private GitHub repository can be harvested by infostealer pipelines and used for valid login, while quarterly reviews miss the drift between code, bots, tokens, and ownership, according to Unosecur. The real problem is that identity control ends at the cloud console long before GitHub secrets, service accounts, and developer workflows do.
NHIMG editorial — based on content published by Unosecur: Why GitHub has become the new identity blind spot and what we're doing about it
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams govern secrets stored in GitHub repositories?
A: Treat every secret in GitHub as a potential credential lifecycle event, not just a source-code mistake.
Q: Why do GitHub repositories create an identity governance gap?
A: GitHub creates a governance gap because it mixes human collaboration, machine access, and deployment automation in one workflow.
Q: What breaks when access reviews are limited to quarterly cycles?
A: Quarterly reviews break down when identities are created, changed, or exposed in minutes.
Practitioner guidance
- Inventory repository identities continuously Map every human user, bot, token, webhook, and service account connected to GitHub.
- Treat exposed secrets as active credentials When a key or token appears in code or history, assume it is usable until revoked.
- Move from periodic review to continuous drift detection Scan repositories for orphaned members, shadow admins, non-MFA access, SSO bypasses, and over-broad roles on a continuous basis.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Walkthrough of the GitHub integration workflow for discovery, detection, and revocation inside developer repositories.
- Examples of orphaned members, shadow admins, non-MFA logins, and SSO bypasses that the platform says it can surface.
- The repo-to-HR ownership mapping approach used to decide when a key should be revoked rather than monitored.
- The specific remediation flow that opens a Jira ticket after access is revoked.
👉 Read Unosecur's analysis of GitHub identity blind spots and secret exposure →
GitHub secrets exposure: what IAM teams are missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 3:22 am
GitHub has become an identity plane, not just a code plane. The article is right to frame GitHub as a blind spot because credentials, bots, and repository access now function as first-class identities. That means the governance model must extend beyond source control review and into identity inventory, ownership, and revocation discipline. For practitioners, the lesson is that GitHub state is identity state.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which helps explain why leaked credentials are so often missed until they are abused.
A question worth separating out:
Q: Who is accountable when a leaked GitHub secret is used to access production systems?
A: Accountability should sit with the system owner who issued or approved the secret, not only with the repository administrator. If a credential can reach production, its lifecycle, scope, and revocation path belong in the same governance model as other privileged access. That includes identity, security, and platform teams.
👉 Read our full editorial: GitHub secrets exposure exposes the blind spot in identity control
