Red Hat GitLab breach shows how consulting repos become credential risk

At a glance

What this is: Red Hat’s consulting GitLab breach shows how third-party deliverables can combine architectural context with live credentials and create a direct path into customer environments.

Why it matters: IAM, NHI, and PAM teams need to treat consulting repositories and reports as credential-bearing systems because exposure of static secrets can widen supplier risk into customer environments.

By the numbers:

• GitHub alone reported more than 39 million secrets leaked across repositories in 2024.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Aembit's analysis of the Red Hat GitLab breach and consulting credential exposure

Context

Red Hat’s consulting GitLab breach is a classic example of how credential sprawl turns ordinary delivery artefacts into security liabilities. In NHI terms, the issue is not source code alone but the habit of storing tokens, keys, and full connection details alongside environment documentation, where they can be reused if exposed.

For IAM and NHI programmes, consulting output has to be treated as part of the access surface. Once a report, script, or proof-of-concept bundle contains live secrets, the boundary between vendor environment and customer environment becomes porous, and downstream compromise can follow the original exposure.

Key questions

Q: What breaks when consulting repositories contain live credentials?

A: When consulting repositories contain live credentials, they stop being documentation and become access infrastructure. That creates a hidden path from delivery artefacts into customer systems, because an exposed token or key can be reused without defeating authentication again. The practical failure is not just disclosure, but uncontrolled reuse across organisations and environments.

Q: Why do static NHI credentials increase third-party breach impact?

A: Static NHI credentials increase third-party breach impact because they persist beyond the moment of use. If a token or service account secret is copied into a report or repository, the attacker can replay it later and potentially pivot into connected systems. The longer the credential lives, the larger the downstream blast radius becomes.

Q: How do security teams know if consulting artefacts are outside governance?

A: Security teams know consulting artefacts are outside governance when deliverables contain tokens, secrets, database URIs, or access notes that were never meant to survive the engagement. A simple scan is not enough. The programme needs ownership, lifecycle, and revocation rules for every shared artefact that can expose identity material.

Q: Who is accountable when a vendor deliverable exposes customer access?

A: Accountability is shared across the vendor, the customer, and any third party that handled the deliverable, but the control failure sits with whoever allowed reusable access material to persist. The cleanest governance answer is to define who owns secret removal, who approves distribution, and who revokes access when the engagement ends.

Technical breakdown

Why consulting repositories become credential stores

Consulting repositories often accumulate more than code. They contain diagrams, scripts, environment files, and pasted credentials that make deployment easier but also concentrate risk in a single system of record. When private GitLab projects are used to hold both delivery material and live access data, the repository becomes a de facto secrets repository with no lifecycle controls, rotation policy, or expiry boundary. That is a structural NHI problem, not just a storage mistake.

Practical implication: classify consulting repositories as secrets-bearing assets and apply explicit controls for discovery, rotation, and offboarding.

Why Customer Engagement Reports widen the blast radius

Customer Engagement Reports often compress architecture, troubleshooting notes, and access material into one package. That convenience creates identity risk because the report can reveal the shape of an environment and the keys needed to reach it. A leaked CER is therefore both reconnaissance and access enablement. The threat is amplified when those documents are distributed across third parties, because each copy expands the number of places where a credential can persist beyond its intended use.

Practical implication: remove live secrets from deliverables and force any shared access to be short-lived and separately governed.

How static NHI credentials turn repository exposure into lateral movement

Static non-human identities are durable by design, which makes them reusable when copied into repositories, reports, or scripts. If a token or service account credential appears in a consulting artefact, the attacker does not need to defeat authentication mechanics again. They can reuse the exposed identity, move into connected systems, and pivot across environments that trust the original issuer. That is why static credential placement, not just code exposure, is the real root cause.

Practical implication: replace long-lived credentials with workload identity and just-in-time access so exposed artefacts cannot be reused.

Threat narrative

Attacker objective: The attacker seeks reusable access material and environment intelligence that can be turned into lateral movement into downstream customer systems.

1. Entry occurred when attackers compromised the Red Hat consulting GitLab instance and accessed private repositories and engagement reports.
2. Credential access followed because those artefacts reportedly contained tokens, database URIs, and other environment details that could be reused outside the repository.
3. Impact would extend from repository theft into customer environments if exposed credentials were valid across vendor and client systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Consulting deliverables are now part of the identity attack surface: The breach shows that code, reports, and environment notes cannot be separated from NHI governance when they contain live access material. The risk is not accidental disclosure alone, but the fact that deliverables can outlive the access context they were created for. Security teams should treat consulting artefacts as governed identity objects, not passive files.

Static secrets in third-party workflows create shared accountability debt: Once a token or full connection string is copied into a consulting package, the original issuer, the vendor, and the customer all inherit exposure risk. That shared exposure changes the governance model from simple access control to lifecycle accountability across organisations. The practitioner lesson is that secrets placement determines who can still be reached later.

Repository sprawl is really identity sprawl: Red Hat’s case is another example of what happens when a repository becomes the place where access is created, stored, and reused. This is the same failure pattern seen across GitLab, GitHub, and CI/CD pipelines: static credentials turn storage systems into authentication systems. The implication is that NHI governance has to follow the artefact, not just the platform.

Secretless delivery is the real boundary control: The article reinforces the limit of detection-only programmes. If valid credentials are present in deliverables, the exposure window remains open until revocation, regardless of where the file lives. The field needs to move from monitoring leaked secrets to designing consulting and pipeline workflows that never place reusable secrets in the artefact at all.

Agentic AI will inherit the same weakness unless identity is redesigned: The article’s point about AI agents is accurate because autonomous workloads do not create a new trust model, they inherit the old one. If repositories and reports still carry static credentials, agents will simply consume and reuse them at machine speed. The governance problem is not agent behaviour alone, but the persistence of credentials that assume human-paced handling.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• Read more in Guide to the Secret Sprawl Challenge for the controls that reduce exposed secrets across repositories and pipelines.

What this signals

Secret sprawl is now an identity lifecycle problem, not just a code hygiene issue: If a consulting artefact can hold a credential, the relevant control is no longer only secret scanning. Teams need lifecycle rules that tie issuance, distribution, and revocation to the engagement boundary, including contractor offboarding and document disposal.

The next failure mode is not simply more leaked tokens, but more places where a leaked token can be reused. That is why workload identity, short-lived credentials, and artefact-level governance belong together in the same control design, especially where GitLab and CI/CD systems are used to move customer-specific material.

For teams building NHI programmes, the practical lesson is to pair secret discovery with a revocation model that can act on findings fast enough to matter. Detection without lifecycle enforcement leaves valid credentials alive, which keeps the exposure window open long after the report or repository is copied.

For practitioners

• Audit consulting repositories for embedded credentials Scan GitLab, GitHub, and shared deliverable stores for tokens, keys, certificates, full URIs, and environment files. Treat consulting outputs as potential secrets stores and flag any live credential that can be reused outside the engagement.
• Remove live secrets from customer-facing reports Redesign Customer Engagement Reports so that diagrams and troubleshooting notes cannot carry operational tokens or reusable database connection details. If a deliverable must reference access, use short-lived, separately issued credentials instead.
• Move delivery workflows to secretless access Use workload identity federation and just-in-time credentials for CI/CD and consulting activity so static tokens do not accumulate in repositories or report bundles. This reduces the chance that a copied artefact can be replayed elsewhere.
• Revoke and rotate by engagement boundary Link credential rotation to the end of the consulting engagement, not to an arbitrary calendar cycle. Any secret shared with a vendor or stored in an engagement repository should be revoked when the work package closes.

Key takeaways

• Consulting repositories become breach multipliers when they mix delivery content with live credentials.
• The scale of the problem is measured in persistent secrets, not just leaked files, and that persistence keeps downstream environments exposed.
• The control that matters most is secretless delivery with revocation tied to engagement offboarding.

Key terms

• Customer Engagement Report: A Customer Engagement Report is a delivery document used in consulting or support work to capture environment details, troubleshooting notes, and implementation context. In practice, it can become an identity risk when it includes credentials, connection strings, or authentication artefacts that should never outlive the engagement.
• Static Non-Human Credential: A static non-human credential is a long-lived token, key, certificate, or account secret used by software, services, or workflows. It is risky because reuse is easy and revocation is often delayed, which makes any copy of the credential a potential access path long after the original use.
• Secretless Access: Secretless access is an access pattern that avoids embedding reusable credentials in code, repositories, or deliverables. Instead, identity is established at runtime through short-lived, policy-scoped mechanisms such as workload identity federation or just-in-time issuance, reducing the chance that a copied artefact can be replayed.

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.

This post draws on content published by Aembit covering the Red Hat GitLab consulting breach: Red Hat GitLab breach exposes how consulting repositories can become credential risk. Read the original.