## TL;DR
Rank your services first, then match CVEs against the ranking. A medium CVE on your public payment API beats a critical CVE on an internal cron job almost every time. The output is an ordered patch queue: tier 1 patches today, tier 2 this week, tier 3 next cycle.

```text
how to prioritize patching across 50 services
```

### Use this when
- One CVE or a batch of CVEs affects many services at once and you need an order
- Coordinated disclosure day lands and every team asks what to patch first
- Planning a fleet-wide dependency bump across a microservice estate
- You own the remediation schedule for dozens of services

### Not for
- Patching one repo (thats a single-service problem, not a fleet problem)
- Writing the actual code fix for a vulnerability
- Setting SLAs or reporting to leadership (different skill)

### Steps

**1. Score each service by exposure.**

For every service, note three things: is it internet-facing, does it handle sensitive data (payments, PII, credentials), and how many users depend on it. Public plus sensitive plus many users equals tier 1.

Expected: three tiers, roughly 5-10 services in tier 1, 15-20 in tier 2, the rest tier 3.

**2. Score each CVE by exploitability, not just severity.**

CVSS severity is a starting point. What matters more is whether a public exploit exists and whether the vulnerable code path is reachable in your deployment. Check the advisory for exploit references and your own usage.

Expected: each CVE gets a practical danger rating that often differs from its CVSS number.

**3. Build the patch matrix.**

Rows are services, columns are CVEs. Mark each cell that applies, then sort by tier-1 service times high exploitability first. This is your patch order.

Expected: a ranked list of service plus CVE pairs, top of list is the worst combination.

**4. Patch tier 1 immediately, and communicate.**

Work the top of the list now. Tell the other teams their position in the queue and the expected window so nobody is guessing.

Expected: the highest-risk pairs patched within hours, everyone else has a date.

**5. Batch the long tail.**

Tier 3 plus low exploitability doesnt need emergency work. Roll those fixes into the next normal release cycle for each service.

Expected: low-risk pairs close without emergency pages or weekend work.

**6. Verify the matrix is empty.**

Re-run your scanner across all services and confirm every marked cell is actually cleared. One service silently still on the old version is the classic failure.

Expected: zero marked cells, scan confirms.

### Variant phrasings

#### Which services do I patch first for a CVE
Tier by exposure (public, sensitive data, user count), then cross with exploitability. Thats the order.

#### How to roll out a security patch across microservices
Same matrix, plus deploy in waves: tier 1 canaries first, watch metrics, then roll down the tiers. Emergency patches still need the order.

#### Patching order when multiple CVEs hit at once
Score each CVE for exploitability, stack them against the service tiers, and work the combined worst pairs first.

### Why it happens
Fleets grow faster than patching discipline. Every service shares some dependencies, so one CVE in a common library touches everything at once. Without a ranking you either panic-patch at random or treat everything as equal, which wastes the emergency window on low-risk services.

### Edge cases
- **Shared libraries mean coordinated deploys:** if 30 services share one internal library, patch the library once and redeploy in tier order rather than patching 30 repos.
- **Tier 1 service cant take a patch yet:** deploy a mitigation (WAF rule, feature flag off, network restriction) and document the residual risk until the real patch lands.
- **Teams disagree with their tier:** keep the tiering criteria written and public so arguments are about the criteria, not the ranking.
- **CVE with no patch affects many services:** mitigation everywhere, track the advisory, and re-check the matrix when the patch ships.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LyCHRa9XWHtM2vduA8YVKg