Prevent

StepSecurity's Prevent controls stop malicious or high-risk NPM dependencies from entering your codebase or executing inside CI/CD pipelines. This page explains the real attack scenarios organizations face and how StepSecurity prevents them — with clear references to the features powering each defense.

Scenario 1: A malicious NPM package is published and developers unknowingly try to adopt it

Attackers frequently publish malicious packages or hijacked versions and rely on the early hours before the community detects the compromise. Most victims install the malicious version within the first day.

In the 20 Popular NPM Packages Compromised incident, attackers published malicious versions of widely trusted packages such as chalk, debug, strip-ansi, color-convert, and wrap-ansi. These versions were quickly pulled into downstream projects because they appeared to be legitimate updates to well-known dependencies, exposing thousands of repositories before detection.

How StepSecurity prevents this

Powered by: NPM Package Cooldown

• Newly published NPM packages are temporarily blocked during a configurable cooldown window

• Any PR introducing or updating to a version published too recently fails automatically

• After the package ages past the cooldown period, the PR passes without requiring changes

Why this matters

• Most malicious NPM packages are discovered within 24 hours

• Cooldown minimizes exposure to zero-day dependency attacks

• Teams stay agile while gaining a crucial safety buffer

Scenario 2: A maintainer’s account is compromised and a trusted package receives a malicious update

In many real-world incidents, attackers take over a maintainer’s NPM account, publish a malicious update, and developers unknowingly adopt it. This is one of the most damaging supply chain attack paths.

During the Shai-Hulud: The Second Coming campaign, attackers compromised maintainer credentials and published malicious updates to trusted NPM packages used across ecosystems such as Zapier, ENS Domains, and others. The malicious code executed during installation and harvested developer and CI/CD credentials, despite the packages retaining their original names and reputations.

How StepSecurity prevents this

Powered by: NPM Package Compromised Updates

• StepSecurity maintains a real-time database of known malicious and high-risk NPM packages

• This database updates continuously, often ahead of official CVEs or advisories

• If a PR attempts to introduce or upgrade to a compromised package, the PR check fails

• The merge is blocked until the dependency is removed or replaced

Why this matters

• Prevents compromised versions from entering your codebase

• Reacts faster than traditional vulnerability scanners

• Stops hijacked-maintainer attacks at the exact moment of risk

Scenario 3: A malicious package attempts to exfiltrate secrets during npm install in CI/CD

Malicious packages often try to exfiltrate CI/CD secrets during install steps by calling out to attacker-controlled domains or embedding data in DNS lookups.

In the Nx build system compromise, malicious code embedded in the package attempted to steal sensitive data during execution. Similarly, the GhostAction campaign demonstrated how attackers exfiltrated thousands of secrets by making outbound network calls from CI/CD workflows, including during dependency installation and build steps.

How StepSecurity prevents this

Powered by: Harden-Runner Egress Network Restrictions

• Harden-Runner filters outbound network traffic during workflow execution

• Only explicitly allowed endpoints can be contacted; everything else is blocked

• DNS-level and network-level enforcement prevents covert exfiltration channels

• Recommended allowlists are generated based on observed workflow behavior

Why this matters

• Protects GitHub tokens, cloud credentials, and environment variables

• Blocks malicious runtime behavior even when the package is newly published and not yet flagged

• Prevents attackers from establishing command-and-control channels