CVE triage: deciding what gets patched first

Advisories do not arrive in order. They arrive as weather: mailing lists, distribution announcements, dashboards, an API feed, and somewhere in between the one line a colleague forwards because the word critical appears in it. The work is not patching everything; the work is deciding what gets patched first. That is triage, and it is a craft we can systematize.

What the number on the label really says

The first instinct is to sort by score. As a first filter that is not wrong, but as the only criterion it is thin. CVSS, the widespread rating system in version 3.1, measures the intrinsic properties of a vulnerability: how it is exploited, what rights an attacker gains, how much interaction it needs. In late 2023, CVSS 4.0 arrived as the next generation, folding context more explicitly into the model. Both share a limitation: they describe the vulnerability in general, not the server it sits on.

So 9.8 does not automatically mean first. A top-score flaw in a library that only an offline batch job imports is a different situation than a 6.5 in the web server facing the internet. The score pre-sorts the queue; the context decides.

The questions that supply the context

In practice we triage through a handful of questions that take minutes per advisory:

• Reachable from where? Does the affected component even listen on an interface anyone can reach, or does it sit behind a firewall, in an isolated network, on localhost only?
• What does exploitation require? A login, a specific configuration state, an unusual package combination?
• Is the affected feature even active? Many vulnerabilities hide in code paths a concrete installation never executes.
• Is there active exploitation? Evidence of real-world use moves a vulnerability into a different category regardless of the score.
• Is a patch out, and in what form? Directly, as a distribution backport, or only a workaround?

Answering these five per advisory usually yields a usable category within minutes: now, this week, next maintenance window, monitor only.

The two-question policy for daily operations

For the ongoing routine we collapse this further into two questions, and it works surprisingly well. Question one: can this vulnerability be exploited from the outside, or from a compromised host, without special preconditions? Question two: does a patch or backport exist, and how does the cost of applying it compare to the risk? Everything that answers question one with an easy yes moves up; everything that answers with practically never moves down; the gray zone gets resolved with the five questions above.

The second half of the policy matters as much: decisions get written down. A short entry per case, with the date, the rating, the reasoning, and a re-check date, is enough. It prevents two classic failure modes: re-litigating the same case three months later because nobody remembers why it was downgraded, and mistaking the cases that repeat loudly in the feed for the ones that actually matter.

Where the data comes from

The intake side should be automated. The security announcements of the distributions we run are the most reliable basis for server operations, because they state exactly which package version is affected and where the fix comes from. The large vulnerability databases add structure: scores, references, and, through their programming interfaces, a subscribable feed filtered to our own software list. That filter is the difference between a feed that works and a mailbox that just nags.

One expectation to set honestly: no feed is complete, and none comes pre-prioritized. The data is raw material; the ordering happens in operations, with the five questions and the two-question policy. Anyone waiting for a tool to emit the correct order will wait a long time.

Decisions are only as traceable as the log basis underneath them; the post Managing Linux server logs properly covers how we lay that basis.

Where the method stops

Triage has a known blind spot: it works on known vulnerabilities. A newly discovered exploitation path without an advisory does not enter the queue; it needs a response, not a priority. That can be prepared as well: a fixed intake channel, one responsible contact per critical system group, and the agreement that active exploitation suspends the two-question policy. Teams that have agreed on this in advance spend the crisis morning acting rather than organizing.

What practice adds to the method

In daily use it turns out that the method is decided less by the vulnerabilities than by the organization around them. Three details have proven load-bearing. First, the fixed slot: triage runs once a day at a set time, not event-driven between other tasks. A reserved place in the day keeps the queue from piling up over days and the decisions from being made under pressure.

Second, the division of labor: whoever answers the questions needs access to the inventory data, not to change rights. Triage decides the order; applying patches belongs elsewhere, with its own windows. That separation keeps decisions sober, because nobody stands under the pressure of defending their own rating by rushing it out.

Third, the retrospective: at the end of each quarter the decision list deserves a look. The question is simple: how many cases were downgraded and stayed harmless, how many downgraded cases turned out to matter later? Both numbers calibrate the own criteria better than any general advice, and after two quarters they show very honestly whether the method fits the landscape or runs too generous or too timid.

One final piece has proven itself: sorting at intake. Incoming reports get split on arrival into two stacks, those touching software present in the own landscape and those not. The second stack gets archived, not read; it removes the largest share of the volume from the daily round without information loss, because for a server on which the affected component does not run there is nothing to decide. The sorting itself is a match against the inventory list and therefore automatable; it belongs to the few steps in this topic that a script handles more reliably than a person.

If you want us to set this practice up for your server landscape, as ongoing management or as a one-time audit of your current queue, the security hardening and audits page describes the matching service, and the contact page is the fastest way to reach us.

Sources

• FIRST, CVSS v4.0 Specification Document, https://www.first.org/cvss/v4.0/specification-document (accessed 2026-11-03)
• FIRST, CVSS v3.1 Specification Document, https://www.first.org/cvss/v3.1/specification-document (accessed 2026-11-03)
• NIST NVD, Vulnerability Data API documentation, https://nvd.nist.gov/developers/vulnerabilities (accessed 2026-11-03; the site rate-limits automated requests, browser access works)
• Debian security advisories index, https://www.debian.org/security/ (accessed 2026-11-03)