Prevent npm and Python Supply Chain Attacks on Developer Machines with Package Configs

What it is

A StepSecurity blog post announcing Package Configs, a feature of their Dev Machine Guard product that audits package-manager configuration across a fleet of developer machines. It is framed against a run of npm/PyPI supply-chain attacks (axios, TanStack, Shai-Hulud, and the self-replicating Miasma npm worm and Hades PyPI worm). Note: despite the catalog summary's emphasis, the page does not discuss .npmrc ignore-scripts or disabling lifecycle scripts — its actual subject is registry configuration, cooldown, and credential exposure.

How it works

The worms spread through the registry itself: once on a machine, they harvest any npm/PyPI publishing token found on disk and republish infected versions of every package that token can publish, making each developer a new launch point. Package Configs inventories config files across global, user, and project scopes — .npmrc, bunfig.toml, .yarnrc/.yarnrc.yml, and pip.conf (covering npm, pnpm, bun, yarn, and pip) — and resolves three things per device:

• Effective registry — where the machine actually resolves packages, accounting for config precedence, flagging any device on the public default rather than an internal Artifactory/Nexus mirror.
• Cooldown — whether a policy holding back newly published versions is in effect; where the package manager is too old to support cooldown, it names what to upgrade.
• Authentication surface — whether registry credentials are hardcoded in a config file versus referenced through an environment variable.

The core insight

Central policy does not guarantee endpoint enforcement. The page names three concrete gaps a dashboard can't see:

1. A project-checked-in .npmrc silently repointing npm to the public registry, taking that machine off the protected path.
2. A device missing cooldown config, or running a package-manager version too old to support it, so new versions install immediately.
3. Registry tokens hardcoded into config files rather than pulled from the environment — exactly what Miasma/Hades harvest.

What to do

The post prescribes defenses rather than commands:

• Route every install through an internal registry / Secure Registry so cooldown, policy, and an audit trail can be enforced on one controlled path.
• Enforce a cooldown policy that holds new versions for a multi-day aging period — the single most effective control here, because most malicious packages are discovered within ~24 hours of publication.
• Reference registry credentials via environment variables, never hardcoded in config on disk.
• Audit project-scope config overrides, not just central policy.

Caveats

This is a vendor product announcement — Package Configs is StepSecurity's paid tooling, and no CLI commands, config snippets, or open detection rules are provided. The actionable content is the threat model and the list of config artifacts/scopes worth auditing yourself; the tooling to do it at fleet scale is the product being sold. Attack dates cited (June 3/5/8) appear in the post without a stated year.