How to Use the Patch Priority Leaderboard

Beginner 15 minutes Engineering Managers / Security Engineers / Dev Leads Remediation & Patching

Pick the next dependency to upgrade by reading the leaderboard — KEV-pinned and EPSS≥0.5 ranked, with `+N deps unblocked` badges showing each upgrade's transitive cleanup.

What the Leaderboard Solves

Most teams pick the next upgrade by going down the CVE list, top-CVSS first. That’s wrong in two ways:

  1. CVSS doesn’t tell you about transitive blast radius. Bumping lodash to clear one CVE might unblock 14 transitively-pinned dependencies that were holding back six other CVEs. A different package with a higher CVSS might be a leaf in your dependency graph and clear nothing else.
  2. CVSS doesn’t tell you what’s actually being exploited. A CVSS 9.8 in a library nobody actively targets is lower-priority than a CVSS 7.5 with KEV membership and EPSS ≥ 0.7.

The leaderboard ranks upgrades by risk-cleared-per-merge, walking the full dependency closure. The result is a queue you can hand to a dev team: “do these in order, each one is the highest-impact next move.”

Prerequisites

  • Dependency inventory populated — i.e., packages have flowed through the proxy.
  • Manager role or above to view the overview dashboard.

Step 1: Open the Leaderboard

Two entry points:

  • Dashboard widget: the Patch Priority widget on the overview page (see tutorial 20) shows the top five.
  • Full leaderboard: navigate to Reports → Patch Priority for the full ranked list, with filters and CSV export.
Full Patch Priority leaderboard
The full leaderboard shows every direct dependency that has at least one KEV-pinned or EPSS≥0.5 CVE in its closure

Step 2: Read the Columns

ColumnMeaning
PackageThe direct dependency you would upgrade (not the transitive coordinate that has the CVE — the leaderboard rolls up to the package you actually control)
Current → TargetThe current pinned version and the simulator’s recommended upgrade target
KEV clearedHow many KEV-pinned CVEs in the closure are resolved by this upgrade
EPSS≥0.5 clearedHow many EPSS-elevated CVEs are resolved
+N deps unblockedTransitive dependencies currently pinned to vulnerable versions that this upgrade allows to bump
ScoreComposite score combining KEV count, EPSS sum, transitive multiplier, and a small penalty for major-version jumps
Closure depthHow deep the leaderboard walked to compute this row (default cap 5; configurable via CHAINSAW_PATCH_PRIORITY_DEPTH)

Step 3: Filter and Scope

The full leaderboard supports filters that the dashboard widget does not:

  • Repository — restrict to a single ecosystem (npm only, pip only, …)
  • Client / team — restrict to packages the selected client actively pulls
  • Severity floor — show only rows with at least N KEV CVEs cleared, or EPSS ≥ X
  • Hide same-major — only show rows where the upgrade is patch / minor (defaults off)

The most operationally useful filter is Client / team, because it converts the global leaderboard into “what should this team do this sprint?”. Each team’s leaderboard row count is usually small enough to be a sprint-sized backlog.

Step 4: Read a Row

Click any row to open the simulator (see tutorial 53 for the full walkthrough). The simulator is the second half of the leaderboard’s value: ranking is one thing, but you also want to see the exact CVE list and transitive impact before opening a PR.

Step 5: Tune the Depth Cap

The default closure walk is depth 5. That covers virtually all real-world transitive impact while staying performant. If you have a particularly deep dependency tree (some Java service deployments hit depth 8+), raise the cap:

CHAINSAW_PATCH_PRIORITY_DEPTH=8

Cost is computational, not memory: depth 8 against a 5,000-package inventory takes seconds longer to recompute, which only matters because the leaderboard recomputes every time the inventory changes.

Step 6: Schedule a Cadence

The most successful teams don’t browse the leaderboard ad-hoc. They:

  • Schedule a weekly patch-priority sync (15 minutes, eng leads + security).
  • Walk the top N rows for the week, assign owners, open tickets.
  • The next sync, confirm last week’s are merged and walk the new top N.

The leaderboard is also queryable from the API for inclusion in your existing dashboards:

curl -H "Authorization: Bearer $CHAINSAW_TOKEN" \
     "https://chain305.com/chainproxy/api/leaderboard/patch-priority?limit=10&min_kev=1" \
     | jq '.rows[] | {package, target_version, kev_cleared, deps_unblocked}'

Step 7: Compare to Last Week

The leaderboard exposes a since= query param that returns the delta. This is how you measure progress:

curl -H "Authorization: Bearer $CHAINSAW_TOKEN" \
     "https://chain305.com/chainproxy/api/leaderboard/patch-priority?since=7d" \
     | jq '.delta | {rows_dropped, kev_cleared_total, new_rows}'

rows_dropped is the count of leaderboard entries that fell off because the recommended upgrade landed. new_rows is what showed up because new CVEs were disclosed in your closure. A healthy trend has rows_dropped ≥ new_rows over a multi-week window.

Verification

  1. The leaderboard widget on the overview page shows at least one row (assuming any of your packages have a KEV-pinned or EPSS-elevated CVE in their closure).
  2. Filtering by repository updates the list.
  3. Clicking a row opens the simulator with the same package preselected.
  4. The CSV export downloads with the same rows + columns.