Notifications
Clear all
Topic starter
18/08/2026 2:30 pm
TL;DR: Malicious RubyGems versions of git_credential_manager, Dendreo, and a fastlane plugin used CI evasion, second-stage payload delivery, and persistence on developer machines, according to StepSecurity's SleeperGem analysis. The pattern shows how supply chain compromise can turn a package install into credential exposure, backdoor persistence, and fleet-wide secret risk.
NHIMG editorial — based on content published by StepSecurity: SleeperGem RubyGems supply chain attack and persistent backdoor analysis
Questions worth separating out
Q: What breaks when a malicious dependency can execute on developer machines but skip CI?
A: Pipeline checks can look clean while the real compromise occurs on a laptop that holds cached credentials, SSH keys, and local sessions.
Q: Why do developer workstations increase supply-chain risk so quickly?
A: Developer workstations concentrate source code, cloud credentials, CI/CD secrets, SSH keys, and repository permissions in one place.
Q: How do security teams know whether a package compromise has become CI/CD persistence?
A: Look for new GitHub workflows, newly created repositories, unfamiliar runner registrations, and unusual audit-log entries tied to repository automation.
Practitioner guidance
- Quarantine developer machines that executed the malicious gems Treat any endpoint that installed or required git_credential_manager 2.8.0 to 2.8.3, Dendreo 1.1.3 or 1.1.4, or fastlane-plugin-run_tests_firebase_testlab 0.3.2 as compromised until you verify process history, persistence, and secret exposure.
- Remove user-level persistence before reintroducing developer access Delete the dropped daemon under ~/.local/share/gcm/, remove matching systemd user services and cron entries, and confirm no autostart mechanism remains before returning the device to use.
- Rotate every credential reachable from the workstation Assume SSH keys, cloud tokens, environment file secrets, browser-stored sessions, and CLI authentication material on the affected device may have been exposed and revoke them accordingly.
What's in the full article
StepSecurity's full article covers the operational detail this post intentionally leaves for the source:
- The exact process tree observed under Harden-Runner, including the loader, downloader, daemon launch, and persistence steps.
- The indicator list for git_credential_manager, Dendreo, and fastlane-plugin-run_tests_firebase_testlab versions that should be removed from repositories and endpoints.
- The recovery sequence for removing ~/.local/share/gcm/, stopping systemd and cron persistence, and checking for the setuid ping6 backdoor.
- The workflow and endpoint detection cues StepSecurity used to validate the attack chain in real execution.
👉 Read StepSecurity's analysis of the SleeperGem RubyGems supply chain attack →
SleeperGem and RubyGems supply chains: what IAM teams should watch?
Explore further
18/08/2026 3:18 pm
Software supply chain compromise becomes identity compromise the moment a package can reach local secrets. SleeperGem is not just a malicious dependency story. It is a demonstration that developer endpoints often sit inside the identity perimeter because they hold tokens, SSH keys, cloud credentials, and browser sessions that a loader can harvest after code execution. The governance failure is assuming software trust and identity trust are separable. They are not, and practitioners should manage package execution as a secrets exposure event.
A few things that frame the scale:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
- 75% of organisations express strong confidence in their secrets management capabilities, even though leaked secrets take an average of 27 days to remediate.
A question worth separating out:
Q: Who is accountable for secret rotation after a developer endpoint compromise?
A: The owning application and platform teams are accountable for the exposed credentials, but security teams should coordinate the response across identity, endpoint, and CI owners. The key governance question is not only whether the package was removed, but which identities may have been reachable during execution. That determines the rotation scope.
👉 Read our full editorial: SleeperGem exposes developer machine risk in RubyGems supply chains
