GitHub secrets exposure: what IAM teams are missing

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 →