CVSS Scores Explained: How to Prioritise Vulnerabilities

CVSS (Common Vulnerability Scoring System) is the industry-standard method for rating the severity of a security vulnerability on a 0.0-to-10.0 scale, using metrics that capture how it's exploited and what damage it causes. A score of 9.8 sounds urgent, and often is — but CVSS alone doesn't tell you whether that vulnerability is reachable in your environment, actively exploited in the wild, or sitting on a system nobody uses. For Indian security and dev teams drowning in scan output, the real skill isn't reading a CVSS number — it's knowing what to layer on top of it before deciding what to fix first.

This guide covers how CVSS v3.1 and v4.0 scores are built, what the severity bands mean, why raw base scores routinely mislead prioritisation, and a practical workflow for triaging findings the way a working security team actually should.

What CVSS Actually Measures

CVSS is maintained by FIRST.org, the Forum of Incident Response and Security Teams, and is the reference standard cited by CERT-In advisories, NIST's National Vulnerability Database, and virtually every vulnerability scanner on the market. Each score is built from a set of metric groups, and understanding what each group actually captures is the first step to using the number correctly instead of just reacting to it.

Base Score: The Foundation

The Base metric group is what most people mean when they say "the CVSS score." It's fixed at the point the vulnerability is disclosed and doesn't change over time or by environment. In CVSS v3.1, it's built from two sub-groups:

1. Exploitability metrics — Attack Vector (network, adjacent, local, physical), Attack Complexity, Privileges Required, and User Interaction. These describe how hard it is to actually trigger the flaw.
2. Impact metrics — Confidentiality, Integrity, and Availability impact, each rated None, Low, or High. These describe what happens once it's triggered.

Temporal and Environmental Metrics: The Parts Everyone Skips

This is where most teams stop reading, and it's the biggest mistake in CVSS-based prioritisation.

1. Temporal metrics adjust the base score for real-world conditions that change after disclosure: is there a public exploit available, is it actively being exploited, has a vendor patch shipped. A high base score with no known exploit and an official fix already available is a very different risk than the same score with exploit code circulating on GitHub.
2. Environmental metrics let you re-score the vulnerability for your specific deployment — is Confidentiality Impact actually relevant if the affected system holds no sensitive data, is the attack vector actually reachable if the service isn't exposed to the internet. This is the only part of CVSS that is organisation-specific, and it's also the metric group scanners almost never fill in for you.

The Severity Bands

Scores map to five qualitative severity ratings, defined by FIRST's CVSS specification:

Why a High CVSS Score Isn't the Same as High Real-World Risk

This is the core failure mode teams fall into: treating the CVSS base score as a complete risk assessment. It isn't, and FIRST itself is explicit that Base scores represent severity, not risk.

Three factors close the gap between "how severe is this bug in the abstract" and "how much should I actually worry about it right now":

1. Exploitability in practice. A vulnerability with public proof-of-concept code, or one appearing in CISA's Known Exploited Vulnerabilities catalogue, carries active real-world risk regardless of its base score. This is what CVSS temporal metrics, and third-party scores like EPSS (Exploit Prediction Scoring System, also maintained under FIRST), are designed to capture — EPSS estimates the probability a vulnerability will actually be exploited in the next 30 days, which is a fundamentally different question than "how bad would it be if it were."
2. Asset context. What does this system hold or connect to. A Medium-severity flaw on a system processing payment data or personal data under India's DPDP Act can outrank a Critical-severity flaw on a disposable dev sandbox.
3. Business impact. Downtime cost, regulatory exposure, contractual obligations, and reputational damage aren't CVSS inputs at all — they live entirely in the Environmental layer and in your own risk register.

A Practical Prioritisation Workflow

Here's the sequence a working security team should actually follow, rather than sorting a scanner report by base score and starting from the top.

1. Start with the base score. It's your baseline severity signal and the fastest way to bucket a large finding list.
2. Layer in environmental context. Is the affected asset internet-facing or internal-only. Does it hold regulated or sensitive data. Is it in production or a disposable test environment. Re-score or manually tag findings where the answer materially changes exposure.
3. Check exploitability signals. Cross-reference against known-exploited lists and, where available, EPSS probability. A Medium-severity finding with a high EPSS score and public exploit code deserves attention ahead of a Critical finding with no known exploit path and no public interest.
4. Weigh business impact. Factor in what the asset is worth to the business — revenue-generating systems, customer PII, anything touching payment flows or DPDP-regulated personal data moves up the queue regardless of what the raw score says.
5. Assign remediation SLAs by the combined priority, not the raw band. Critical-by-context findings get the shortest fix windows; everything else follows a tiered schedule your team can actually sustain.

What a Realistic Finding Distribution Looks Like

Most vulnerability assessments, run across a typical mid-sized environment, don't return a flood of Critical findings — they return a long tail of Low and Medium issues with a smaller number of High and Critical items that need immediate attention. Treating every Medium as urgent burns team capacity that should go toward the smaller set of findings that actually matter.

Building This Into Your Process

Most teams don't need a new scoring framework — they need a lightweight, repeatable process that turns CVSS output into a ranked action list every time a scan runs, instead of re-litigating priorities from scratch each cycle. Document the environmental factors that matter for your assets once (internet-facing, data sensitivity, production status), and apply them consistently to every new finding as it comes in.

At Bachao.AI, built by Dhisattva AI Pvt Ltd, automated VAPT reporting is built around exactly this gap — surfacing base severity alongside exploitability and asset context, so findings arrive pre-triaged instead of as a raw, unranked scanner dump. If your team is still prioritising purely off base score, a free VAPT scan will show you what a context-aware finding list actually looks like against your own assets. For teams handling personal data, our DPDP compliance guide covers how vulnerability findings on regulated systems map to your broader compliance obligations, and the Bachao.AI blog has more hands-on guides like this one.