Field lesson S2 / 9 min

Prioritize vulnerabilities and exposures

Combine severity, exploitation evidence, exposure, and business context to order a synthetic vulnerability backlog without pretending a single score is enough.

socvulnerabilitykevepss

What you’ll be able to do

  • Build a queue that uses CVSS, EPSS, KEV, exposure, and asset impact as separate columns.
  • Explain a justified exception when a lower-severity issue should jump the queue.
  • Refuse to invent exploitation evidence that is not in the catalog or in local telemetry.
  • Connect the queue to an owner and a verification step after patching.

A backlog is a set of documented bets

Riverstone’s scanner dumped 400 findings. Maya and Devon will not patch 400 things tonight. They will make a queue that can be defended tomorrow. Each row should keep signals separate: CVSS for technical severity, EPSS for a 30-day exploitation probability estimate, KEV for observed exploitation somewhere, exposure for whether Riverstone actually presents the service, and impact for the F1 asset that would fail.

Mixing those into one homemade “risk score” can be fine internally if the recipe is public to the team. Hiding the recipe inside a red-yellow-green blob is how the lunch wiki beats the VPN again. FIRST publishes CVSS and EPSS as different tools on purpose. CISA KEV is a third tool. Use them as columns.

Worked backlog: three findings

Finding A: VPN appliance, CVSS high, KEV-listed, EPSS elevated, internet-facing, authenticates drivers. Impact: FleetLink and YardOS stall if it is taken, plus a path toward identity abuse. Finding B: TrackPort library with a medium CVSS, no KEV, moderate EPSS, but the library parses uploaded bills of lading and a public proof-of-concept appeared this morning. Impact: integrity of shipping documents. Finding C: internal wiki plugin, CVSS high, EPSS low, not KEV, reachable only from the office VLAN, no customer data.

Tonight’s order is A, then B, then C—unless new evidence appears. B jumps many “high” internal findings because of exposure of a document parser plus a public exploit path, even without KEV. C stays visible so it does not rot. Verification after A is not “the ticket closed.” It is: version string, management port not on the internet, test login, and a watcher for the KEV identifier.

  • Do not drop a KEV item because patching is inconvenient.
  • Do not promote a finding because a vendor called it AI-powered.
  • Compensating controls (geofence, WAF rule) can buy hours, not silence.
  • Unscanned assets are a queue item of their own: unknown exposure.

Exceptions and honesty

Sometimes the VPN cannot be patched until a maintenance window because a vendor image is broken. That is an exception, not a disappearing row. Write the compensating control, the owner, the expiry, and the evidence you will watch in between. CSF Govern and Identify expect that kind of ownership. CIS IG1-minded hygiene still wants the appliance inventoried and the admin interfaces constrained.

If EPSS is low and KEV is empty, you may still patch early when the asset is a domain controller or a backup catalog. Business context can raise a row. It should not lower a KEV-listed internet appliance without a written compensating control. Never invent a local exploit just to win an argument; say “no local evidence yet.”

CHECK YOUR JUDGMENT

Devon can patch only one system before Friday’s freight surge. The candidates are the KEV-listed internet VPN, a high-CVSS wiki plugin, and a medium-CVSS TrackPort parser with a new public proof-of-concept. Which choice and justification should Maya record?

NEXT FIELD LESSON

Investigate, respond, and verify recovery

Find your next idea.

Tip: press / to open search. Escape closes this window.