GitHub identity blind spots expose broader NHI governance gaps

At a glance

What this is: Unosecur’s GitHub integration extends identity governance into code workflows, focusing on visibility, least privilege, and threat detection for users, bots, tokens, and secrets.

Why it matters: It matters because GitHub has become a live identity control plane for both human and non-human identities, and blind spots there can widen supply chain and privilege risk across IAM and NHI programmes.

By the numbers:

• Customers can correlate GitHub findings with cloud-native signals in a single dashboard, reducing mean time to remediate identity threats by up to 60 percent in early deployments.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Unosecur's analysis of native GitHub identity visibility and risk

Context

GitHub has become part of the identity surface, not just the developer workflow. Tokens, bots, service accounts, and secrets often accumulate there faster than governance teams can inventory them, which makes privilege drift and hidden access a control problem rather than a tooling inconvenience.

For IAM and NHI programmes, the gap is simple to describe and hard to close: security teams often govern cloud consoles and directories more tightly than they govern the repositories where credentials are created, reused, and exposed. That gap is common, not exceptional, in modern software supply chains.

This announcement points to a broader operating reality. Identity security now has to follow code, because code paths increasingly create the access paths that later appear in incident reports.

Key questions

Q: How should security teams govern GitHub access as part of identity security?

A: Security teams should govern GitHub as an identity domain, not only as a development platform. That means inventorying users, bots, tokens, secrets, and integrations, then reviewing repository permissions, OAuth scopes, and workflow access in the same programme that covers cloud and directory entitlements. Without that joined-up view, privilege drift and hidden access remain outside governance.

Q: Why do GitHub repositories create NHI risk for IAM teams?

A: GitHub repositories create NHI risk because they often contain the credentials and automation identities that actually touch production systems. Secrets, tokens, and service accounts can be over-privileged, reused across workflows, or left behind when teams change. That makes the repository a control point for both exposure and escalation, not just source code storage.

Q: What breaks when secrets and bots are not governed inside GitHub?

A: When secrets and bots are not governed inside GitHub, organisations lose track of who or what can act, where those credentials are stored, and whether access still matches the intended task. The result is access sprawl, orphaned privilege, and delayed revocation, which can turn a repository issue into a broader cloud compromise.

Q: How do security teams reduce identity blind spots across code and cloud?

A: They reduce blind spots by correlating GitHub activity with cloud identity signals, enforcing least privilege on repository and workflow permissions, and treating exposed secrets as lifecycle events. That approach helps teams detect drift earlier and cut the time between exposure, investigation, and revocation.

How it works in practice

GitHub as an identity plane

GitHub now functions as a live identity plane because access, collaboration, and automation all intersect in the same place. Users, bots, tokens, and secrets each have different governance needs, but they often appear together in repository, organization, and workflow settings. The technical risk is that the same platform can hold durable human access, ephemeral automation credentials, and embedded secrets side by side. That mixture makes visibility incomplete if teams only look at directory identities or cloud IAM.

Practical implication: inventory GitHub as an identity domain, not just a source-control platform.

Least privilege in repositories and workflows

Least privilege in GitHub is not limited to repository membership. It also includes OAuth scopes, workflow permissions, admin roles, secret access, and the privileges inherited by integrations. When those permissions drift, a token or bot can keep more power than its task requires, especially when scopes were granted for convenience and never revisited. The result is identity sprawl inside development workflows, which creates a wider attack surface than many security teams expect.

Practical implication: review GitHub scopes and workflow permissions with the same rigor used for cloud entitlements.

Identity threat detection across code and cloud

Identity threat detection becomes more effective when GitHub findings are correlated with cloud-native signals. That correlation matters because suspicious repository access, secret exposure, and abnormal admin activity often become meaningful only when they are seen alongside workload or cloud changes. Agentless connection models reduce deployment friction, but the real value is in connecting repository identities to broader entitlement and incident data so teams can spot drift before it becomes escalation.

Practical implication: connect repository events to cloud and IAM telemetry for faster triage.

NHI Mgmt Group analysis

GitHub is now an identity control plane, not a peripheral developer system. Once users, bots, tokens, and secrets all live in the same workflow surface, governance teams can no longer treat repository access as separate from identity security. The practical consequence is that visibility, policy enforcement, and detection must extend into the code system itself.

Unified identity visibility is the missing control in most software supply chains. Access sprawl, orphaned admin accounts, non-MFA logins, and SSO bypasses all become harder to justify once GitHub is treated as a governed identity domain. The article’s core message aligns with the wider NHI problem: unmanaged repository identities widen the same attack surface that already exists in cloud IAM.

Secret exposure in GitHub is a lifecycle problem before it is a detection problem. Credentials placed in repositories or workflow contexts often persist beyond the moment they were needed, which means the issue is not only discovery but offboarding and revocation discipline. The implication is that identity governance for development platforms must include credential lifecycle control, not just access review.

GitHub blind spots reveal a broader identity blast radius. When access patterns in code repositories are not correlated with cloud entitlements, organisations lose the ability to see how a repository event can become an infrastructure event. That is the governance gap: the same identity can now operate across development, automation, and cloud execution paths, so practitioners must manage the blast radius as a connected system.

Repository identities are now part of Zero Trust scope. If the code platform can create, store, or trigger access, then trust decisions cannot stop at the directory or the cloud console. The broader field lesson is that least privilege has to travel with the workflow, or it becomes a policy that ends where the code begins.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• That visibility gap is why practitioners should also review NHI Lifecycle Management Guide when repository identities, tokens, and secrets outlive their intended use.

What this signals

Identity blast radius: When GitHub becomes a place where access is created, stored, and triggered, security teams need a way to measure how far one repository identity can reach. That is a programme design issue, not just a monitoring issue, and it should be reflected in entitlement reviews, secret governance, and incident triage.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the operating assumption should be that repository exposure is normal until proven otherwise. Ultimate Guide to NHIs remains a useful baseline for teams mapping that exposure across their environment.

The next step for mature programmes is to connect repository identity governance with lifecycle controls, especially revocation and offboarding. The NHI Lifecycle Management Guide is the right starting point when teams need to move from spotting exposure to closing it.

For practitioners

• Inventory GitHub as part of your identity estate Map every user, bot, token, secret, and integration in GitHub, then classify which identities are human, NHI, or automation-linked. Use that inventory to identify orphaned accounts and access paths that are invisible in your central IAM tools.
• Review repository and workflow entitlements together Audit repository membership, OAuth scopes, workflow permissions, and secret access in one review cycle so teams can see where privilege accumulates across the developer path. Pair the review with cloud entitlement data to expose drift that is otherwise hidden.
• Treat secrets in code as revocation events When credentials are found in repositories or workflow contexts, remove them as a lifecycle issue, not just a detection alert. Rotate the secret, trace its usage, and revoke any dependent access that outlived the original task.
• Correlate GitHub telemetry with cloud identity signals Feed repository events into your identity threat detection process so unusual admin activity, token use, or secret exposure can be compared with cloud changes in real time. That correlation helps shorten investigation paths and prioritise the identities most likely to expand blast radius.

Key takeaways

• GitHub now carries identity risk as well as code risk, because users, bots, tokens, and secrets all coexist in the same workflow surface.
• Visibility gaps and privilege drift in repositories can widen the attack surface across both NHI and cloud environments.
• Teams that correlate repository telemetry with IAM and lifecycle controls can reduce blind spots and shorten remediation paths.

Key terms

• Identity control plane: An identity control plane is the set of systems where access is created, managed, observed, and revoked. In practice, GitHub can become part of that plane when users, bots, secrets, and workflow permissions all influence who or what can act in production environments.
• Identity blast radius: Identity blast radius is the amount of system access an identity can reach if it is misused, exposed, or over-privileged. In NHI programmes, it measures how far a token, bot, or service account can move across repositories, cloud resources, and automation paths before containment occurs.
• Secret lifecycle: Secret lifecycle is the full path of a credential from creation to storage, use, rotation, and revocation. For GitHub and similar platforms, weak lifecycle discipline is what allows a temporary secret to become a persistent exposure point after the original task has ended.

What's in the full announcement

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• How the native GitHub integration inventories users, bots, tokens, and secrets inside repositories and organizations
• The specific access-sprawl, orphaned-account, and privilege-drift findings surfaced by the integration
• What the agentless OAuth connection collects, and which read-only scopes are required for deployment
• How the dashboard correlates GitHub findings with cloud-native signals to support remediation workflows

👉 The full Unosecur post covers the GitHub findings, cloud correlation, and remediation context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.