Understanding CVSS Scores and Their Limitations

The Common Vulnerability Scoring System (CVSS) shows up on nearly every vulnerability scan report, every CVE entry, and every vendor security advisory. It's genuinely useful — a standardized, reproducible way to describe how severe a vulnerability is in the abstract. It is also frequently misused as a stand-in for "how much should I worry about this," which is a different question entirely.

What CVSS Actually Measures

CVSS (currently versions 3.1 and 4.0 are both in active use) produces a score from 0 to 10 based on a set of metrics grouped into categories:

• Base metrics — intrinsic characteristics of the vulnerability: attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction needed, and the impact on confidentiality, integrity, and availability. This is the score most people see and cite.
• Temporal metrics (v3.1) or threat metrics (v4.0) — factors that change over time, such as whether exploit code exists and how mature it is.
• Environmental metrics — organization-specific adjustments, letting you modify the base score based on your actual deployment (for example, lowering it if a compensating control mitigates the impact).

In practice, the overwhelming majority of scanners and dashboards report only the base score, because it's the one published centrally and doesn't require per-organization configuration. That convenience is exactly where the limitation begins.

The Base Score Is Context-Free By Design

A base CVSS score describes the vulnerability as if it existed on a generic, undefined system with no compensating controls and no information about how it's actually deployed. That's intentional — it lets vendors and researchers publish one consistent number for a given flaw. But it means the base score cannot know:

• Whether the affected system is internet-facing or isolated on an internal network with no route from untrusted zones.
• Whether a WAF, network segmentation, or endpoint protection already blocks the practical exploitation path.
• Whether the system holds your most sensitive data or is a disposable internal test box.
• Whether an exploit is sitting in a research paper or is being used in active ransomware campaigns right now.

A 9.8 "critical" base score on an internal, network-segmented, low-value system can be genuinely lower priority than a 6.5 "medium" on a public-facing system holding customer records with a known working exploit. Teams that sort remediation queues purely by base score routinely get this backwards.

Where CVSS Falls Short Structurally

Beyond the context problem, CVSS has known structural limitations worth understanding:

• It measures severity, not likelihood. A vulnerability can be maximally severe if exploited and still be extremely unlikely to be exploited in your environment, or vice versa.
• Scores can shift after initial publication. Early CVSS ratings are sometimes assigned before full technical details are public and get revised — sometimes significantly — once more is understood about real-world exploitability.
• It doesn't capture chained exploits. Two "medium" findings that are individually unremarkable can combine into a critical attack path — CVSS scores each in isolation and has no mechanism to reflect that combination.
• Version differences create inconsistency. CVSS 4.0 changed how several metrics are calculated compared to 3.1, so scores for similar vulnerabilities aren't always directly comparable across the transition period, and many vendors still publish only 3.1 scores out of habit or tooling limitations.

Using CVSS Correctly

None of this means CVSS should be ignored — it means it should be one input among several, not the sole prioritization mechanism. A more defensible approach:

• Use the base score as a starting filter (for example, to decide what deserves triage attention at all), not as the final ranking.
• Layer in environmental context manually or through your platform: is this asset exposed, and how critical is it to the business?
• Check exploit availability and active exploitation status separately — resources like CISA's Known Exploited Vulnerabilities catalog are more predictive of real risk than the base score alone.
• Recalculate or annotate scores with environmental metrics when your organization's deployment materially changes the real-world impact, and document why.
• Revisit scores periodically for long-lived findings, since exploit maturity and threat activity change even when the underlying CVSS number doesn't.

A Concrete Example

Consider a vulnerability with a base score of 7.5 in a third-party library used by an internal reporting tool with no external access and no sensitive data. Under a naive "sort by CVSS" policy, this competes for remediation attention with a 7.5 on your public API gateway. Under a risk-informed policy, the API gateway finding is remediated first — same base score, materially different real-world risk — and that gap is exactly what environmental context is meant to close.

This is also why manually reconciling CVSS scores against exposure and asset data across a large environment gets unwieldy fast, and why platforms built for vulnerability management increasingly bake exposure and asset-criticality context directly into the triage workflow. Venstap's findings and asset modules are built around exactly this gap — combining CVSS as reported by scan engines like nuclei with asset context (exposure, criticality, ownership) so triage decisions reflect actual risk rather than a single generic number. CVSS is a valuable common language for describing vulnerabilities. It was never meant to be the whole conversation.