function scoreLongevity(ageYears: number): number {
if (ageYears >= 6) return 25;
if (ageYears >= 4) return 20;
if (ageYears >= 2) return 14;
if (ageYears >= 1) return 8;
if (ageYears >= 0.5) return 4;
return 1;
}

function scoreDownloads(
weeklyAvg: number,
trend: "growing" | "stable" | "declining" | null
): number {
let base = 0;
if (weeklyAvg >= 1_000_000) base = 22;
else if (weeklyAvg >= 100_000) base = 18;
else if (weeklyAvg >= 10_000) base = 14;
else if (weeklyAvg >= 1_000) base = 10;
else if (weeklyAvg >= 100) base = 6;
else base = 3;

const trendMod = trend === "growing" ? 3 : trend === "declining" ? -3 : 0;
return Math.max(0, Math.min(25, base + trendMod));
}

A sole maintainer scores 4/15 — the lowest non-zero value. The reasoning is
structural: one compromised npm token means a malicious version goes to every
downstream install. One phishing email, one credential leak, one maintainer
account selling their package — and the blast radius is the full weekly download
count.


### 5. GitHub Backing (15 pts)


If the package has a linked GitHub repository, we score that repository independently
across five sub-dimensions: longevity, recent commit activity (last 30 days),
contributor count, release cadence, and stars. The resulting 0–100 GitHub score
maps linearly to 0–15 points.


Organization-backed repos score higher than personal repos for the same reason:
organizational accounts have multiple people with access, institutional continuity,
and usually internal security practices. A personal repo is one account away from
full control by whoever compromises it.


## The CRITICAL Flag


The flag has two conditions, both must be true:


1. Single maintainer (`maintainerDepth = 4/15`)
2. Weekly downloads > 10M

The threshold is explicit and deterministic. You can reproduce it from the npm
registry and downloads API with no proprietary data. The reasoning behind 10M:
below that volume, a compromised package causes real damage but doesn't constitute
an infrastructure-level event. Above it, the blast radius is broad enough that
a well-resourced attacker has a meaningful incentive.


Two additional flags exist for adjacent risk profiles:


- **HIGH**: package 1M weekly downloads — rapid adoption without operational track record.
- **WARN**: package hasn't published in >365 days — likely unmaintained but still receiving traffic.


## How the Audit API Works


The `POST /api/audit` endpoint takes a list of package names and returns
scored profiles. The naive implementation — firing one download API request per package
concurrently — hits a documented npm rate limit: parallel requests to the downloads
API return zeros. This was the first failure mode we hit in production.


The fix: batch all unscoped packages into a single bulk request before processing.

The bulk API (`/downloads/point/last-week`) accepts up to 128 packages
per request and returns a map of package → weekly count. Scoped packages
(`@scope/name`) are not supported by the bulk endpoint — they fall back
to individual fetches.


The registry metadata fetch and GitHub scoring run concurrently per package.
For a 20-package audit, this is roughly: 1 bulk download request + 20 registry
requests + up to 20 GitHub requests, all in parallel. Wall-clock time on cold
CF Workers: typically 800ms–1.5s depending on GitHub API latency.


## Benchmarks: Real Packages, Live Data


Actual response from the live API (April 29, 2026):

| Package | Score | Maintainers | Weekly DL | Age | Last Publish | Risk |
| --- | --- | --- | --- | --- | --- | --- |
| `chalk` | 75 | 1 | 418M | 12.7 yr | 181 days ago | 🔴 CRITICAL |
| `hono` | 79 | 1 | 34.5M | 4.4 yr | 4 days ago | 🔴 CRITICAL |
| `express` | 94 | 5 | 95M | 15.3 yr | 12 days ago | ✅ No flag |


Score breakdowns:

chalk and hono both score in the 75–80 range and look reasonably healthy by
conventional package health metrics. Both are CRITICAL. The difference with
express is one number: 5 maintainers vs. 1.


## What This Doesn't Cover


**Code analysis.** Proof-of-commitment doesn't inspect package
contents. Socket.dev does this — static analysis of published code for
suspicious patterns. These are complementary layers, not competitors.
If you want to catch malicious code after it's been published, Socket.dev
is the right tool. If you want to identify packages structurally positioned
for compromise before any malicious code exists, use Commit.


**CVE tracking.** npm audit, Snyk, and Dependabot scan for known
vulnerabilities. Commit doesn't duplicate this. Both layers serve different
threat models: known CVEs (catalogued, after-the-fact) vs. structural exposure
(predictive, before-the-fact).


**Trajectory, not snapshot.** The current implementation scores
the current state of a package. A package that had 5 maintainers for 10 years
and just dropped to 1 gets the same maintainerDepth score as one that's always
had a single maintainer. This is a known gap — the score should track transitions,
not just current state.


**CRITICAL packages that never get attacked will always outnumber
the ones that do.** The flag identifies exposure, not certainty.
Most sole-maintained packages with 100M weekly downloads are run by talented,
security-conscious people. The risk is structural, not behavioral.


## Run It On Your Stack


CLI:

API (replace with your packages):

Browser: [getcommit.dev/audit](https://getcommit.dev/audit)


The source is at [github.com/piiiico/proof-of-commitment](https://github.com/piiiico/proof-of-commitment).
The scoring functions are in `src/backend/npm.ts`. The audit endpoint
is in `src/backend/worker.ts`.


---


*Related: How Commit Scores npm Packages: The Methodology — the reasoning behind the weights. Why npm audit Returns Zero Vulnerabilities for the Most Dangerous Packages — where each tool fits in the stack. Two Types of npm Supply Chain Attack — what each tool actually covers.*