This document defines the scoring methodology used by Commit to assess structural trust in open-source packages and repositories. Every weight, threshold, and flag is published here. Scores are reproducible from public data.
We score the container, not the contents. Commit does not analyze source code, scan for malware, or check for known CVEs. It measures the structural conditions that make a package a high-value target — or a resilient dependency.
The goal is to identify targets before compromise, not to detect active attacks. A sole maintainer controlling 100M weekly downloads is a structural risk regardless of whether an attack has occurred.
Commit operates on different data than Snyk, Socket, or npm audit. Those tools detect known vulnerabilities and malicious code. Commit maps the structural conditions that produce the next vulnerability. Use both.
Every weight and threshold is published in this specification. All input data comes from public APIs (npm registry, PyPI, GitHub). Given the same input data, the same score must be produced.
Badges, certifications, and self-reported security practices are excluded. Only observable, verifiable behavioral signals are scored. A package that claims best practices but has one maintainer and no releases in two years is scored on the latter.
Package scores range from 0–100. Five dimensions are evaluated independently, then summed. The score reflects structural trust — the degree to which the package's maintenance structure is resilient to single points of failure.
Time is a cost signal. A package that has existed for six years has survived shifts in ecosystem preference, maintainer fatigue, and the natural decay of abandoned projects. Longevity is the strongest Lindy indicator available from registry metadata.
| Package age | Points |
|---|---|
| ≥ 6 years | 25 |
| 4–6 years | 20 |
| 2–4 years | 14 |
| 1–2 years | 8 |
| 0.5–1 year | 4 |
| < 6 months | 1 |
Download volume measures ecosystem adoption. But absolute count alone rewards incumbency. Download Momentum combines volume with a 90-day trend analysis — rewarding growing adoption and penalizing decline. The trajectory matters as much as the snapshot.
Base score is determined by weekly download volume (npm) or daily downloads (PyPI). A trend modifier of ±3 points is then applied based on the 90-day trajectory. Trend is computed by comparing the first 45 days to the last 45 days: growing if ratio > 1.15, declining if < 0.85, stable otherwise. Final score is clamped to 0–25.
| Volume | Base |
|---|---|
| ≥ 1,000,000 | 22 |
| ≥ 100,000 | 18 |
| ≥ 10,000 | 14 |
| ≥ 1,000 | 10 |
| ≥ 100 | 6 |
| ≥ 10 | 3 |
| < 10 | 0 |
| Volume | Base |
|---|---|
| ≥ 5,000,000 | 22 |
| ≥ 500,000 | 18 |
| ≥ 50,000 | 14 |
| ≥ 5,000 | 10 |
| ≥ 500 | 6 |
| ≥ 50 | 3 |
| < 50 | 0 |
A healthy package publishes regularly. Total version count demonstrates sustained investment over time. Recency of the last publish signals whether the project is actively maintained or dormant.
| Versions | Base |
|---|---|
| ≥ 100 | 15 |
| ≥ 30 | 12 |
| ≥ 10 | 9 |
| ≥ 3 | 6 |
| ≥ 1 | 3 |
| Last publish | Bonus |
|---|---|
| < 30 days | +5 |
| 30–90 days | +3 |
| 90–365 days | +1 |
| > 365 days | 0 |
Final score is clamped to 0–20.
Credential concentration is the single strongest structural risk signal in package ecosystems. A sole maintainer is not a quality judgment — it means one set of credentials controls all publish access. The more maintainers, the more organizational resilience. This dimension measures bus factor and credential distribution.
| Maintainers | Points |
|---|---|
| ≥ 5 | 15 |
| 3–5 | 11 |
| 2 | 7 |
| 1 | 4 |
| 0 | 0 |
When a package links to a GitHub repository, that repository provides independent signals about project health: contributor count, commit activity, release cadence, and community engagement. This dimension maps the linked repository's commitment score (0–100) to a 0–15 range.
github_backing = (github_repo_score / 100) × 15 If no linked repository: 0 points Risk flags operate independently of the numerical score. A package can score 89/100 and still carry a CRITICAL flag. This is by design: a high score means the package is well-established and widely adopted. A CRITICAL flag means one credential controls that entire surface area. Both statements are true simultaneously.
Maximum credential concentration at catastrophic blast radius. One compromised account affects the entire downstream dependency tree at infrastructure scale.
Historical validation: axios (WAVESHAPER.V2, March 31 2026), event-stream (2018), ua-parser-js (2021). Each was a sole-maintainer package with massive download volume. The structural signal was visible for years before the attack.
Elevated structural risk. Either rapid adoption without time-tested stability, or significant credential concentration at meaningful scale.
The package has not published a new version in over one year. This may indicate abandonment, or may indicate a mature, stable library. Context matters. The flag ensures the condition is visible.
When a package links to a GitHub repository, or when a repository is assessed directly, a separate scoring model applies. The dimensions differ from package scoring because the available signals differ.
| Repository age | Points |
|---|---|
| ≥ 5 years | 30 |
| 3–5 years | 22 |
| 1–3 years | 14 |
| 0.5–1 year | 7 |
| < 6 months | 2 |
Commits in the last 30 days. A direct measure of active development.
| Commits (30 days) | Points |
|---|---|
| ≥ 50 | 25 |
| ≥ 20 | 20 |
| ≥ 6 | 15 |
| ≥ 1 | 8 |
| 0 | 0 |
Contributor count. More contributors means distributed knowledge, review capacity, and reduced bus factor.
| Contributors | Points |
|---|---|
| ≥ 20 | 20 |
| ≥ 6 | 15 |
| ≥ 2 | 10 |
| 1 | 5 |
Stable (non-prerelease) releases among the most recent 10. Regular releases indicate active maintenance and a commitment to shipping.
| Stable releases | Points |
|---|---|
| ≥ 10 | 15 |
| ≥ 3 | 10 |
| ≥ 1 | 5 |
| 0 | 0 |
Stargazer count. An imperfect but broadly available signal of ecosystem recognition. Weighted lowest because stars are gameable and noisy.
| Stars | Points |
|---|---|
| ≥ 10,000 | 10 |
| ≥ 1,000 | 8 |
| ≥ 100 | 5 |
| ≥ 10 | 2 |
| < 10 | 0 |
If a repository is archived or has had no push events in 730+ days, the final score is multiplied by 0.5. This reflects terminal maintenance risk.
Numerical scores are mapped to four tiers for quick interpretation. These tiers are consistent across all ecosystem types (npm, PyPI, GitHub).
Well-established, actively maintained, multiple maintainers or strong organizational backing. Low structural risk.
Adequate maintenance signals but with structural gaps. Review the specific dimension breakdown before depending on this package.
Multiple structural concerns. Consider alternatives or evaluate whether the risk is acceptable for your use case.
High structural risk across multiple dimensions. The package may be abandoned, very new, or unmaintained.
SVG badges served at /api/badge/:ecosystem/:package use these colors:
Three packages that illustrate why score and risk flags are independent signals. Data as of April 2026.
No scoring model is complete. These are the known limitations of the current methodology. Acknowledging them is a feature, not a caveat.
The dimension weights (25/25/20/15/15) reflect expert judgment about which structural signals correlate most with supply chain risk. They are not the output of a regression model trained on historical attack data. Such a model would require a comprehensive labeled dataset of supply chain compromises that does not exist at sufficient scale. The weights are defensible, not proven.
Commit does not assess test coverage, code complexity, documentation quality, or architectural soundness. A well-structured package with zero tests and a chaotic package with comprehensive coverage receive the same score if their structural signals are identical.
Maintainer count is taken from registry metadata. Whether those accounts represent distinct individuals, or whether they have appropriate access controls (2FA, hardware keys), is not checked. A package with 5 maintainers where all 5 share one person's email alias would score the same as one with 5 independent maintainers.
A package at 999,999 weekly downloads scores 18 on momentum; at 1,000,000 it scores 22. This discrete jump does not reflect a real-world discontinuity. Continuous scoring functions would be smoother but harder to audit and reproduce. We chose transparency over precision.
Whether a package uses signed releases, requires 2FA for publishers, or has a security policy is not measured. These are important signals, but they are declarations (gameable), not behaviors (observable). Future versions may incorporate signals that bridge this gap.
v1.0.0 covers npm, PyPI, and GitHub repositories. Cargo, Go modules, Maven, and other ecosystems are not yet supported. Each ecosystem requires calibrated download thresholds and registry-specific metadata handling.
This specification follows Semantic Versioning.
Paste your dependencies. Get structural trust scores for your entire tree.