Every team carries a backlog of upgrades it means to get to. The list is easy to make and hard to act on, because sorting by how far behind a package is tells you nothing about how much it matters. A dependency five major versions back might be harmless. The one that is a single patch behind might carry a flaw that attackers are exploiting today.
vg fix answers the question the list can't: which upgrade should you do first? It reads your drift — the gap between the versions you run and the latest stable releases — and returns three ranked upgrade plans, scored on real-world exploitability.
The problem with "just upgrade everything"
Upgrading everything at once is how you turn a quiet afternoon into a three-day firefight. A blanket bump pulls in breaking changes you didn't need, on packages that were never a risk, all to reach a version nobody asked for. So teams do the opposite — they wait — and the risk that mattered sits untouched next to forty that didn't.
The missing piece is prioritisation you can trust. Not "newest first" and not "most versions behind," but most dangerous, given what is actually happening in the wild.
Three plans, ranked by risk
Run the planner at the root of your project:
$ vg fix
Vibgrate fix — upgrade plan
12 drifted dependencies analysed
⚠ 2 packages carry a KNOWN-EXPLOITED (KEV) advisory, peak EPSS 74% — prioritise these.
● recommended Low-risk — patch and minor updates only
risk 12/100 low · 5 upgrades · fixes 1 critical, 2 high · DriftScore 58 → 54
lodash 4.17.19 → 4.17.21 closes a prototype-pollution advisory
○ Full — everything to latest stable
risk 58/100 high · 12 upgrades · DriftScore 58 → 31Each plan is a real, ordered set of upgrades with a risk score, the number of advisories it closes, and the DriftScore — our 0–100 measure of how far your stack has drifted — you would land on. You pick the trade-off: the Low-risk plan clears the urgent advisories with patch and minor bumps, while Full takes you all the way to the latest stable at the cost of more churn.
Exploitability, not just severity
Most tools stop at severity. A CVSS score of 9.8 looks alarming, but severity describes the worst case — it doesn't tell you whether anyone has ever exploited the flaw. vg fix layers two public signals on top of the advisory data so the ranking reflects reality, not just theory:
- CISA KEV — the Known Exploited Vulnerabilities catalog. If a flaw is on this list, it is being exploited in the wild. That is the strongest possible reason to move it to the front.
- FIRST EPSS — the Exploit Prediction Scoring System, a probability that a vulnerability will be exploited in the near term.
A package that is on KEV with a high EPSS score outranks a higher-CVSS flaw that no one has ever weaponised. That is the difference between a queue sorted by fear and a queue sorted by evidence.
It re-scans so the plan matches your tree
A plan built from a stale scan is worse than no plan. If a manifest or lockfile has changed since your last scan, vg fix notices and re-runs the drift scan first, so the recommendations describe the code you have right now — not the code you had last week.
$ vg fix
Scan is out of date (package-lock.json changed since the last scan) —
re-running a drift scan first…Read-only by default — you decide when to apply
vg fix plans; it does not touch your project unless you tell it to. Every state-changing action goes through an explicit choice, never a quiet auto-apply. To print the plans and stop, pass --no-apply. To preview the exact changes without writing them, use --dry-run. When you are ready, apply a specific tier non-interactively:
# Preview only — never edits the project
$ vg fix --no-apply
# Apply the low-risk plan without prompting
$ vg fix --plan safe --yesThe plan tiers are safe, balanced, and aggressive; applying one runs your project's own package manager to make the changes. Drift scoring and the code map are free. The ranked planner is a hosted capability, so vg fix needs a login — run vg login once, or set a VIBGRATE_DSN. It reads only your dependency versions and aggregate usage signals; it never uploads your source.
Wire it into CI
vg fix earns its place in a pipeline with one flag. --fail-on-vulns exits non-zero when the recommended plan would still leave an advisory at or above the severity you name — so a pull request can't merge while a known-exploited flaw goes unaddressed:
$ vg fix --no-apply --fail-on-vulns highTry it
Point it at any project you own:
$ vg login
$ vg fixPrefer to read the flags first? The vg fix command reference lists every option, and Drift is your next CVE explains why staying current is a security control, not just hygiene. To see the free drift scoring that feeds the planner, start at the Vibgrate CLI page.