Reading a CVSS Score Without Overreacting

An advisory lands with a 9.8 on it and the phone rings. Someone wants to know whether the line has to stop. The honest answer is almost always "not yet, and here's what I need to check first" — but getting there requires reading past the number, and the number is the only part most summaries carry.

CVSS base scores measure severity under assumed conditions, not risk in your plant. The score is computed from a vector, and the vector is where the useful information lives. AV:N means the attack comes over a network; AV:A means an adjacent network, which in practice means someone already inside the right VLAN; AV:L means local access; AV:P means physically touching the device. Those four letters change the conversation completely. A 9.8 with AV:N on a device exposed to the internet is an emergency. The same 9.8 on a controller reachable only from an engineering VLAN that six people can enter is a scheduling problem.

The privileges and interaction metrics matter nearly as much. PR:N means no credentials needed. UI:R means a user has to do something — open a file, click a link, restore a backup — and on an unattended RTU there may be no user to require. A flaw that needs an operator to import a tampered configuration file is real, but it sits behind a procedure you can change this week without touching firmware.

Then there is what CVSS deliberately does not know. It has no idea that the affected device runs a safety function, or that its failure mode is a silent wrong reading rather than a crash, or that it sits on a skid you cannot power down between September and March. Those facts dominate the actual decision, and they live in your head and your P&IDs, not in the advisory.

This is why two advisories with identical scores produce different work. A 7.5 denial of service on a protection relay can be more urgent than a 9.1 information disclosure on an HMI, because losing protection for ten minutes has consequences that losing confidentiality does not. Scoring systems are built to be comparable across products, which necessarily means being blind to context, and context is most of what an OT engineer knows.

A practical habit: when an advisory arrives, write down four things before deciding anything. What is the vector's access requirement. Is the service even enabled on your units. What does the device do if the flaw is exploited — stop, misbehave, or leak. And when is the next window in which you could touch it. Those four answers produce a decision. The score alone produces a meeting.

One more thing. Vendors increasingly publish both CVSS v3.1 and v4.0 scores, and they often differ by a point or more in either direction. That's not inconsistency; v4.0 adds metrics for automatable exploitation and for safety impact, which is exactly the kind of thing the older version could not express. If an advisory gives you both, the v4.0 vector is usually the more informative one for industrial equipment, and almost nobody reads it.