Defining CVSS Scores

If you ask any infosec pro at random how they measure the severity of software vulnerabilities, chances are they’ll say that they use Common Vulnerability Scoring System (CVSS) scores. CVSS Scores are a mainstay in most vulnerability management programs as the primary metric by which one vulnerability is compared with another for purposes of prioritization.

There are three metric groups that make up every CVSS score – Base, Temporal, and Environmental. Every component has several subcomponents.

The metric group meant to show how a vulnerability changes in severity as a result of actions taken by software vendors and by adversaries is the Temporal Metric group. If a new patch is made available by the software vendor, the Temporal score goes down. If adversaries create and distribute easy-to-use exploit code, the Temporal score goes up.

The metric group meant to show how the severity of a vulnerability changes due to specific aspects of an organization is the Environmental Metric group.

The metric group meant to show the attributes inherent in a vulnerability that do not change over time is the Base Metric group, the focus of this article. No matter what an adversary, vendor, or enterprise does, the CVSS base score does not change. When looking up a CVSS score for a vulnerability in a third party system like NIST’s National Vulnerability Database, the reported score is almost always the CVSS Base Score.

CVSS Base Metrics

Base Metrics have three sub-groupings – Exploitability Metrics, Impact Metrics, and Scope.

Exploitability Metrics

Exploitability Metrics relate specifically to the thing that is vulnerable, without regard for any specific configuration or other compensating controls. Exploitability Metrics have four components – Attack Vector, Attack Complexity, Privileges Required and User Interaction

Attack Vector

Attack vector is an indicator of the level of access required for an attacker to exploit the vulnerability. A vulnerability that requires physical access to a target system is much more difficult to exploit than one that can be remotely exploited over the Internet.

The Attack Vector metric is scored in one of four levels:

  • Network (N) – Vulnerabilities with this rating are remotely exploitable, from one or more hops away, up to, and including, remote exploitation over the Internet.
  • Adjacent (A) – A vulnerability with this rating requires network adjacency for exploitation. The attack must be launched from the same physical or logical network.
  • Local (L) – Vulnerabilities with this rating are not exploitable over a network. The attacker must access the system locally, remotely (via protocol like SSH or RDP), or requires use of social engineering or other techniques to trick an unsuspecting user to help initiate the exploit.
  • Physical (P) – In this type of attack, the adversary must physically interact with the target system.

Attack Complexity

This metric indicates conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Most commonly, this refers to either required user interaction, or specific configurations of the target system.

The Attack Complexity metric is scored as either Low or High:

  • Low (L) – There are no specific pre-conditions required for exploitation.
  • High (H) – There are conditions beyond the attackers control for successful attack. For this type of attack, the attacker must complete some number of preparatory steps in order to get access. This might include gather reconnaissance data, overcoming mitigations, or becoming a man-in-the-middle.

Privileges Required

This metric is exactly as it sounds, describing the level of privileges, or access, an attacker must have before successful exploit.

Privileges requires falls under three ratings:

  • None (N) – There is no privilege or special access required to conduct the attack.
  • Low (L) – The attacker requires basic, “user” level privileges to leverage the exploit.
  • High (H) – Administrative or similar access privileges are required for successful attack.

User Interaction

The User Interaction metric describes whether a user, other than the attacker, is required to do anything or participate in exploitation of the vulnerability.

User Interaction is a yes/no metric:

  • None (N) – No user interaction is required.
  • Required (R) – A user must complete some steps for the exploit to succeed. For example, a user might be required to install some software.

Impact Metrics

Impact Metrics measure the impact to the well known CIA Triad (Confidentiality, Integrity, Availability) of the impacted system. In other words, what is the final negative outcome that occurs as a result of exploitation.


Confidentiality refers to the disclosure of sensitive information to authorized and unauthorized users, with the goal being that only authorized users are able to access the target data.

Confidentiality has three metric values:

  • High (H) – the attacker has full access to all resources in the impacted system, including highly sensitive information such as encryption keys.
  • Low (L) – the attacker has partial access to information, with no control over what, specifically, they are able to access.
  • None (N) – no data is accessible to unauthorized users as a result of the exploit.


Integrity refers to whether the protected information has been tampered with or changed in any way. If there is no way for an attacker to alter the accuracy or completeness of the information, integrity has been maintained.

Integrity has three metric values:

  • None (N) – there is no loss of the integrity of any information.
  • Low (L) – A limited amount of information might be tampered with or modified, but there is no serious impact on the protected system.
  • High (H) – The attacker can modify any/all information on the target system, resulting in a complete loss of integrity.


Information needs to be accessible as needed. If an attack renders information unavailable, such as when a system crashes or through a DDOS attack, availability is negatively impacted.

Availability has one of three metric values:

  • None (N) – there is no loss of availability
  • Low (L) – Availability might be intermittently limited, or performance might be negatively impacted, as a result of a successful attack.
  • High (H) – There is a complete loss of availability of the impacted system or information.


The scope metric is a determination on whether a vulnerability in one system or component can have carry over impact on another system or component. According to FIRST, “a security authority is a mechanism (e.g., an application, an operating system, firmware, a sandbox environment) that defines and enforces access control in terms of how certain subjects/actors (e.g., human users, processes) can access certain restricted objects/resources (e.g., files, CPU, memory) in a controlled manner. All the subjects and objects under the jurisdiction of a single security authority are considered to be under one security scope. If a vulnerability in a vulnerable component can affect a component which is in a different security scope than the vulnerable component, a Scope change occurs.

Scope has two possible ratings – changed or unchanged:

  • Changed (C) – An exploited vulnerability can have carry over impact on another system.
  • Unchanged (U) – The exploited vulnerability is limited in damage to only the local security authority.

Operationalizing CVSS Scores

As discussed previously, published CVSS scores are typically comprised of Base Metrics only. This is a useful starting point, but really only answers the question, “Is it possible for this to do damage?”, when you really need to answer, “Can this do damage to my company?” In order to ensure that you’re not being misled by CVSS scores, you need to ensure that you’re accounting for Temporal and Environmental factors as well. This is key to successfully operationalizing CVSS scores in your vulnerability management program.