CVSS Scoring: A Hands-on Approach

Hello! Welcome to the penultimate lesson of your course.

In our last session, we focused on how to construct a professional vulnerability report, covering the five essential components: a descriptive title, a clear summary, a reproducible proof-of-concept, a compelling impact statement, and actionable remediation advice.

One of the key elements we touched upon was assessing a vulnerability's "criticality" or "impact." Today, we will formalize that process. To be a professional, you need to speak the same language as the rest of the industry. The Common Vulnerability Scoring System (CVSS) is that language. It's the global standard for capturing a vulnerability's characteristics and producing a numerical score to reflect its severity.

Our learning outcome for this lesson is to assign a CVSS score to a vulnerability based on its technical characteristics and impact. Mastering this will not only make your reports more professional but will also help you justify higher bounties and better articulate risk to clients.

1. Understanding the CVSS Framework

At its core, CVSS provides a transparent and standardized way to rate vulnerabilities. It generates a score from 0.0 to 10.0, which maps to qualitative severity ratings:

CVSS is structured into three metric groups:

1. Base Metrics: These represent the intrinsic qualities of a vulnerability that are constant over time and across different environments. This is what you, as the finder, are primarily responsible for calculating.
2. Temporal Metrics: These reflect characteristics that change over time, such as the availability of an exploit kit or an official patch.
3. Environmental Metrics: These account for factors specific to a particular organization's environment, like the presence of mitigating controls or the importance of the affected system.

The Temporal and Environmental scores are typically adjusted by the product vendor or the organization's security team to reflect their specific context. Our focus will be squarely on the Base Score.

Let's watch a short video to solidify these foundational concepts and see where to find the official calculator.

2. Deconstructing the CVSS v3.1 Base Score

The Base Score is calculated from eight metrics, which can be divided into Exploitability metrics and Impact metrics. We'll use the industry-standard CVSS version 3.1 for our main analysis, as it is still the most widely used.

The article "Bug Bounty Hunting Process" provides a concise, text-based reference for these metrics. It's a useful resource to have open as we go through them.

Now, let's dive into each metric with a more detailed walkthrough.

Understanding the "Scope" Metric

The Scope (S) metric is often the most confusing. Think of it this way: "Does the exploit allow an attacker to break out of the vulnerable component's 'box' and impact a different one?"

• Scope: Unchanged (U): The vulnerability and the impact are contained within the same security authority. For example, a SQL injection that lets you read from the application's own database.
• Scope: Changed (C): The vulnerability allows you to affect a component with a different security authority. The classic example is a Stored Cross-Site Scripting (XSS). The vulnerability is in the server-side application (it fails to sanitize input), but the impact occurs in a completely different component—the victim's web browser. The server vulnerability has escaped its scope to impact the client.

3. Practical Scoring Examples

Let's apply this knowledge to some real-world examples. The "Bug Bounty Hunting Process" article provides excellent, fully-explained CVSS assessments for common web vulnerabilities.

Let's analyze the Stored XSS example from the article together.

Vulnerability: Stored XSS in an admin panel that affects other admins.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N
Score: 5.5 (Medium)

Here is the breakdown, justifying each choice:

• AV: Network (N): The admin panel is accessible over the internet.
• AC: Low (L): No special conditions needed; the attacker just needs to store the payload in a field.
• PR: High (H): The attacker must already be an administrator to access the vulnerable function and plant the payload. This significantly lowers the score. If PR were None, the score would be much higher.
• UI: None (N): Another admin visiting the page is a passive victim; they don't need to be tricked into performing an unusual action. They are just using the application normally.
• S: Changed (C): The server-side vulnerability (improper sanitization) impacts the client-side component (the victim's browser). This is a classic scope change.
• C: Low (L): The attacker can read some data from the victim's browser context (e.g., session cookies, data on the page). It's not a full system compromise, so it's not High.
• I: Low (L): The attacker can make limited modifications in the victim's browser, like altering the page appearance or performing actions on the victim's behalf. It doesn't corrupt all data, so it's not High.
• A: None (N): This specific XSS attack doesn't cause a denial of service.

4. The Future is Here: A Glimpse at CVSS v4.0

The industry is currently transitioning from CVSS v3.1 to the newly released CVSS v4.0. As a professional, you need to be aware of this evolution. CVSS v4.0 aims to provide a more granular and intuitive scoring process, addressing some of the ambiguities of v3.1 (like the Scope metric).

You don't need to master v4.0 today, but you should understand the key changes.

Key improvements in CVSS v4.0 include:

• Finer-grained Exploitability: Attack Complexity is now supplemented by Attack Requirements (AT) to better capture preconditions.
• Granular User Interaction: The User Interaction metric is now more descriptive with three values: None, Passive, and Active.
• Clarity on Impact: The confusing Scope metric is replaced by a clear distinction between impacts on the Vulnerable System (VC, VI, VA) and impacts on Subsequent Systems (SC, SI, SA). This makes scoring XSS, for example, much more logical: the impact on the Subsequent System (the browser) is high, while the impact on the Vulnerable System (the server) is none.

Conclusion

You now have the tools to quantitatively assess the severity of a vulnerability, a non-negotiable skill for a security professional. A well-justified CVSS score elevates your report from a simple observation to a structured, defensible risk assessment.

Key Takeaways:

• CVSS is the standard: It provides a common language for describing vulnerability severity.
• Focus on the Base Score: As a finder, your primary responsibility is to calculate the Base Score based on the vulnerability's inherent characteristics.
• Justify Everything: In your report, don't just state the score; include the vector string (e.g., AV:N/AC:L/...) and a brief justification for each metric choice, especially for contentious ones like Privileges Required or Scope.
• v4.0 is on the horizon: While v3.1 is the current de facto standard, being familiar with v4.0's concepts will keep you ahead of the curve.

Next Lesson Preview:

We have reached the final lesson of this course. You've built a lab, learned reconnaissance, exploited networks and web apps, escalated privileges, and written professional reports. In our next lesson, we will tie all of this together. The final learning outcome is to develop a personal methodology for approaching a new target in a bug bounty or penetration testing engagement. This will be your strategic blueprint for success.