Notifications
Clear all
Topic starter
25/06/2026 2:54 pm
TL;DR: Red Hat confirmed a breach of a consulting GitLab instance after attackers claimed access to nearly 28,000 private repositories and about 800 Customer Engagement Reports that could include tokens, database URIs, and environment details, underscoring how consulting artefacts become credential-rich attack paths. Static secrets and shared deliverables are the governance failure, not just the repository exposure.
NHIMG editorial — based on content published by Aembit covering the Red Hat GitLab consulting breach: Red Hat GitLab breach exposes how consulting repositories can become credential risk
By the numbers:
- GitHub alone reported more than 39 million secrets leaked across repositories in 2024.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: What breaks when consulting repositories contain live credentials?
A: When consulting repositories contain live credentials, they stop being documentation and become access infrastructure.
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.
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.
Practitioner guidance
- Audit consulting repositories for embedded credentials Scan GitLab, GitHub, and shared deliverable stores for tokens, keys, certificates, full URIs, and environment files.
- 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.
- 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.
What's in the full article
Aembit's full analysis covers the operational detail this post intentionally leaves for the source:
- Repository and engagement patterns that let consulting deliverables double as secrets stores
- Specific examples of how long-lived tokens move from GitLab and GitHub into customer environments
- The case for workload identity federation and just-in-time credentials in delivery workflows
- Practical steps for reducing exposure in CI/CD, partner access, and consulting handoffs
👉 Read Aembit's analysis of the Red Hat GitLab breach and consulting credential exposure →
Red Hat GitLab breach: what consulting deliverables exposed for IAM teams?
Explore further
25/06/2026 4:07 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Red Hat GitLab breach shows how consulting repos become credential risk
