In March 2022, a wave of npm packages with names like discord.js-selfbot-v13 clones and lookalikes of popular libraries were caught exfiltrating Discord tokens and browser credentials before most developers had installed anything. Attacks like this rely on a simple trick: publish a package whose name is one keystroke away from a package millions of developers already trust — crossenv instead of cross-env, pytroch instead of pytorch — and wait for a mistyped npm install or pip install to do the rest. Snyk, one of the most widely deployed software composition analysis (SCA) tools, maintains a dedicated pipeline for catching these packages before they spread, separate from its standard CVE-based vulnerability database. This post walks through how that detection pipeline is publicly documented to work: what it looks for, how it verifies a package is malicious rather than just risky, and where the mechanical limits of that approach sit.
What makes a "malicious package" different from a regular vulnerability in Snyk's database?
Snyk treats malicious packages as a distinct advisory category, separate from CVE-numbered vulnerabilities, because the two have different origins and different fixes. A CVE describes a flaw in legitimate code — a SQL injection bug in a web framework, a buffer overflow in a parser — that a patch can fix. A malicious package is not a good package with a bug; it is intentionally hostile code shipped under a package name, and the only "fix" is removal, not an upgrade. Snyk's public vulnerability database exposes a "Malicious Packages" classification alongside standard severity ratings, and these entries are sourced primarily from Snyk's internal security research team (branded publicly as Snyk Security Labs) rather than from NVD, GitHub Security Advisories, or vendor disclosures. That distinction matters operationally: a scanner that only ingests CVE feeds will never surface a typosquat, because typosquats are rarely assigned CVEs at all.
How does Snyk find typosquatted package names before they spread widely?
Snyk's public write-ups describe a combination of automated name-similarity checks against registry-download rankings and continuous monitoring of new package publications on npm, PyPI, RubyGems, and Maven Central. The core heuristic is straightforward: compute edit distance (commonly Levenshtein distance) and visual/keyboard-proximity similarity between a newly published package name and the names of the most-downloaded packages in that ecosystem, then flag close matches for review. A package named reqeusts published days after requests sees millions of weekly downloads is a textbook candidate. Snyk's research team has published dozens of blog posts documenting specific typosquat campaigns caught this way — including clusters of npm packages typosquatting electron, discord.js, and various crypto-wallet libraries — typically naming the exact lookalike strings and the legitimate package they targeted. This name-similarity signal is a triage filter, not a verdict: most flagged names still require the content-level checks below before Snyk publishes an advisory, since some near-name matches are legitimate forks or unrelated projects.
What does Snyk actually inspect inside a suspicious package before flagging it?
Snyk's documented approach combines static inspection of package contents with behavioral analysis of what the code does when installed or run. On the static side, researchers and tooling look at install-time scripts — the preinstall, install, and postinstall hooks in a package's package.json — because these execute automatically the moment a package is downloaded, without the victim ever importing or running the library's actual code. A postinstall script that reaches out to an unfamiliar domain, decodes a base64 blob, or downloads a second-stage payload is one of the most consistent tells Snyk's published incident reports cite. On the behavioral side, Snyk has described running suspect packages in isolated, instrumented sandbox environments to observe network calls, file-system writes, and environment-variable access at execution time, which catches obfuscated payloads that static string-matching alone would miss. Snyk also weighs package metadata signals surfaced through Snyk Advisor — a very recent publish date, a first-time or newly created maintainer account, near-zero download history, and no corresponding GitHub repository activity — which don't individually prove malice but sharpen which packages get prioritized for deeper manual review.
How does Snyk check whether a published package actually matches its claimed source code?
Snyk's public documentation describes comparing the code shipped in a published package tarball against the source code available in the package's linked repository, looking for discrepancies between what a developer would see on GitHub and what actually gets installed. This matters because a common supply-chain technique is to keep a clean, reviewable GitHub repo while publishing a tampered tarball directly to the registry — reviewers auditing the repo never see the malicious code that ships to users. When Snyk's tooling or researchers find files, scripts, or dependencies present in the published artifact but absent from the linked source, that mismatch is treated as a strong indicator worth manual investigation rather than an automatic verdict, since build steps (bundling, minification, generated files) can legitimately produce differences too. This is one of the more resource-intensive checks in the pipeline, which is part of why Snyk pairs automated diffing with human analyst review before an entry is published as a confirmed malicious-package advisory rather than a "possibly suspicious" flag.
How fast does a Snyk malicious-package finding reach developers scanning their projects?
Once Snyk's research team confirms a package is malicious, the finding is published to the Snyk Vulnerability Database and becomes visible to Snyk Open Source (SCA) customers on their next scan, typically within the same release cycle as the internal confirmation — Snyk has stated publicly that many malicious-package advisories go out within hours to a few days of initial detection, faster than the weeks-to-months timeline common for CVE assignment and NVD publication. Because malicious packages are actively harmful the moment they're installed (unlike a dormant vulnerability that only matters if exploited), Snyk treats time-to-publish for this category as a distinct operational priority from its general vulnerability triage backlog. The tradeoff inherent in this speed is coverage: manual verification of static, behavioral, and provenance signals doesn't scale to the full volume of new packages published daily across npm, PyPI, and other registries, so Snyk's database — like every vendor's — reflects a sampled, prioritized subset of what's actually published, weighted toward packages that are already gaining traction or that closely mimic high-download targets.
How Safeguard Helps
Snyk's malicious-package detection is a well-documented and genuinely useful layer of open-source risk visibility, but it's built around periodic database lookups: a package is either already in Snyk's curated list of confirmed malicious entries, or it isn't flagged. Safeguard is built to close the gap in that model — the window between when a malicious or typosquatted package is first published and when any vendor's research team has manually confirmed and cataloged it. Safeguard continuously analyzes new and updated packages as they land in your dependency graph, applying automated behavioral and provenance checks in real time rather than waiting on a curated advisory feed, so a lookalike package published this morning doesn't have to wait for tomorrow's database update to get flagged. For security and platform teams that already rely on SCA tooling for known-vulnerability coverage, Safeguard adds a continuous, supply-chain-native detection layer purpose-built for the fast-moving, pre-disclosure window where typosquats and malicious publishes do the most damage.