SleeperGem exposes developer machine risk in RubyGems supply chains

At a glance

What this is: SleeperGem is a coordinated RubyGems supply chain attack that delivered a loader, skipped CI, and installed persistence on developer machines.

Why it matters: It matters because developer endpoints and build workflows can expose secrets, tokens, and privilege paths even when pipelines themselves appear clean.

👉 Read StepSecurity's analysis of the SleeperGem RubyGems supply chain attack

Context

RubyGems package compromise is a supply chain problem that becomes an identity problem as soon as the malicious code lands on a developer machine and can reach stored secrets, cloud credentials, or signing material. In SleeperGem, the attacker used a loader pattern, CI evasion, and persistence to turn a package install into endpoint-level compromise rather than a simple malicious dependency event.

For IAM and NHI teams, the key issue is not just package trust but which identities and secrets are reachable from developer workstations. When a compromised gem can inherit environment access, cached tokens, SSH keys, or browser-stored credentials, the blast radius crosses from software supply chain into identity governance and secrets management.

The behaviour described here is atypical in its coordination and persistence, but the underlying control gap is common: developer machines are often treated as lower-risk than CI, even though they can hold the richest identity context.

Key questions

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. That creates a blind spot where the software supply chain is monitored in CI but the identity surface is exposed on endpoints. The result is delayed detection and broader secret exposure.

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. When an attacker compromises that endpoint, the impact is not limited to the laptop itself. The stolen identity material can be reused to modify code, access services, and push compromise downstream into customers and production pipelines.

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. The key signal is not only secret theft, but whether the attacker has established a repeatable execution path on self-hosted infrastructure.

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.

Technical breakdown

Loader-based package compromise in RubyGems

A loader does not carry its full payload in the package itself. Instead, the malicious gem executes minimal code, contacts an external command and control host, and retrieves a second stage that performs the real work. That design lowers detection odds because static inspection sees little beyond obfuscated install logic, while runtime execution reveals the actual behaviour. In SleeperGem, the package also checked for CI environment variables and exited if it detected them, which is a deliberate evasion tactic aimed at developer machines rather than runners.

Practical implication: monitor package execution behaviour, not just source contents, and treat developer endpoints as part of the software supply chain trust boundary.

Persistence on developer endpoints

Persistence turns a one-time dependency execution into an ongoing foothold. The malicious release dropped a daemon under the user profile and registered it through both systemd and cron, creating multiple restart paths that survive simple cleanup. That is especially dangerous on developer machines because long-lived user sessions, cached credentials, and local secrets create a rich environment for post-compromise access. If the persistence layer can relaunch without further package interaction, the compromise outlives the original installation event.

Practical implication: detect and remove user-level persistence mechanisms alongside the package, not after, because the backdoor can survive the dependency being uninstalled.

Developer secrets exposure after package execution

Once code runs on a workstation, the attacker does not need to steal a password from a vault if tokens are already present in memory, configuration files, browser stores, or command-line tooling. This is where supply chain compromise becomes identity compromise: the workstation may hold cloud tokens, SSH keys, Git credentials, and session cookies that were never intended to be reachable by a package install. In practice, the attack surface is the intersection of software execution rights and identity material on the endpoint.

Practical implication: inventory every credential class reachable from developer devices and assume any machine that executed the loader may require broad secret rotation.

Threat narrative

Attacker objective: The attacker aimed to establish persistent access on developer machines and use that foothold to reach secrets and privileged identities.

1. Entry occurred through malicious RubyGems versions published to the registry and installed through normal dependency workflows.
2. Credential access and execution were gated to avoid CI, then the loader fetched a second stage and launched it on developer machines.
3. Impact came from persistence, possible privilege escalation, and the exposure of every secret reachable from the compromised endpoint.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed 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

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.

CI evasion creates a false sense of safety around pipeline-based detection. The malware deliberately exited when it detected CI variables, which means a clean pipeline scan does not prove the dependency is safe on human endpoints. That splits assurance into two very different control planes: ephemeral build runners and long-lived developer workstations. The named concept here is developer trust gap, the mismatch between how organisations secure CI and how little visibility they maintain on laptops where identity material is richest. Teams should close that gap with endpoint-level behavioural monitoring.

Persistence is the governance signal that turns a package incident into an access lifecycle incident. Once the daemon is installed and registered in multiple autostart mechanisms, simple package removal is no longer enough. This is where NHI and IAM disciplines intersect with endpoint security: the compromised machine may have accessed human identities, service accounts, or delegated tokens that now need lifecycle review. Practitioners should treat local persistence as a standing access problem, not only as malware cleanup.

Runtime evidence matters because static reputation controls miss the actual abuse path. The article’s process tree shows the attack in motion, from gem require to payload retrieval to daemon launch. That is the kind of evidence security teams need to build detections around execution lineage, not just package names. For identity governance, this means knowing which identities, secrets, and approvals were reachable during the active window, then constraining future exposure with tighter workstation policy.

Secrets management programs need endpoint scope, not just vault scope. The strongest controls around vault rotation and token hygiene still fail if a developer machine can cache or reuse credentials outside the vault boundary. SleeperGem reinforces that secrets governance must include where secrets are consumed, not only where they are stored. Practitioners should treat the workstation as part of the secrets control plane and close the gap between secret issuance and local execution.

From our research:

• 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.
• For a broader identity lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the controls that reduce exposure windows across provisioning, rotation, and offboarding.

What this signals

Developer endpoint security is becoming a first-class identity control. When packages can execute locally and inherit access to tokens, the workstation is no longer just an engineering asset. It is part of the identity plane, and controls such as least privilege, local secret minimisation, and device-level monitoring need to be treated that way. The lesson aligns closely with 52 NHI Breaches Analysis: access paths that look temporary often become the easiest route to durable compromise.

Developer trust gap: the split between CI assurance and endpoint exposure is where supply chain attackers will keep looking. Security teams should assume that a dependency can behave benignly in runners and maliciously on laptops, which means policy must distinguish build environments from human systems. That is a governance problem as much as a detection problem, and it requires tighter linkage between endpoint telemetry, secrets inventories, and identity lifecycle actions.

As supply chain attacks increasingly target runtime behaviour rather than package reputation, teams should prioritise detection of execution lineage, hidden persistence, and outbound contact from build tools. The practical shift is from asking whether a package looks safe to asking which identities and secrets it can touch if it runs.

For practitioners

• 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.
• Add execution-behaviour detection for dependency installs Alert on Ruby processes that spawn child install scripts, disable certificate verification during outbound fetches, or contact unusual hosts during gem require events.
• Baseline developer machine network destinations separately from CI Build distinct allowlists and monitoring baselines for laptops and runners, because malware that skips CI can still activate fully on human endpoints.

Key takeaways

• SleeperGem shows that a malicious package becomes an identity incident when it can reach secrets on a developer machine.
• The strongest evidence in this case is the loader chain, CI evasion, persistence, and the ability to touch local credentials outside the vault boundary.
• Practitioners should treat developer endpoints, persistence artefacts, and reachable secrets as one response scope, not three separate problems.

Key terms

• Loader: A loader is malware whose main job is to retrieve, decrypt, inject, or launch a second-stage payload. In these campaigns, loaders are not the final objective. They are the mechanism that turns an initial click into remote access, persistence, or data theft.
• Persistence: Persistence is the ability to retain memory, state, or goals across sessions and time. In NHI governance, persistence matters because retained context can influence later access decisions, create hidden privilege, and extend the impact of a prior task beyond its intended window.
• Vendor trust gap: A vendor trust gap is the space between assuming an external partner is legitimate and actually verifying that the request is safe. In practice, it appears when business familiarity becomes a substitute for identity validation, especially in finance, procurement, and account-change workflows.
• Secret Exposure Surface: Secret exposure surface is the set of places where credentials can be read, copied, or misused by systems and integrations. It includes environment variables, configuration stores, runtime memory, and connected tools. Reducing the surface means limiting both storage and reachability, not just encrypting data at rest.

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.

👉 The full StepSecurity post covers the kill chain, artifacts, and recovery steps in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps security and identity teams connect lifecycle controls to real-world compromise paths.