Trust scores
How the per-source 0–100 trust score is blended from multiple signals, where it shows up, and what each contributor means.
Every tracked source and every lockfile dependency gets a trust score: a single integer from 0 to 100 meant to answer "how comfortable should I be having this in my dependency tree?" It is orthogonal to the per-release risk score: trust is a property of the project, risk is a property of a specific release. A low-risk update from a low-trust source is still a low-trust source.
The score band #
| Band | Meaning |
|---|---|
| 0–39 (Low) | No reputable score available, signs of abandonment, no publisher reputation, or unusually low usage for the ecosystem. Worth reviewing before depending on. |
| 40–69 (Medium) | Plausibly maintained but with notable gaps: older last commit, no Scorecard data, or thin marketplace signals. |
| 70–100 (High) | Well-maintained, popular, and either has a strong OpenSSF Scorecard report or strong marketplace signals (verified publisher, large install base, healthy ratings). Raw GitHub signals alone are not sufficient: when the GitHub composite is the only scored signal the blended score is capped at 69, even if stars and recency would otherwise push it higher. |
How the number is built #
The score is a weighted blend of every reputable signal we can collect for the source. When a signal is missing we don't punish for it: its weight redistributes across the remaining signals, so a project with only a Scorecard report scores the same as it did before blending. The one exception is the GitHub composite: when it is the only scored signal available the result is capped at 69, so a repo with no OpenSSF Scorecard report cannot reach the HIGH band on stars and recency alone. The hover-card breakdown lists every contributing signal so you can see what moved the result.
Signals that contribute #
| Signal | Baseline weight | Where it comes from |
|---|---|---|
| OpenSSF Scorecard | 0.60 | The industry-standard 0–10 supply-chain security score, fetched daily from api.securityscorecards.dev. Scorecard itself updates weekly, so most days the number is unchanged, but daily polling catches the new weekly snapshot within 24 hours. Available for GitHub-backed sources and, via deps.dev, for npm/PyPI/Go/Cargo packages whose upstream repo is on GitHub. |
| GitHub signals | 0.15 | A composite of stars, forks, last-push recency, and the archive flag. Always computed alongside Scorecard for GitHub repos so a popular-but-unscored project still gets credit. When it is the only available signal the blended score is capped at 69 (top of MEDIUM). |
| deps.dev project | 0.10 | Dependent count, license recognition, and last-published recency from Google's deps.dev catalog. Applies to npm/PyPI/crates/Go. |
| Marketplace + AI | 0.65 | For VS Code Marketplace and Open VSX extensions only: install count, ratings, verified-publisher flag, plus the extension manifest, fed to an OpenAI model that synthesises a calibrated 0–100 score. |
| AI assessment | 0.50 | Last resort for sources with no upstream signals (ad-hoc web sources via the AI fallback parser). |
| Vulnerabilities (OSV.dev) | penalty up to −15 | A separate subtractive step rather than a weighted contribution: known active advisories from osv.dev drag the score down (0 vulns = 0, 1–2 = −5, 3–5 = −10, 6+ = −15). The score is floored at 0. |
Primary provenance #
Even though the number is a blend, the badge still labels a primary
provenance: the contributing signal that carried the largest effective
weight. For most GitHub repos that's OpenSSF Scorecard; for registry
packages it's deps.dev (Scorecard); for extensions it's
Marketplace signals + AI. Two sources at score 75 are not equally
trustworthy: one with a Scorecard primary is far more reliable than one
with an AI primary. The hover card surfaces this so you don't have to
assume.
How often it refreshes #
Trust scores are recomputed daily so newly-disclosed OSV advisories and Scorecard / deps.dev updates surface within 24 hours of landing upstream. A background loop sweeps the catalog once an hour, picking up the rows whose 24-hour TTL has lapsed; every refresh forces a re-fetch of all upstreams (no stale Redis hits) so a real change in the underlying data always moves the score. New sources are scored within an hour of being added.
How to use the number #
- Use it as a triage signal, not a verdict. A score of 30 is a prompt to dig in, not a refusal-to-merge. Some niche but legitimate libraries score low because they have no Scorecard data and few stars; the hover card tells you which.
- Cross-reference with the release risk score. The dangerous combination is low trust plus high risk: a poorly-audited source shipping a release with breaking changes. The available upgrades page flags this combination explicitly.
- Inspect the breakdown before trusting a borderline score. A 65 driven mostly by Scorecard with a small OSV penalty is a very different signal from a 65 driven by an AI assessment alone.
Limitations #
- VS Code Marketplace and Open VSX extension trust scores are AI-synthesised; we feed the real install counts and publisher verification flags into the prompt, but the final number reflects an LLM judgement and may shift modestly between recomputations.
- Ad-hoc web sources (the AI fallback parser) have no reliable upstream reputation signals at all; those scores are the least confident in the catalog by design.
- OSV.dev's coverage varies by ecosystem; "no advisories" reflects what OSV knows about, not a guarantee the project is vulnerability-free.
- Trust scoring does not replace a software-composition analysis tool. Combine it with Dependabot, Snyk, Socket, or similar. See how DevUpdate.io compares to a CVE scanner or SCA tool.