Open a random npm package page on Snyk's site and you'll see a single number between 0 and 100, followed by four smaller labels: Popularity, Maintenance, Community, and Security. The snyk package itself currently scores 89/100 — "Influential Project" popularity (622,790 weekly downloads, 5,605 GitHub stars, 260 contributors), "Healthy" maintenance (a release 13 days ago, a commit 14 hours ago), "Active" community, and no known vulnerabilities in its latest version, 1.1305.2. Contrast that with a package Snyk uses as its own scoring example: 42/100, "Inactive" maintenance because no new version has shipped to PyPI in 12 months, and "Limited" popularity and community because it has a single GitHub star and 10 or fewer contributors. This post breaks down exactly which signals feed each of those four categories, using Snyk's own published methodology, so you know what a health score is actually telling you before you rely on it.
What is Snyk Advisor and what does its health score measure?
Snyk Advisor is a package research tool, originally launched as a standalone product in 2020, that scores open source packages on a 0–100 scale and has since been folded into Snyk's broader package pages on security.snyk.io. The score is a composite of four sub-scores — Popularity, Maintenance, Community, and Security — each shown separately with its own label (like "Healthy," "Inactive," "Influential Project," or "Limited") so a viewer can see which specific dimension is dragging the overall number down rather than trusting one opaque figure. As of mid-2026, package health data is published for three ecosystems: npm, PyPI, and Go, with Snyk stating plans to expand coverage to additional registries over time. The stated goal is to let a developer evaluating a new dependency see adoption, upkeep, and community support in one place instead of manually checking a GitHub repo, a download counter, and a vulnerability database separately.
How does Snyk Advisor calculate the popularity signal?
Popularity is calculated primarily from download volume, using a moving average of downloads over the trailing 12 months that explicitly excludes weekends and known missing-data gaps in registry statistics, smoothing out the kind of single-day spikes that could otherwise misrepresent a package's real adoption. That download average is combined with repository-level signals — GitHub star count, fork count, and contributor count — to place a package into a tier such as "Key ecosystem project," "Influential Project," or "Limited." The snyk npm package's 622,790 weekly downloads, 5,605 stars, and 687 forks land it in the "Influential Project" tier, while a package with a single GitHub star gets flagged "Limited" regardless of how long it's existed. Because downloads are a lagging indicator, a package can carry high popularity for months after its maintainers have effectively stopped working on it — which is exactly why Advisor keeps popularity and maintenance as separate scores instead of merging them.
What counts as "healthy" maintenance versus "inactive"?
A package is scored as having healthy maintenance when it shows a positive release cadence — Snyk's documented threshold is at least one new version shipped in the past three months — combined with ongoing repository activity such as recent commits and issue or pull-request handling. The maintenance check also looks at commit frequency over roughly the trailing six months and the timestamps of the last commit and last release specifically, not just whether a repository exists. The snyk package shows this in practice: a release 13 days ago and a commit 14 hours ago earn it a "Healthy" maintenance label with 22 open pull requests still being actively triaged. On the opposite end, Snyk's own scoring-methodology example package is labeled "Inactive" for a single, specific reason stated on the page: no new version has been released to PyPI in the past 12 months, regardless of how the package scores on popularity. That's a meaningful distinction for supply chain risk — a widely-downloaded package that hasn't cut a release in a year is a different risk profile than one with low downloads but weekly commits.
What community signals does the score track?
Community scoring looks at whether a project shows evidence of more than one person actively engaged with it, starting from a baseline check of at least one pull request or issue that the community has interacted with in a recent window. Beyond that baseline, it factors in contributor count (Snyk's own documentation flags "10 or fewer contributors" as a limited-community signal), the presence of contributor-facing documentation like a README and a CONTRIBUTING.md file, whether a Code of Conduct exists, and whether the project has any funding mechanism in place. The snyk package's 260 contributors and README/Contributing.md documentation earn it an "Active" community label, though the page still notes the absence of a Code of Conduct as a gap. This category is effectively a bus-factor proxy: a package maintained by one person with no contributing guidelines and no outside pull requests is structurally more fragile than one with an active contributor base, even if both currently pass every vulnerability scan.
How do security findings factor into the health score?
Security scoring is based on known vulnerabilities and license issues detected in the package, pulled from Snyk's own vulnerability intelligence rather than from the popularity or maintenance signals. The snyk package illustrates how this is scoped to the current version: Snyk's data shows four total vulnerabilities have existed across the package's full version history, but zero of them affect the latest release (1.1305.2), so the current security label reads "No Known Security Issues" with zero critical, high, medium, or low severity findings in that version. That version-scoping matters for how you read the number — a package can carry historical CVEs and still show a clean security label today, because the score reflects what's shipping now, not the project's entire track record. Security is one of four equally-surfaced categories rather than a single override, which means a package with zero known vulnerabilities can still carry a low overall score if it's abandoned or has a single maintainer with no community backing.
What does the health score not tell you?
The health score doesn't tell you whether a specific version pinned in your lockfile is the one being measured, whether a maintainer account itself is trustworthy, or how a package behaves at install or runtime — because Advisor's inputs are registry metadata, GitHub repository activity, and known-vulnerability databases, not build provenance or behavioral analysis. A package can score well on all four Snyk Advisor categories and still ship a malicious postinstall script in a patch release the day after the score was last computed, since none of the four signals (downloads, release cadence, contributor count, known CVEs) is designed to catch a supply chain attack in near-real time. It's also worth noting the score is computed at the package level, not per-version, so teams evaluating a specific pinned version still need to check what actually changed in that release rather than reading the top-line 0–100 number as a guarantee.
How Safeguard Helps
Package health scores like Snyk Advisor's are a useful first filter for dependency selection, but they're built from lagging, registry-level signals — downloads, stars, commit timestamps — that describe a project's general reputation rather than what's actually inside the artifact your build just pulled down. Safeguard is built to close that gap: instead of scoring a package's overall community health, Safeguard analyzes the actual code changes, install scripts, and behavior introduced in each new version as it publishes, so a maintainer going quiet or a repository losing contributors doesn't have to be the only signal standing between your pipeline and a compromised release. For teams that already use popularity and maintenance signals like Snyk Advisor's to triage which dependencies deserve scrutiny, Safeguard adds the version-level and behavioral layer underneath — catching the specific supply chain attack patterns, like malicious install hooks or unexpected network calls in a patch release, that a health score's four categories aren't designed to detect on their own.