What does a CVSS base score deliberately leave out about your own deployment?
answer
- the same number for everyone, everywhere
- intrinsic to the flaw, not the deployment
- asset value and segmentation are invisible
- severity is not likelihood
- environmental fixes three, EPSS fixes the fourth
basics
~20 sA CVSS base score rates the flaw itself under reasonable worst-case assumptions. It ignores where your instance actually sits, how much the affected asset matters to your business, what controls already stand in the way, and how likely exploitation is.
solid answer
~50 sBase metrics describe properties of the vulnerability that are meant to hold everywhere and forever: how it is reached, what conditions the attacker needs, and what it does to confidentiality, integrity and availability of the affected component. The publisher scores once and everyone reads the same number, which is exactly why it is blind to you. It does not know your instance answers only inside a private VLAN, or that the affected component holds transaction-signing keys rather than a public catalogue. It does not know about the segmentation, allowlists or hardening already in front of it. And it is a severity number, not a probability — it says nothing about whether anyone is actually exploiting the flaw this month. CVSS answers the first three with environmental metrics; exploitation-probability data such as EPSS and a catalogue of vulnerabilities with confirmed in-the-wild exploitation answers the fourth. The base score is where a rating starts, not where it ends.
go deeper
Know that the number published with a vulnerability describes the flaw in the abstract, and that your team still has to decide what it means for your system. Do not read a severity band as a work queue.
Be ready to list what the base group cannot express — exposure, asset value, compensating controls, likelihood — and to name environmental metrics and exploitation-probability data as the two different fixes for different gaps.
Expect to be handed a scored finding on a real design and asked whether the number is right for that deployment. Show the rescoring, and say out loud which assumption you replaced and why.
Own the position that a published severity is an input, not a policy. Be able to argue what your organisation's rating actually is a function of, and what it costs when teams inherit someone else's worst-case assumption as their own priority order.
## What a base score actually claims CVSS base metrics are defined as the intrinsic characteristics of a vulnerability: the ones intended to be constant over time and across every user environment. That is a deliberate design choice, because it lets one publisher score a flaw once and lets thousands of downstream readers consume the same number. The price of that universality is that the number describes the flaw, not your system. A base score is a statement about a piece of software; a risk rating is a statement about a running deployment. Confusing the two is the most common scoring mistake in a design review. ## The five things it omits **1. Where your instance actually sits.** A base vector saying the flaw is network-reachable means it is reachable over a network in the general case. It cannot know that your copy listens only on a private VLAN entered through a jump host, and it equally cannot know that you accidentally published the admin port to the internet. Exposure is a property of your deployment, not of the code. **2. What the asset is worth to you.** Base impact metrics say what the flaw does to the affected component. They cannot say whether that component holds a public price list, a customer identity store, or the scheduling authority for something with no tolerance for downtime. **3. Compensating controls.** Network segmentation, a narrow source allowlist, request filtering at the edge, a hardened runtime, strong detection on the affected path — none of these are visible to the person who scored the flaw, and none of them reduce the published number. **4. Probability.** Severity is roughly impact combined with how hard the attack is. It is not an estimate of how likely anyone is to run that attack against you in the near term. A high base score on a flaw nobody has ever weaponised and a high base score on one being sprayed across the internet today read identically. **5. Chains.** A base score rates one flaw in isolation. Two medium-rated flaws that compose — one that leaks an internal hostname, one that trusts callers from that host — can be worse together than either alone, and no single base score expresses that. One further trap: when the environment is unknown, scoring guidance directs the scorer toward the reasonable worst case. So the base number is not neutral, it leans pessimistic on purpose. That is safe for a publisher and misleading for a defender who treats it as a verdict. ## What CVSS offers as the fix The environmental metric group exists precisely to absorb the first three omissions. Modified base metrics let you re-express reachability, required privileges and impact as they truly are in your deployment, and the security requirement metrics let you state how much confidentiality, integrity or availability matters for that specific asset. Requirements default to a neutral middle setting, so an unstated requirement changes nothing, and raising one increases the weight of the matching impact term. Crucially, environmental scoring can move the number **up** as well as down — a modest base score on an asset where one property is critical can end up outranking a headline-grabbing score elsewhere. ## What complements it from outside CVSS Exploitation-probability data fills the fourth gap. EPSS produces a daily-refreshed probability that exploitation activity will be observed for a vulnerability in the next thirty days, together with a percentile ranking. A published catalogue of vulnerabilities with confirmed in-the-wild exploitation gives a blunter, binary signal: someone, somewhere, has been seen using this. Neither carries any information about impact, so neither replaces severity — they multiply against it. ## A worked example Consider the scheduling service of a satellite ground station, which allocates contact windows for passes overhead. An anonymous internet attacker reaching that service cannot read anything interesting and cannot forge much, but can stop it answering. Confidentiality and integrity requirements here are close to irrelevant; availability requirement is critical, because a missed window is a mission the customer does not get back. A denial-of-service flaw with an unremarkable base score, rescored with availability requirement high, can and should outrank a confidentiality flaw with a much larger published number sitting on a reporting database. If the team orders work by base score alone, it fixes the wrong one and can defend the choice only by pointing at a number that was never about them. ## How to say it in an interview Compress it to three clauses: the base score describes the flaw; environmental metrics describe the flaw **here**; exploitation-probability data describes whether anyone is **using** it. A rating that skips either of the last two is an inherited opinion, not an assessment.
- Can a flaw with a low base score ever be your top priority?Yes, routinely. Base impact is scored against the affected component in the abstract; if that component is the only thing keeping a critical function alive, the security requirement for the matching property is high and the environmental score rises accordingly. A modest denial-of-service flaw in a single-path scheduling service outranks a large confidentiality score on a system holding nothing sensitive. The published number is an input to that comparison, not the comparison.
- Why does scoring guidance push toward the reasonable worst case when the environment is unknown?Because the publisher genuinely does not know who runs the software or how. Assuming the most exposed plausible deployment means the published number errs toward over-warning rather than under-warning, which is the right default for a broadcast signal. It also means the number is systematically pessimistic for hardened deployments, so a defender who never rescores will chronically over-prioritise flaws that their own architecture already blunts.
- What does a base score fail to capture when two flaws are chained?Everything about the chain. Each score assumes the attacker starts from the position that flaw's own metrics describe, so a flaw requiring local access is scored as if reaching that position were a precondition, not a step. If another flaw supplies exactly that position, the realistic attack is easier than either score suggests. Chains are found by modelling the path, not by reading two numbers side by side.
A base score is a crash-test rating for a car model. It tells you nothing about whether you race the car daily or keep it in a locked garage.
saying these in an interview costs you the question
- Treats a 9.8 as a mandate to fix first, unconditionally
- Believes the base score already accounts for the affected system's importance
- Assumes a high base score means exploitation is likely
- Thinks segmentation or an allowlist lowers the published base score
- Reads base impact as impact on the business rather than on the component