Vulnerabilities and patching

When a vulnerability is found in a product, it usually gets a CVE number (Common Vulnerabilities and Exposures), like CVE-2026-12345, so everyone can talk about the same bug. A CVSS score from 0 to 10 says how severe it is: 0.1 to 3.9 low, 4.0 to 6.9 medium, 7.0 to 8.9 high, and 9.0 to 10.0 critical.

Severity isn't the whole story. A critical bug in a program you don't run doesn't matter to you; a medium one on your internet-facing login page might. The biggest signal is whether attackers are already using it. The US agency CISA keeps a public Known Exploited Vulnerabilities (KEV) list; anything on it that you run goes to the front of the queue.

You can't patch what you don't know you have, so vulnerability management starts with an asset inventory: every device, server, cloud service and piece of software, and who owns each. A vulnerability scanner then checks them against known CVEs.

The loop: find (inventory and scan), prioritise (exploited? internet-facing? critical asset?), fix (patch, or change a setting), and check (scan again). Set targets, such as internet-facing critical fixes within days and the rest within weeks, and turn on automatic updates wherever you can. When a patch isn't possible yet, a workaround (turning a feature off, a firewall rule) reduces the risk until it is.

Software is built from other people's code: open-source libraries and the libraries they use. A flaw in one popular library can affect thousands of products at once. Keep a list of what each app depends on (a software bill of materials, SBOM), use tools that warn about vulnerable versions, and update them like anything else. Software that's past end of life gets no more patches and should be replaced.

A zero-day is a vulnerability attackers use before a patch exists. You can't patch it, which is why the other layers (least privilege, segmentation, monitoring, backups) matter: they limit the damage when something gets through.