StepSecurity describes two dashboard controls that verify whether CI jobs and developer machines are actually resolving packages from an internal registry instead of falling back to public ones like npm, PyPI, or Docker Hub. Control 1 uses Harden Runner to behaviorally monitor CI job network calls, flagging any job still contacting public registries even if a private one is configured elsewhere. Control 2 uses Dev Machine Guard to read each package manager's config file (.npmrc, pip.conf) on every developer machine, evaluated per device-and-tool pair since a machine can be correctly configured for npm but not pip. The piece cites the axios, litellm, and @bitwarden/cli compromises as motivation, arguing developer machines are an increasingly common attack entry point since installs there bypass PR review. Recommended enforcement pairs network-level egress blocking in CI with centrally deployed registry configs on developer machines, plus download-time policies (cooldown periods, compromised package blocking, typosquatting protection) at a registry proxy like StepSecurity Secure Registry.
Table of contents
Everyone is on the same journeyDeclaring the migration is easy. Proving it is hard.Control 1: Jobs should use a secure registry instead of public package registriesControl 2: Developer machines should use a secure registry instead of public package registriesWhy both controls, and not just oneVisibility is step one. Then you enforce.Track the migration, not just the incidentsQuestions this post answers
How was the @bitwarden/cli npm package compromised?
A republished version of @bitwarden/cli on npm ran a credential stealer on the developer machine that performed the install, harvesting SSH keys, cloud credentials, and GitHub tokens. Those stolen GitHub tokens were then used to inject malicious workflows into CI pipelines, showing how a developer-machine compromise can escalate into a CI/CD attack. Teams hardening their supply chain against npm-borne attacks can track incidents like this one on daily.dev.
What malicious code was found in the litellm PyPI package?
Two litellm releases published on PyPI carried an identical credential stealer, hidden using two different techniques inside the published wheel files rather than in visible source code. Because the malicious code was embedded in the built wheel artifact, standard repository source-code scanning had nothing to inspect, letting the credential stealer slip past typical review. Developers vetting Python dependencies for hidden risks follow package security incidents like this on daily.dev.
Why isn't blocking public registries in CI enough to stop supply chain attacks?
Blocking public registries only in CI misses developer machines, which are increasingly the actual entry point for attacks. The @bitwarden/cli compromise ran its credential stealer during an install on a developer machine, then used the stolen GitHub tokens to attack CI pipelines directly, meaning a secured CI pipeline behind an unsecured developer machine is still exposed. Engineers designing supply-chain defenses across CI and local dev environments compare approaches like this on daily.dev.