GitLab SSH keys and the hidden NHI governance gap

At a glance

What this is: This guide explains how GitLab SSH keys work and why poor key hygiene creates hidden access risk across developer and machine workflows.

Why it matters: It matters because SSH keys often sit outside normal IAM visibility, yet they can grant durable access to code, pipelines, and infrastructure across human and NHI programmes.

By the numbers:

• 88% of all web application attacks involved stolen credentials.
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Apono's guide to managing GitLab SSH keys

Context

GitLab SSH keys are a machine-readable way to prove identity for repository access, deployments, and automation. In practice, they function as non-human credentials when used by CI/CD tools, infrastructure bots, and deployment workflows, which means SSH key governance belongs in the same programme as secrets management and NHI oversight.

The control problem is not cryptography, but lifecycle and scope. Keys that are reused, left unrotated, or kept on shared systems create persistent access paths that bypass the visibility most IAM teams expect from passwords, MFA, and standard user offboarding.

Key questions

Q: How should security teams govern GitLab SSH keys used by automation?

A: Treat every automation SSH key as a non-human identity credential with an owner, purpose, scope, and expiry date. Limit it to the smallest repository or deployment task it needs, rotate it on a schedule, and revoke it automatically when the workflow ends. Central inventory matters because unmanaged keys become invisible standing access.

Q: Why do GitLab SSH keys create more risk than passwords in some environments?

A: SSH keys often bypass the visibility and alerting that teams expect from password-based access. If a private key is reused, copied, or left active after offboarding, it can authenticate silently across repositories and pipelines. That makes lifecycle control and revocation speed more important than the authentication method itself.

Q: What breaks when GitLab SSH keys are not rotated or expired?

A: The organisation loses track of which keys are still valid, which systems still trust them, and whether a retired person or workflow can still reach critical repositories. That creates persistent access paths that are hard to detect and harder to prove safe. Rotation and expiry are what prevent keys from becoming dormant but active credentials.

Q: Who is accountable when a GitLab SSH key is left active after offboarding?

A: Accountability should sit with the identity or platform team that owns GitLab access governance, but the control failure usually spans HR, IAM, and engineering operations. Offboarding must remove the key from GitLab and any connected automation promptly. If revocation is manual, the process is already too weak for audit-ready identity governance.

Technical breakdown

How GitLab SSH key authentication works

GitLab SSH access relies on a public-private key pair. The public key is registered with GitLab, while the private key stays on the user or machine and proves possession during authentication. That makes SSH suitable for automation because no password needs to travel over the network. The security model assumes the private key remains protected, unique, and revocable. Once that assumption breaks, the key becomes a durable bearer credential. In NHI contexts, the risk is not only theft but reuse across workflows, devices, and environments, which expands blast radius beyond the original repository.

Practical implication: treat SSH keys as governed credentials with inventory, ownership, and expiry, not as developer convenience artifacts.

Why SSH keys become NHI credentials in CI/CD

When GitLab SSH keys are used by pipelines, deployment jobs, or infrastructure bots, they cease to be purely human convenience tokens and become machine identities. Those identities often need scoped access to code, build systems, and release targets, but static keys make it hard to distinguish intended automation from abuse. The governance challenge is lifecycle: who owns the key, which system uses it, and when it should expire. Without explicit lifecycle controls, a key can outlive the task, the host, or the contractor that created it.

Practical implication: assign every automation key to a named workload or service and enforce expiry aligned to the workload lifecycle.

SSH agent use, rotation, and offboarding controls

SSH agents cache private keys in memory for convenience, but they do not solve key hygiene. Rotation still matters because a cached or loaded key can remain valid long after the original reason for access has passed. Offboarding is equally important: if a contributor leaves, their SSH keys must be removed from GitLab and any linked access systems. The technical issue is not only authentication, but revocation latency. The longer a key remains active, the more opportunity there is for replay, misuse, or forgotten access paths.

Practical implication: wire key rotation and offboarding into identity lifecycle workflows so revocation happens with the same discipline as provisioning.

Threat narrative

Attacker objective: The attacker wants durable, low-friction access to code and deployment paths that can be used for covert changes or lateral movement.

1. Entry occurs when an attacker obtains a reused, exposed, or poorly protected GitLab SSH private key and uses it to authenticate without triggering password-based alerts.
2. Escalation follows when the same key is valid across repositories, deployment contexts, or automation paths, allowing unauthorized code changes or broader pipeline access.
3. Impact arrives through untraceable repository manipulation, compromised builds, or persistence inside CI/CD workflows that trust the key as a legitimate identity.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static SSH keys are an NHI governance problem, not just a Git hygiene problem. Once GitLab SSH keys are used by pipelines, deploy tools, and infrastructure bots, they become machine credentials that need the same lifecycle discipline as any other NHI. The article’s real signal is that authentication can be technically strong while governance remains weak. Practitioners should stop treating SSH access as a developer-only concern and fold it into machine identity inventory and ownership.

Long-lived repository keys create standing privilege in disguise. A key that survives beyond the workflow, device, or contractor that created it is functionally standing access. That is the hidden governance failure the article surfaces: access survives because revocation is manual, fragmented, or delayed. The practitioner takeaway is that GitLab key control must be governed as lifecycle, not as a one-time configuration.

Ephemeral access models expose the weak point in traditional SSH handling. The article points toward just-in-time access and expiry as the correct direction because static keys do not align with modern pipeline trust. This aligns with OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 thinking on access control and recovery. Practitioners should see key expiry as a control boundary, not an administrative preference.

Secret sprawl debt is the right concept for SSH key risk. The same pattern that drives leaked API keys and stale tokens also applies to GitLab SSH keys: access accumulates faster than teams can see, classify, and retire it. The implication is broader than GitLab, because the same control weakness often exists across CI/CD, cloud consoles, and service accounts. Security teams need one governance model for all non-human secrets, not separate exceptions for each tool.

Offboarding failure is the clearest indicator that SSH key governance is incomplete. If a leaver’s key remains valid after departure, the organisation has already lost control of the credential lifecycle. That failure spans human and NHI governance because the same deactivation logic should remove access when the person, workload, or automation task ends. The practitioner conclusion is simple: if offboarding does not revoke SSH access automatically, the programme is operating with residual standing privilege.

From our research:

• Only 44% of organisations are currently using a dedicated secrets management system, according to The 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• This is why the next step is lifecycle control across all non-human credentials, not just SSH key hygiene, as discussed in Guide to the Secret Sprawl Challenge.

What this signals

Secret sprawl debt: GitLab SSH keys illustrate how organisations accumulate non-human credentials faster than they can govern them. The gap is not only technical rotation, but ownership, expiry, and revocation across CI/CD and repository access paths, which is why secrets management must sit inside identity governance rather than beside it.

The programme signal is clear: if GitLab access still depends on manually maintained keys, the organisation is carrying standing privilege in a machine-friendly form. That is where NHI governance, IAM lifecycle, and offboarding discipline converge, and it is the point at which auditability starts to fail.

Teams should expect more pressure to unify human and machine revocation workflows. Once access is tied to keys rather than interactive sign-in, the security model depends on lifecycle control, not login friction, and that changes how access reviews, incident response, and repository governance need to operate.

For practitioners

• Inventory GitLab SSH keys by owner and workload Build a complete register of who or what uses each key, which repository or deployment it touches, and whether it supports a human or a machine identity.
• Set explicit expiry on every non-human SSH key Use key expiration for contractors, ephemeral environments, and automation accounts so access ends with the task rather than surviving by default.
• Rotate keys on a defined lifecycle schedule Replace long-lived keys with a rotation cadence tied to device change, role change, or workflow retirement, and remove old public keys immediately.
• Automate key revocation in offboarding workflows Connect HR, IAM, and GitLab processes so departing users and retired automations lose SSH access before any remaining session or deployment window can be abused.
• Separate human access from pipeline access Use distinct credentials for developers and automation so review, audit, and revocation decisions do not blur across different identity types.

Key takeaways

• GitLab SSH keys are often non-human credentials in practice, so they need lifecycle governance, ownership, and expiry.
• Static or reused keys create standing access that can persist beyond the workflow, device, or person that created them.
• The control that matters most is automatic revocation aligned to offboarding and pipeline retirement, not just stronger key generation.

Key terms

• GitLab SSH key: A GitLab SSH key is a public-private key pair used to authenticate access to repositories and related automation without a password. In practice, it can represent either a human user or a machine identity, so its ownership, scope, and expiry must be governed like any other credential.
• Non-human identity: A non-human identity is a credentialed system, service, or automation account that performs work without a person logging in interactively. Examples include CI/CD tools, deployment bots, API tokens, and SSH keys used by workflows. These identities need scoped access, lifecycle control, and revocation just like human accounts.
• Standing privilege: Standing privilege is access that remains valid all the time rather than only when it is actively needed. For SSH keys and other non-human credentials, standing privilege increases the chance that stale access survives role changes, offboarding, or workflow retirement and becomes available for misuse.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across tools, users, pipelines, and environments. It creates blind spots because teams lose track of where secrets live, who owns them, and whether they are still valid, which makes rotation, inventory, and revocation harder to execute reliably.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme maturity, it is worth exploring.

This post draws on content published by Apono: The Secure Guide to Managing GitLab SSH Keys. Read the original.