CVSS: Working a Score, and the Temporal and Environmental Metrics

The result. Adding, 3.5952 plus about 3.887 is about 7.482, and the roundup gives 7.5, which is High. That matches the published score in the National Vulnerability Database, which is the check that the method was applied correctly.

Notice which half limited the result. The exploitability half was as large as it can be; the impact half was held down because two of the three impact metrics are None. Heartbleed reads memory and alters nothing, and that is the whole reason it is 7.5 rather than 10.

Working it by program

The same computation as a small program. It is safe and self-contained: arithmetic on a vector string, attacking nothing.

import math

AV = {"N": 0.85, "A": 0.62, "L": 0.55, "P": 0.20}
AC = {"L": 0.77, "H": 0.44}
UI = {"N": 0.85, "R": 0.62}
CIA = {"H": 0.56, "L": 0.22, "N": 0.00}
PR_UNCHANGED = {"N": 0.85, "L": 0.62, "H": 0.27}
PR_CHANGED = {"N": 0.85, "L": 0.68, "H": 0.50}


def roundup(value):
    # The specification's Roundup: the smallest one-decimal number >= value.
    scaled = round(value * 100000)
    if scaled % 10000 == 0:
        return scaled / 100000.0
    return (math.floor(scaled / 10000) + 1) / 10.0


def base_score(av, ac, pr, ui, scope, c, i, a):
    changed = scope == "C"
    pr_weight = (PR_CHANGED if changed else PR_UNCHANGED)[pr]
    exploitability = 8.22 * AV[av] * AC[ac] * pr_weight * UI[ui]
    iss = 1 - (1 - CIA[c]) * (1 - CIA[i]) * (1 - CIA[a])
    if changed:
        impact = 7.52 * (iss - 0.029) - 3.25 * (iss - 0.02) ** 15
    else:
        impact = 6.42 * iss
    if impact <= 0:
        return 0.0
    combined = impact + exploitability
    if changed:
        combined = 1.08 * combined
    return roundup(min(combined, 10))


def score_vector(vector):
    fields = dict(pair.split(":") for pair in vector.split("/")
                  if ":" in pair and not pair.startswith("CVSS"))
    return base_score(fields["AV"], fields["AC"], fields["PR"],
                      fields["UI"], fields["S"], fields["C"],
                      fields["I"], fields["A"])


examples = [
    ("AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N", "Heartbleed: reads memory only"),
    ("AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", "Log4Shell shape: total, scope changed"),
    ("AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "local privilege escalation"),
    ("AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N", "stored-XSS shape: needs a click"),
    ("AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N", "reachable but affects nothing"),
]
for vector, description in examples:
    print(f"{score_vector(vector):>5}  {vector}  ({description})")

  7.5  AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  (Heartbleed: reads memory only)
 10.0  AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H  (Log4Shell shape: total, scope changed)
  7.8  AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H  (local privilege escalation)
  4.2  AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N  (stored-XSS shape: needs a click)
  0.0  AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N  (reachable but affects nothing)

Read the five lines as a set, because together they teach the model better than any single one.

• 7.5 reproduces the hand calculation and the published figure.
• 10.0 shows what reaches the maximum: total impact plus Scope Changed.
• 7.8 is instructive: the impact is total, exactly as in the 10.0 case, yet the score is lower, because Attack Vector is Local. Reach matters as much as damage.
• 4.2 shows the cost of dependencies: High complexity and a required user action pull a genuine flaw down into Medium.
• 0.0 is the sanity check from the previous chapter, demonstrated: a flaw that is network-reachable, reliable and needs nothing at all scores zero when it affects none of the three properties.

Temporal metrics: what is true today

The base score is deliberately frozen; it describes the flaw itself and never changes. But the practical danger does change, and the Temporal group captures that. It can only ever lower the score from the base, never raise it.

• Exploit Code Maturity. Is there a working exploit? The range runs from Unproven, through Proof-of-Concept and Functional, to High (reliable, widely available, or automated in tooling). A flaw with public reliable exploit code is a different practical problem from one nobody has weaponised.
• Remediation Level. Is there a fix? From Unavailable, through Workaround and Temporary Fix, to Official Fix. A flaw with an official patch is less dangerous in practice, because you can act.
• Report Confidence. How sure are we that this is real and correctly described? From Unknown, through Reasonable, to Confirmed.

The useful insight is that Temporal metrics move in opposite directions over time: as a flaw ages, exploit code tends to mature (raising practical danger) while remediation becomes available (lowering it). Which dominates is exactly the question a triage meeting is arguing about.

Environmental metrics: what is true for you

The Environmental group re-scores the flaw for a specific organisation, and this is where "severity" finally becomes "risk".

• Security Requirements (CR, IR, AR). How much do Confidentiality, Integrity and Availability matter for this asset? Each can be Low, Medium or High. A public marketing site may have Low confidentiality requirement and High availability requirement; a payroll database the reverse. These reweight the impact metrics.
• Modified Base Metrics. Any base metric can be overridden to reflect your deployment. If a flaw is scored Attack Vector Network but in your network the service is reachable only from an internal segment, you set Modified Attack Vector to Adjacent or Local and the score falls accordingly. If you have already applied a compensating control that requires authentication in front of it, Modified Privileges Required rises.

This is the formal answer to the complaint that "CVSS does not know my network". It can, if you supply the information, and mature vulnerability-management programmes do exactly this rather than working from base scores alone.

Prioritising properly

Putting the chapter together, a sound priority order uses three inputs, not one:

1. Base severity, the intrinsic score.
2. Exposure, from the Environmental group: is the affected thing internet-facing, does it hold important data, is it reachable by untrusted users?
3. Exploitation status, from the Temporal group and from threat intelligence: is this being exploited in the wild right now?

The third is the one teams most often omit and the one that most improves decisions. A Medium-severity flaw under active mass exploitation on an internet-facing server outranks a Critical flaw on an isolated internal system that nobody has ever exploited. A scanner sorting purely by base score will get that ordering exactly backwards.

What beginners get wrong

• Treating the base score as risk. It is intrinsic and context-free by design. Risk needs exposure and exploitation status, which the Environmental and Temporal groups supply.
• Expecting Temporal metrics to raise the score. They only lower it from the base.
• Rounding intermediate values and then adding. CVSS keeps full precision until the final roundup; rounding early gives a slightly wrong answer.
• Forgetting that Roundup is always upward. It is not round-to-nearest, so 7.401 becomes 7.5.
• Ignoring Scope in the final step. Scope Changed both alters the Impact formula and multiplies the combined value by 1.08.
• Patching strictly in base-score order. Exposure and active exploitation routinely reorder the list, and ignoring them wastes effort on flaws nobody is using.

Quick revision

• ISS = 1 - (1 - C)(1 - I)(1 - A); impacts compound but saturate.
• Impact = 6.42 x ISS (Scope Unchanged) or a curve (Scope Changed). Exploitability = 8.22 x AV x AC x PR x UI.
• Base = Roundup(min(Impact + Exploitability, 10)), with the sum first multiplied by 1.08 if Scope is Changed. Impact of zero gives 0.0. Roundup is always upward, to one decimal.
• Heartbleed works out to 7.5; total impact with Scope Changed reaches 10.0; the same total impact with Attack Vector Local gives 7.8.
• Temporal (Exploit Code Maturity, Remediation Level, Report Confidence) adjusts for what is true today and can only lower the score.
• Environmental (Security Requirements CR/IR/AR, and Modified Base Metrics) re-scores for your deployment, and is how severity becomes risk.
• Prioritise on three inputs: base severity, exposure, and whether it is being exploited in the wild.

Test yourself

1. State the four steps of the base-score calculation.

Compute the Impact Sub-Score from the three impact metrics as 1 minus the product of their survivals; scale it into Impact according to Scope; compute Exploitability as 8.22 times the four exploitability weights; add Impact and Exploitability, multiply by 1.08 if Scope is Changed, cap at 10 and round up to one decimal.

1. Two flaws both have Confidentiality, Integrity and Availability all High, but one scores 10.0 and the other 7.8. What explains the difference?

The exploitability half. The 10.0 case is network-reachable with Scope Changed; the 7.8 case has Attack Vector Local, so despite identical total impact the attacker must already be on the machine, and no Scope multiplier applies.

1. What do the Temporal metrics capture, and can they increase the base score?

Exploit Code Maturity, Remediation Level and Report Confidence, which describe the current state of the flaw in the world rather than the flaw itself. They can only lower the score relative to the base, never raise it.

1. How do the Environmental metrics turn severity into risk?

By letting an organisation state how much Confidentiality, Integrity and Availability matter for the specific asset (the Security Requirements) and by overriding any base metric to match the actual deployment, for example reducing Attack Vector from Network to Local where the service is only internally reachable.

1. Why can a Medium-severity flaw legitimately be patched before a Critical one?

Because prioritisation combines base severity with exposure and exploitation status. A Medium flaw on an internet-facing system that is being actively exploited presents more real risk than a Critical flaw on an isolated internal system with no known exploitation.