Skip to content

Back to the catalog

Introducing Secure Registry: install-time defense for the npm supply chain - StepSecurity
stepsecurity.ioarticle

Introducing Secure Registry: install-time defense for the npm supply chain - StepSecurity

StepSecurity introduces Secure Registry, a proxy/registry-layer control that inspects and blocks malicious npm packages at install time, aiming to stop supply-chain attacks like malicious postinstall scripts, typosquats, and dependency confusion before they execute in CI/CD or developer environments. It positions itself as a preventive layer complementary to post-hoc scanning, sitting between developers/CI and the npm registry.

TL;DR StepSecurity launches Secure Registry, an install-time gatekeeper to block malicious npm packages before they run.
Open original ↗
Document

What it is

StepSecurity Secure Registry, an authenticated upstream proxy that sits between npm clients (developer laptops, CI runners, artifact managers) and public package registries. It launched with one live control, Cooldown Period, plus two "coming soon" controls (Compromised Packages, Typosquatting Protection). The launch is framed around the Mini Shai-Hulud worm from threat group TeamPCP, which trojanized several @tanstack packages (millions of weekly downloads), stole CI/CD credentials to self-propagate to UiPath, DraftLab and other maintainers, and — notably — shipped with valid SLSA Build Level 3 provenance attestations, the first documented npm worm to produce validly-attested malicious packages.

How it works

You repoint your npm clients / CI / artifact manager at the Secure Registry URL as upstream; install commands don't change, only where requests go. Every metadata request and tarball download is evaluated against enabled controls and logged to the Policy Evaluations log in the StepSecurity dashboard.

The Cooldown Period control blocks packages published within a configurable window. Rather than erroring, it returns a modified metadata response with recent versions stripped out — the client sees only versions older than the window and resolves against those normally, so no client-side changes are needed. The logic is structural: most malicious npm packages are discovered within 24 hours of publication, so a multi-day cooldown pushes the discovery window outside your install window.

The argument for install-time (vs PR-stage) enforcement: PR scanners only see dependency changes that flow through reviewed code and only catch known-bad packages already in a database. Local npm install with floating semver, clean-checkout CI resolution, ad-hoc global installs, and template bootstrapping all bypass PR controls — and Mini Shai-Hulud moved faster than any known-bad database could update.

Preconditions / Affected

Relevant if you install npm packages via CI, developer machines, or an artifact manager and want enforcement outside PR review. Supported integration paths: JFrog Artifactory, Google Artifact Registry, or direct .npmrc configuration.

What to do

  • Point npm clients / CI runners / artifact manager at the Secure Registry URL as upstream (Setup Guide tab, three paths above).
  • Enable Cooldown Period. Default window is 10 days (recommended); it's configurable and can be scoped per ecosystem.
  • Use the Setup Guide's test sequence to confirm requests actually flow through the proxy.
  • Rotate credentials without downtime using the supported primary and secondary API keys.

Caveats

  • Only Cooldown Period is live at launch; Compromised Packages and Typosquatting Protection are "coming soon."
  • Cooldown is time-based, not verdict-based: it delays access to reduce zero-day exposure but does not itself identify malicious packages — that gap is what the not-yet-shipped Compromised Packages control is meant to fill.
  • Cooldown assumes the ~24-hour discovery pattern holds; a shorter configured window narrows protection accordingly.

Technologies named here

Related in Supply Chain