# 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 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](https://www.stepsecurity.io/blog/20-popular-npm-packages-compromised-chalk-debug-strip-ansi-color-convert-wrap-ansi), 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: [**Package Cooldown**](/github-checks/configuration.md#package-cooldown) * Newly published 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 * Runs as separate **npm Package Cooldown** and **PyPI Package Cooldown** checks, so you can apply different cooldown windows per ecosystem ### Why this matters * Most malicious 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 registry account, publish a malicious update, and developers unknowingly adopt it. This is one of the most damaging supply chain attack paths and affects both npm and PyPI maintainers. During the [*Shai-Hulud: The Second Coming* campaign](https://www.stepsecurity.io/blog/sha1-hulud-the-second-coming-zapier-ens-domains-and-other-prominent-npm-packages-compromised), 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: [**Package Compromised Updates**](/github-checks/configuration.md#package-compromised-updates) * StepSecurity's SOC continuously monitors the npm and PyPI ecosystems and maintains a real-time database of known malicious and high-risk 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 * Runs as separate **npm Package Compromised Updates** and **PyPI Package Compromised Updates** checks ### 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 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. This applies to npm `preinstall` and `postinstall` hooks, and to PyPI packages that execute code during `pip install` (for example, via `setup.py`). In the [*Nx build system compromise*](https://www.stepsecurity.io/blog/supply-chain-security-alert-popular-nx-build-system-package-compromised-with-data-stealing-malware), 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/workflow-runs.md#filter-outbound-network-traffic-to-allowed-endpoints) * 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.stepsecurity.io/oss-supply-chain-security/prevent.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.