Trust scoring & maintainer-change alerts
Some supply-chain attacks have no CVE — a maintainer's credentials are compromised and a malicious version ships before anyone notices. Trust scoring targets that gap: it scores each package version on signals of continuity and risk, and can block when the score drops sharply versus the last version you approved.
Roadmap capability
Trust scoring is on the roadmap. The signals below describe the model; check your build for current availability. The rest of the firewall (policy, modes, signed bypass) is generally available today.
What the score considers
| Signal | Why it matters |
|---|---|
| Maintainer continuity | A new or changed publisher on an established package is the classic takeover signature. |
| Release cadence | A sudden release after long dormancy, or an out-of-pattern burst, is suspicious. |
| Install-script presence | Newly-added postinstall/build hooks are a common malware delivery vector. |
| Download / dependency anomalies | Unusual download patterns or dependency changes versus the prior version. |
| Package health | Maintainer count, license clarity, and historical vuln record (shared with dependency health scoring). |
How it gates
Rather than an absolute threshold, the rule compares a candidate version against the last approvedversion of the same package. A significant drop — e.g. maintainer change + new install script — triggers a block, even with no CVE assigned.
Tuning
- Per-ecosystem thresholds — npm’s install-script risk differs from Maven’s.
- Cooldown windows — optionally hold brand-new versions for a soak period before allowing.
- Allowlist — legitimate major rewrites / ownership transfers can be pre-approved so they don’t trip the rule.
What it targets
The incident class here is maintainer-credential compromise and dependency hijack (the ua-parser-js and event-stream style events) — attacks that ship before any advisory exists.