Skip to main content

​
Overview

The Common Vulnerability Scoring System (CVSS) is an industry-standard framework for assessing the severity of security vulnerabilities. VulnTrack implements CVSS v3.1, which provides a standardized method to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity.

​
CVSS Score Range

CVSS scores range from 0.0 to 10.0, with higher scores indicating greater severity:
Score RangeSeverity
0.0None
0.1 - 3.9Low
4.0 - 6.9Medium
7.0 - 8.9High
9.0 - 10.0Critical

​
CVSS Vector String

VulnTrack stores CVSS scores using the standard vector string format: 
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
This compact representation encodes all the metrics that contribute to the final score.

​
Base Metric Groups

CVSS v3.1 consists of three metric groups. VulnTrack primarily focuses on Base Metrics, which represent the intrinsic characteristics of a vulnerability that are constant over time and across user environments.

​
Exploitability Metrics

These metrics capture how easily a vulnerability can be exploited.
This metric describes the context by which vulnerability exploitation is possible.
​
AV:N
Network
The vulnerability is exploitable remotely over a network. The attacker does not require access to the local network or physical proximity.Example: A SQL injection vulnerability in a public web application
​
AV:A
Adjacent Network
The vulnerability requires access to the local network (e.g., LAN, Bluetooth).Example: An ARP spoofing attack on a local network
​
AV:L
Local
The attacker must have local access to the system or requires local execution.Example: A privilege escalation vulnerability requiring shell access
​
AV:P
Physical
The attacker requires physical access to the device.Example: A vulnerability in a hardware security module
This metric describes the conditions beyond the attacker’s control that must exist to exploit the vulnerability.
​
AC:L
Low
No special conditions exist. The attacker can expect repeatable success.Example: A buffer overflow with a publicly available exploit
​
AC:H
High
Successful exploitation depends on conditions beyond the attacker’s control (e.g., race condition, information gathering).Example: A timing-based side-channel attack requiring precise conditions
This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.
​
PR:N
None
The attacker requires no authentication or privileges.Example: Unauthenticated remote code execution
​
PR:L
Low
The attacker requires basic user privileges.Example: An authenticated user can read other users’ data
​
PR:H
High
The attacker requires significant privileges (e.g., administrator).Example: A vulnerability requiring admin access to exploit
This metric captures whether exploitation requires user participation.
​
UI:N
None
The vulnerability can be exploited without any user interaction.Example: A worm that spreads automatically
​
UI:R
Required
Exploitation requires a user to perform some action.Example: A phishing attack requiring the user to click a malicious link

​
Scope (S)

This metric captures whether exploitation of the vulnerability affects resources beyond its security scope.
​
S:U
Unchanged
The exploited vulnerability can only affect resources managed by the same security authority.
​
S:C
Changed
The exploited vulnerability can affect resources beyond the authorization scope.Example: A VM escape vulnerability allowing access to the host system

​
Impact Metrics

These metrics capture the direct impact of a successful exploit on the CIA triad.
Measures the impact to data confidentiality.
​
C:N
None
No impact to confidentiality.
​
C:L
Low
Some information disclosure, but limited access.
​
C:H
High
Total information disclosure, providing access to all system data.
Measures the impact to data integrity.
​
I:N
None
No impact to integrity.
​
I:L
Low
Modification of some data is possible, but the attacker has limited control.
​
I:H
High
Total compromise of system integrity with the ability to modify any data.
Measures the impact to system availability.
​
A:N
None
No impact to availability.
​
A:L
Low
Reduced performance or interruptions in resource availability.
​
A:H
High
Total loss of availability, with the attacker able to fully deny access.

​
Data Storage

In VulnTrack’s database schema, CVSS data is stored in the Vulnerability model: 
model Vulnerability {
  id                  String   @id @default(uuid())
  title               String
  description         String
  severity            String
  
  // CVSS fields
  cvssScore           Float?
  attackVector        String?
  attackComplexity    String?
  privilegesRequired  String?
  
  // Additional CVSS metrics stored in JSON
  impactAssessment    String? // JSON serialized
  
  // ... other fields
}

​
Example: Calculating a CVSS Score

Consider a remote code execution vulnerability in a web application: 
const cvssVector = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H";

const vulnerability = {
  cvssScore: 9.8,
  severity: "CRITICAL",
  attackVector: "Network",
  attackComplexity: "Low",
  privilegesRequired: "None"
};
Analysis:
  • AV:N - Exploitable remotely over the internet
  • AC:L - Easy to exploit with public exploits available
  • PR:N - No authentication required
  • UI:N - No user interaction needed
  • S:U - Impact limited to the vulnerable component
  • C:H/I:H/A:H - Complete compromise of confidentiality, integrity, and availability
Result: CVSS Score of 9.8 (Critical) - Immediate remediation required

​
Best Practices

Use Standard Vectors

Always store the complete CVSS vector string to ensure reproducibility and transparency in scoring decisions.

Consider Context

While CVSS provides objective severity, always consider your specific environment and risk tolerance.

Regular Updates

Review CVSS scores when new information about a vulnerability becomes available.

Combine Frameworks

Use CVSS alongside DREAD and STRIDE for comprehensive risk assessment.

​
Resources

Build docs developers (and LLMs) love

Get started for freeTalk to us