Which Vulnerability Should You Patch First?

A patch queue contains a critical issue in an unused component and a lower-scored flaw on an internet-facing gateway. Which goes first? A severity score describes properties of a vulnerability. Your queue also needs to describe the system on which it exists.

Establish whether the finding applies

Identify the product, deployed build, enabled feature and path an attacker would need. Distribution vendors sometimes backport fixes without changing the upstream version as a scanner expects. Check the vendor's advisory and package revision before assuming the finding is exploitable or dismissing it as noise.

Look for actual exposure. A vulnerable management endpoint behind an access control still deserves attention, but it presents a different immediate risk from the same endpoint published anonymously on the internet. Verify the restriction from the relevant network boundary.

Separate urgency from certainty

CISA's Known Exploited Vulnerabilities Catalog identifies vulnerabilities with evidence of exploitation in the wild. A listing can increase urgency; absence is not proof of safety. Combine that signal with the system's privileges, data access and the time required to isolate or patch it.

For the gateway example, a temporary access restriction may reduce exposure today while an update is tested. Record its owner and expiry. Otherwise an emergency workaround can become an undocumented permanent dependency.

Close the finding with evidence

After rollout, verify the running version or configuration, not merely the package downloaded to disk. Repeat the original exposure check and confirm service health from a user's route. Keep a separate exception for systems that could not be fixed. A queue sorted by next action and owner is easier to operate than a spreadsheet of alarming scores.

Further reading

CISA: Known Exploited Vulnerabilities Catalog

Related guide: Design Network Segmentation Around Real Traffic.