Skip to content
Back to Maintenance & LTS

Patch Priority

Rank patches by severity and exploitability so critical fixes ship first and cosmetic ones wait.

Why

Not all patches are equal, and treating them as equal means either shipping every patch as an emergency (burnout, deploys become noisy, real emergencies get missed) or batching them all (a critical CVE waits 2 weeks for a quarterly release). Priority ranking — critical (exploitable in prod, ship today) / high (exploitable with conditions, ship this week) / medium (not exploitable but wrong, ship next release) / low (cosmetic, batch) — lets you match the response to the risk. The key input is exploitability, not just severity: a critical-severity vuln that requires auth + a specific config is lower-priority than a high-severity one that's exploitable by any unauthenticated request. Ranking by exploitability is what makes patch response fast where it matters and calm where it doesn't.

When

For every patch. Rank at triage time and re-rank if exploitability changes (e.g., a PoC is published).

How

1. At triage, assign both severity (CVSS) and exploitability (is there a PoC? auth required? specific config?)
2. Compute priority: critical+exploitable = P0 (today) | critical+conditional = P1 (this week) | high = P2 (this sprint) | medium/low = P3 (batch)
3. P0: drop everything, branch, fix, test, deploy within 24h; notify on-call + security lead
4. P1: fix this week, deploy as a patch release; notify in the changelog
5. P2: fix this sprint, deploy with the next scheduled release
6. P3: batch into the next minor or a quarterly "maintenance" release
7. Re-rank if conditions change: a P2 becomes P0 the moment a public PoC appears
8. Track a patch-priority dashboard: vuln, severity, exploitability, priority, ETA, status

Example

# Patch priority matrix
| Vuln          | CVSS | Exploitable?        | Priority | ETA      |
|---------------|------|---------------------|----------|----------|
| auth bypass   | 9.8  | yes, unauth, prod   | P0       | today    |
| proto pollute | 7.5  | yes, but needs auth | P1       | this wk  |
| XSS in admin  | 6.1  | yes, admin only     | P2       | sprint   |
| info leak     | 3.7  | no PoC              | P3       | batch    |

# P0 response (today)
git checkout -b hotfix/auth-bypass
# fix + regression test
git commit -m "fix(security): auth bypass [P0, CVE-2024-9999]"
npm test && npm run e2e
# deploy immediately, bypass the normal release schedule
# notify: on-call, security lead, #incidents channel

# Re-rank when a PoC appears
# "VULN-042 was P2 (no PoC). A public PoC just appeared -> P0."
# -> drop current work, fix VULN-042 today

Common Problems

  • ⚠Treating every CVE as P0 — the team burns out, deploys become noisy, and a real P0 gets lost in the noise.
  • ⚠Ranking by CVSS alone, ignoring exploitability — a 9.8 that requires a rare config waits while a 6.1 with a public PoC ships.
  • ⚠Not re-ranking when a PoC appears — a P2 sits for weeks while it's actively exploited in the wild.

Best Practices

  • ✓Rank by exploitability (is there a PoC? auth required?) not just CVSS — a low-CVSS with a public PoC is higher priority than a high-CVSS that's theoretical.
  • ✓Re-rank the moment a PoC is published — a P2 can become P0 overnight, and the ranking must track that.
  • ✓Match the deploy cadence to the priority: P0 today, P1 this week, P2 this sprint, P3 batched — don't batch a P0 into a sprint.