It's Monday morning. Your security team discovers that a widely-used npm package in your tech stack was compromised over the weekend. The package appeared in multiple repositories, introduced through various pull requests over the past few months. Now the critical questions:
Which repositories are affected? Who added this package and when? What's the actual blast radius?
For most teams, answering these questions means manually searching through repositories, checking package.json files, reviewing Git history, and piecing together a timeline. Hours tick by while the scope remains uncertain.
This is the current reality of incident response in modern software development.
The npm Supply Chain Attack Problem
The frequency and sophistication of npm supply chain attacks have escalated dramatically. In September 2025 alone, the JavaScript ecosystem faced multiple high-impact incidents:
The Shai-Hulud Worm compromised over 500 npm packages through a self-replicating attack that automatically infected downstream packages. The worm stole cloud credentials, GitHub tokens, and npm publishing keys, then used those credentials to propagate further across the ecosystem.
The Singularity compromise in September 2025 targeted the popular Nx build system, which is used by thousands of organizations to manage JavaScript and TypeScript monorepos. A malicious version of the @nx/singularity package was published to npm, containing data-stealing malware designed to exfiltrate tokens and credentials from developer environments.
The eslint-config-prettier attack in July 2025 compromised a package with over 30 million weekly downloads, delivering the Scavenger infostealer malware through modified install scripts.
Each incident followed the same pattern: compromised maintainer credentials, malicious package versions published to the registry, and organizations scrambling to determine where they were exposed. The challenge isn't just detecting that a package is compromised – it's understanding where that package exists in your codebase and how it got there.
Introducing NPM Package Search
Today, we're excited to announce NPM Package Search, a new capability within StepSecurity's Artifact Security suite that gives you instant visibility into where any npm package was introduced across your organization.
NPM Package Search allows you to search for npm packages that were added in pull requests across your GitHub organizations, tracking them to the exact PR where they were introduced. When a package is discovered to be compromised or vulnerable, you can immediately identify all affected pull requests, understand the blast radius across repositories, and take targeted remediation steps.
This isn't just another dependency scanner, NPM Package Search answers a fundamentally different question: not "what packages do I have right now?" but "when and how did this package enter my codebase?"
How NPM Package Search Differs from Traditional SCA Tools
Most Software Composition Analysis (SCA) solutions focus on the current state of your dependencies — what’s present in your repositories today. NPM Package Search goes a step further by showing the full history of how each dependency entered and evolved within your organization’s codebase.
With NPM Package Search, you can:
- Search across pull requests, not just manifests: Instantly find the exact PRs where a package was introduced or modified, providing context that SCA tools miss.
- Track package lifecycle changes: Even if a dependency was later removed or replaced, you’ll know precisely when it was added, by whom, and for how long it existed in your repositories.
- Correlate developer activity: When a compromised package is identified, you can immediately see which developer introduced it, making it easier to assess potential compromise of developer machines or credentials and accelerate incident response.
How NPM Package Search Works
Explore this interactive demo to see how NPM Package Search can work in your organization
Real-World Use Cases
Incident Response
When the Shai-Hulud worm was discovered, affected organizations needed to immediately determine if any of the 500+ compromised packages had entered their codebases. With NPM Package Search, security teams could query for specific package versions, instantly see every PR where they were added, identify who introduced them, and trace the timeline of exposure across repositories.
Instead of spending hours manually auditing repositories, teams get comprehensive results in seconds, enabling rapid response and containment.
Dependency Auditing
Beyond reactive incident response, NPM Package Search enables proactive security practices. Security teams can periodically search for deprecated packages, packages with known vulnerabilities, or packages that violate organizational policy. The PR-level visibility shows exactly where non-compliant packages exist and provides the context needed to understand why they were introduced.
Blast Radius Assessment
When a vulnerability is disclosed in a popular package, understanding exposure is critical for prioritization. NPM Package Search shows not just which repositories use the package, but how widely it's distributed across your organization. If a package appears in dozens of repositories through automated dependency updates, you know you have a significant remediation effort. If it only exists in one experimental PR that was never merged, the urgency is lower.
Get Started
The npm ecosystem moves fast, and so do the threats targeting it. When the next supply chain attack hits – and it will – you need to know immediately if you're affected and where.
NPM Package Search transforms incident response from hours of manual investigation into seconds of targeted queries. It turns the question "are we exposed?" from a research project into a definitive answer.
For detailed setup instructions and a complete walkthrough of NPM Package Search capabilities, visit the documentation.
Ready to see it in action? Start your free trial and gain instant visibility into your npm package landscape.
.png)
