Open-source software giant Red Hat has confirmed that one of its GitLab instances, dedicated to consulting engagements, was breached. The attackers, a group calling itself “Crimson Collective,” claim to have taken nearly 28,000 private repositories and roughly 800 Customer Engagement Reports (CERs).
CERs often contain detailed records of client environments – network diagrams, configuration data, authentication tokens, even full database URIs. In other words, they mix context with credentials for convenience, turning a reference document into both the map and the keys for the client’s environment.
The attackers in this case published a directory listing of these reports, revealing a client roster that stretches from major banks and telecoms to U.S. government bodies and agencies. While Red Hat has sought to limit the scope by emphasizing that the incident affects only its consulting division, the breach illustrates how supply-chain trust can unravel when credentials and architectural details are spread across third parties.
Consulting engagements often serve as connective tissue between enterprises and their vendors. A consulting report might live in a repository that also contains scripts and tokens used for proof-of-concept deployments. Over time, those codebases accumulate sensitive material that extends well beyond the engagement itself. Once exposed, they become launchpads for lateral movement into customer environments.
History shows how these patterns play out – and it was a reminder of why GitLab had been front of mind for us. We have just come off a major campaign around credential lifecycle management for GitLab, announcing new capabilities to replace long-lived personal access tokens with short-lived, identity-driven credentials that appear only when needed.
The emphasis on CI/CD was deliberate. GitHub and GitLab repositories have repeatedly yielded OAuth tokens, cloud keys, and service account credentials. Pearson and the Internet Archive both recently saw GitLab token exposure lead to data theft. In another case, attackers moved from a partner’s GitHub account into Salesforce customer environments by abusing long-lived tokens. Each time, the common denominator was the same: non-human identities represented by static credentials, stored in places never intended to serve as long-term vaults. And now, with agentic AI workloads beginning to operate side by side with traditional software development pipelines, the number of non-human identities multiplying inside repositories is only growing.
What should security teams take from this episode?
First, that codebases are not neutral storage locations. They often double as defacto credential repositories. Second, that third-party deliverables, no matter how carefully prepared, can embed more operational data than their recipients may realize. Third, and arguably most consequential, that the distinction between a vendor’s environment and a customer’s environment erodes once long-lived tokens and keys are involved. For organizations experimenting with agentic AI, this erosion is even more pronounced: autonomous agents do not mint their own credentials – they simply inherit whatever static secrets are present in code, configs, or pipelines, and will reuse them across contexts, carrying risk directly into production environments.
The Red Hat breach is another reminder that CI/CD has become one of the most attractive avenues for adversaries, not just because of code access, but because of the credentials and infrastructure details intertwined with it.
So what options exist to reduce this specific risk – and others like it – especially now that autonomous AI agents are part of everyday enterprise environments?
Recommended Takeaways
What Should You Do Right Now?
- Rotate and revoke immediately: Any credential shared with Red Hat Consulting should be considered exposed. Tokens, keys, and service account credentials tied to those engagements must be rotated without delay.
- Assume secondary exposure: Downstream providers and partners may also be at risk. Verify whether integrations or third parties accessed your environment using Red Hat-managed credentials.
What Can You Avoid This Exposure Threat in the Future?
- Audit repositories for embedded secrets: Treat repositories as potential secrets stores. Scan them systematically for configuration files, tokens, and environment variables that may have been committed historically. (GitHub alone reported more than 39 million secrets leaked across repositories in 2024.)
- Revisit consulting practices: Push back on the practice of embedding live credentials or full connection strings in deliverables. Require that consulting engagements use ephemeral policy-scoped credentials instead.
- Get rid of secrets altogether: Apply workload identity federation and just-in-time credentials to GitLab, GitHub, and other CI/CD platforms, ensuring that static tokens never accumulate in repositories or reports in the first place. This same approach will be essential for AI agents that need to call APIs or cloud services – short-lived, identity-based credentials that vanish once the connection is complete.
The broader lesson of this incident is how fragile trust becomes once static credentials are left to sprawl across repositories and third-party deliverables. Attackers know that these artifacts often offer a fuller picture of an environment than they could easily piece together on their own – and if they include valid tokens, that picture doubles as a way in. Until organizations move non-human identities to secretless access, breaches like this will remain inevitable.
To learn how the Aembit Workload IAM Platform can help, visit aembit.io.
