A desktop fleet runs forty to a hundred third-party apps, and between them they publish several updates a week. Nobody deploys them all on the day they appear, so every team has a prioritisation policy, written or not. The unwritten one is usually "browsers quickly, the rest when we get to it", which is not wrong, just unmeasurable. This is how to make it explicit without turning it into a vulnerability-management programme.
What a CVSS score tells you, and what it does not
CVSS (the Common Vulnerability Scoring System) gives each published vulnerability a base score from 0 to 10, from the characteristics of the flaw: how it is reached (network or local), whether it needs a user to do something, how much privilege it grants. The usual bands are critical from 9.0, high from 7.0, medium from 4.0, low below that.
The score describes severity if exploited, not the likelihood that anyone will. The large majority of published CVEs are never seen exploited in the wild, and a flaw rated 7.5 that is being used in phishing campaigns this week matters more than a 9.8 that requires local access to a box nobody has. Ranking purely by score makes a team spend its week on the wrong patches, which is the honest reason most teams stop looking at scores.
What CISA KEV adds
The Known Exploited Vulnerabilities catalogue, kept by the US Cybersecurity and Infrastructure Security Agency, lists CVEs with reliable evidence of active exploitation. It is small (a few hundred additions a year across all software), it is free, and it is the best single signal of "patch this now" available without a threat-intelligence subscription. US federal agencies are required to remediate KEV entries by a due date, typically within three weeks of listing; for a private fleet the same list makes a good tier-zero trigger with a shorter clock.
Two things to know. KEV lists a CVE when exploitation is confirmed, which can be weeks after the vendor's fix, so a KEV entry often concerns an update you could already have deployed. And NVD may not have scored a CVE yet when it lands on KEV; the exploited flag should not wait for the score.
A four-tier policy for desktop apps
| Tier | Trigger | Target | How |
|---|---|---|---|
| 0 | A fixed CVE is on KEV, or the vendor says it is being exploited. | Pilot within 24 hours, everyone within 72. | Skip the normal waiting period; rings still apply but with a one-day gap, not a week. |
| 1 | Fixes a critical (9.0+) CVE, or any CVE in an internet-facing category: browsers, PDF readers, mail clients, remote-access and VPN clients, Office-adjacent tools. | Everyone within 7 days. | Normal rings, standard gaps. |
| 2 | Fixes a high (7.0 to 8.9) CVE in anything else. | Everyone within 14 days. | Normal rings; can share a deployment window with other tier-2 updates. |
| 3 | Everything else: medium and low fixes, feature releases. | Next monthly cycle. | Batch them. |
The category clause in tier 1 matters: most real-world compromise of desktop fleets comes through the handful of apps that open untrusted content, and treating a 7.8 in a PDF reader like a 7.8 in a disk-benchmarking tool is the mistake the score invites.
Where the data comes from, and its lag
- NVD (the US National Vulnerability Database) publishes CVE records with scores and affected-version ranges. Since 2024 it has carried an analysis backlog, so a new CVE can sit unscored and unmapped for days or weeks; vendor advisories and CNA scores fill the gap.
- Affected-version ranges are how a CVE is tied to the version on your devices. They are frequently missing or written against a product name that is not quite your installer's, which is why tools that show this data have to curate the mapping and why some apps have no data at all.
- Vendor release notes remain the authority for "this version fixes this". The feeds confirm and score; they do not replace reading the notes for your tier-0 and tier-1 apps.
Measuring it
Three numbers make the policy real: time to patch (from the fixed version appearing to it being deployed, per tier), the share of devices on a fixed version after the target window, and the exposure window (how many devices ran a version with a known-exploited CVE, for how long). The first two come from your deployment tool; the third needs CVE data joined to your inventory.