Three scores, one decision: how Vibgrate measures drift and risk

Three numbers, one decision

Most tools give you a wall of findings. Vibgrate gives you three numbers, because three is what it takes to answer the two questions engineering leaders actually ask — how far behind are we? and how exposed are we right now? — and then turn both into a single call on whether to act.

• DriftScore measures maintainability: how far your runtimes, frameworks, and dependencies have drifted from current, supported baselines. 0 is fully current; 100 is maximally drifted.
• RiskScore measures security and business exposure: known-exploited and likely-exploited vulnerabilities, end-of-life runtimes, weighted by how business-critical the code is. Higher is worse.
• DriftRisk™ is the headline that blends the two into one pressure-to-act number — always shown next to the two scores it comes from.

They are deliberately separate. A stale package with no known vulnerability is drift, not an emergency. A current package with an actively-exploited CVE is an emergency, not drift. Collapsing those into one number hides exactly the distinction you need.

DriftScore: drift measured in time, not just versions

"Two major versions behind" means something very different for a package that ships yearly than for one that ships weekly. So DriftScore's dependency signal is built on the libyear — the calendar time between the version you run and the latest stable release (Cox et al., ICSE 2015). Time is comparable across ecosystems in a way that version counts are not.

Each dependency blends time distance and version distance, with floors that cannot be averaged away: an end-of-life major floors the dependency's drift, and the portfolio aggregate keeps a 95th-percentile term so one eight-year-old transitive dependency does not vanish behind hundreds of fresh ones. Every score is stamped Verified (release-date data available) or Estimated (version-only), and carries the commit and snapshot date it was computed from.

Run it yourself — no account, nothing uploaded:

npx @vibgrate/cli scan

Post-install, a bare vg scans the current directory.

RiskScore: exploitation-aware, not severity-only

RiskScore follows the modern prioritisation consensus — CISA KEV, then EPSS, then business context. Severity comes from CVSS, likelihood from EPSS, and membership in CISA's Known Exploited Vulnerabilities catalog overrides likelihood to "actively exploited" and floors the score high. End-of-life runtimes and deprecated packages add exposure; a business-criticality weight makes the same CVE matter more in a payment service than in an internal demo. Independent findings combine so that many small issues never outweigh a single actively-exploited one.

DriftRisk™: one number for how hard to act

DriftRisk blends the two axes and adds one correction that matters more than the weights: an actively-exploited vulnerability is never washed out by a current stack. If RiskScore is critical, DriftRisk is high — full stop — even when your upgrade debt is low. That is the difference between a headline you can trust and one that lulls you.

The formulas, bands, and worked examples are published in full. DriftRisk™ is a trademark of Vibgrate, but the algorithm is open source — the name is protected, the method is not. DriftScore and RiskScore are not trademarked at all.

The point of three numbers is a faster decision: know how far behind you are, how exposed you are, and how hard to act — before you approve the next sprint.