Detect

StepSecurity's Detect capabilities give your organization continuous visibility into NPM dependency usage — across PRs, repositories, and time. This section explains the real scenarios where detection matters and the StepSecurity features that power these workflows.

Scenario 1: A newly disclosed malicious NPM package hits the ecosystem and you need to know everywhere it was used

When a package is declared malicious, every security team asks the same immediate question:

“Where in our organization has this package ever been introduced?”

Manually searching through repositories, branches, and lockfiles is slow, error-prone, and often incomplete.

After the disclosure of the Shai-Hulud: The Second Coming campaign, security teams needed to rapidly determine whether compromised packages used across Zapier, ENS Domains, and other ecosystems had ever been introduced into their repositories. In many cases, exposure was limited to specific PRs or short-lived updates that were not obvious from current dependency state alone.

How StepSecurity detects this

Powered by: NPM Package Search

• Search across all PRs in all repositories

• Identify every PR where the package was introduced

• Understand the blast radius instantly

• Run both custom searches and compromised-package searches

• Search at either the organization or tenant level

Why this matters

• Reduces incident response from hours to minutes

• Ensures complete visibility across all teams and repos

• Prevents missed exposures in large or distributed organizations

Scenario 2: A developer adds or updates a dependency in a PR — and you need to know whether it’s malicious or high-risk

Every dependency update is a potential supply chain entry point. If a package is known malicious, recently weaponized, or flagged by StepSecurity’s intelligence, you need real-time detection before the merge happens.

In the 20 Popular NPM Packages Compromised incident, malicious versions of widely trusted packages like chalk and debug were introduced via normal version bumps in PRs. Without real-time detection at PR time, these changes would have merged unnoticed, even though the package names themselves were already deeply trusted across the ecosystem.

How StepSecurity detects this

Powered by: NPM Package Compromised Updates

• Every PR modifying package.json or lockfiles is evaluated

• Dependency changes are compared against StepSecurity’s real-time compromised package intelligence

• Includes both confirmed malicious packages and packages flagged as high-risk

• If a dependency is unsafe, the PR fails immediately and the developer is notified

Why this matters

• Prevents compromised packages from merging into main

• Gives developers instant clarity while the PR is still open

• Detects threats before CVEs or advisories are published

• Helps maintain consistent dependency hygiene across teams

Scenario 3: You need to understand whether you were exposed in the past even if the dependency has been removed

A malicious package might have been introduced weeks or months ago, merged briefly, and then removed during cleanup. During an incident, you need to answer:

“Were we ever using this dependency? When was it introduced? In which PR?”

Even if the dependency is no longer in your repositories today, the historical introduction event still matters.

During investigations into the Nx build system compromise, teams discovered that the malicious package had been introduced temporarily in some repositories and later removed. Organizations still needed to determine whether CI runs occurred during that exposure window, even though the dependency no longer existed in the current codebase.

How StepSecurity detects this

Powered by: NPM Package Search

• Tracks when and where packages were added through PRs

• Allows you to search historical PR introduction events

• Enables reconstruction of exposure windows

• Works even if the dependency no longer exists in the current codebase

Why this matters

• Essential for forensic investigations

• Enables accurate determination of exposure periods

• Supports compliance and post-incident reporting

Scenario 4: A package appears suspicious before it is officially declared malicious and you want early warning signals

Many supply chain attacks have early behavioral signals long before the security community identifies them:

• Sudden ownership changes

• Unusual publishing activity

• Publisher anomalies

• Strange versioning patterns

• Connections to past malicious campaigns

These are early “smoke signals” that often precede large-scale compromises.

Prior to full disclosure of the Shai-Hulud resurgence, affected packages showed abnormal publishing behavior and ties to previously compromised maintainers. These early indicators appeared before public advisories but were critical for identifying risk ahead of widespread impact.

How StepSecurity detects this

Powered by: StepSecurity Research & Automated Detection Systems

• Ecosystem-wide monitoring surfaces anomalous NPM activity

• Proprietary signals flag suspicious packages early

• StepSecurity intelligence feeds into PR checks and search workflows

• Alerts appear even before public disclosures

Why this matters

• Allows teams to take proactive action

• Helps prevent early-stage adoption of risky dependencies

• Provides visibility into emerging NPM threats at their earliest stage

Scenario 5: You need consistent visibility into dependency usage across many repositories

Organizations with microservices or large engineering teams often struggle to answer:

• Which repos use which dependencies? • Are we using the same package versions everywhere? • Where do we have outdated, drifted, or duplicated dependencies?

During the GhostAction investigation, widespread secret exfiltration across hundreds of repositories highlighted how difficult it was for organizations to quickly understand which repositories shared common tooling, workflows, and dependencies — and therefore shared exposure.

How StepSecurity detects this

Powered by: NPM Package Search

• Aggregates dependency introduction events across all repos

• Provides a unified view of package usage

• Highlights inconsistencies, outdated usage, and hotspots

• Makes cross-repository dependency governance feasible

Why this matters

• Reduces supply chain sprawl

• Improves upgrade planning

• Creates a consistent security posture across services