What CVSS measures and what it doesn't

The Common Vulnerability Scoring System (CVSS) is an open standard, maintained by FIRST.Org, that expresses the severity of a vulnerability as a numeric value from 0.0 to 10.0. The NVD definition is unambiguous here: the Base Score reflects severity - CVSS is not a measure of risk. This distinction is the most important starting point for any prioritization: the value describes how bad a technical flaw is in principle, not how likely or how business-critical its exploitation would be in a specific environment.

CVSS organizes its assessment into metric groups. In CVSS v3.1, these are Base, Temporal, and Environmental. CVSS v4.0 changes this structure to Base, Threat, Environmental, and Supplemental. The Base group captures the intrinsic properties of the vulnerability, constant over time and environment. The remaining groups are meant to adapt this base value to the real-world situation - and this is exactly where most organizations stop.

In practice, the NVD publishes only Base metrics; according to NIST, Threat, Temporal, and Environmental values are not provided because they are environment- and time-dependent. A published score is therefore almost always a pure Base Score - deliberately the pessimistic starting value that still awaits adaptation by the consumer.

DimensionCVSS BaseEPSSBusiness Impact (OWASP)
QuestionHow severe is the flaw technically?How likely is it to be exploited?What does exploitation cost the business?
Value range0.0 to 10.0 (None to Critical)0 to 1 (probability)qualitative, organization-specific
PublisherFIRST.Org / NVDFIRST.OrgThe organization itself, framework from OWASP
Update frequencystatic per vulnerabilitydaily, 30-day horizonon context or data change
Weakness for API logic flawsignores the data value behind the objectonly available for CVE entriesrequires manual assessment

CVSS severity, EPSS, and business impact compared

Severity levels and the vector

CVSS optionally maps the numeric value onto qualitative severity levels. The thresholds are identical in v3.1 and v4.0: None at 0.0, Low at 0.1-3.9, Medium at 4.0-6.9, High at 7.0-8.9, and Critical at 9.0-10.0. The Info level common in many tools is not part of the CVSS specification, but a convention used by scanners and pentest tools for findings without a direct severity rating.

Every assessment is additionally expressed as a vector string - a compact, traceable notation of all the metric values used. A v3.1 vector looks something like this: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N. In v4.0, the Scope metric is dropped; instead, impacts are captured separately for the Vulnerable System (VC/VI/VA) and the Subsequent System (SC/SI/SA), and the new metric Attack Requirements (AT) is added. A complete Base vector then reads CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N.

Important for communication: v4.0 introduces a nomenclature that discloses which groups went into the value - CVSS-B (Base only), CVSS-BT (Base and Threat), CVSS-BE (Base and Environmental), and CVSS-BTE (all three). This label is meant to be carried along with every displayed value, so it's clear whether it's the raw base value or an assessment adapted to the environment.

Why CVSS underestimates API logic flaws

CVSS was designed for classic, technical vulnerabilities - memory errors, injection, missing authentication. With API logic flaws, the model hits a fundamental limit: it assesses the technical severity of the mechanism, not the business value of the data and functions behind it.

The clearest example is BOLA (Broken Object Level Authorization, API1:2023). OWASP rates BOLA as Exploitability: Easy, Prevalence: Widespread, Detectability: Easy, and Technical Impact: Moderate - the business impact, however, is explicitly classified as Business Specific. The attack itself is trivial: an attacker manipulates an object ID in the request and accesses other people's records. How much this matters depends entirely on what stands behind the object - a harmless display setting, or the health data, revenue figures, or vehicle controls of thousands of users.

A Base Score simply cannot capture this context. Mass data exposure via a GET endpoint appears as a Confidentiality impact, without knowing the factor that the same gap is iterable across all objects and thereby exposes the entire dataset. BFLA (missing function-level authorization) and flaws in Business Flows share this same pattern too: technically unremarkable, potentially existential for the business. Anyone who prioritizes purely by CVSS value systematically pushes such findings to the back - even though, according to OWASP, they are among the most common and consequential API risks.

Combining business impact and EPSS

A solid prioritization only emerges once the CVSS severity is supplemented with two dimensions: the likelihood of exploitation and the business impact.

For likelihood, EPSS (Exploit Prediction Scoring System, also from FIRST.Org) provides an empirical value. EPSS estimates, as a probability between 0 and 1, that a published CVE will be exploited in the wild within the next 30 days, and updates this value daily. EPSS replaces subjective severity judgments with observed exploitation signals, and is thus a sensible complement, not a replacement, for CVSS: CVSS says how bad it would be, EPSS says how likely it is to happen. It's worth noting that EPSS is tied to CVE entries and simply provides no value for most API logic flaws, which don't receive a CVE.

For business impact, the OWASP Risk Rating Methodology offers a simple framework: Risk = Likelihood × Impact, where the impact breaks down into Technical Impact (confidentiality, integrity, availability, accountability) and Business Impact (financial damage, reputational damage, legal consequences, data protection violation). OWASP stresses that this model must be adapted to the respective organization - what is technically a Medium can be a business Critical if personal data is affected and GDPR reporting obligations therefore apply.

Prioritizing findings in practice

For prioritizing API findings, a three-step approach has proven effective, using CVSS as an input but not as the sole decision:

  1. Determine severity (CVSS Base): establish the technical base value and vector and label it clearly as CVSS-B, so no one mistakes it for a finished risk assessment.
  2. Account for the environment (Environmental, business impact): adapt the Base Score to the specific API using the Environmental metrics and the OWASP factors - which data, which user groups, which compliance obligations are attached to the finding? For BOLA and BFLA, this step is the one that actually decides the matter.
  3. Weight likelihood (EPSS, Threat): where a CVE exists, draw on EPSS and the Threat metric Exploit Maturity (the stage of exploit availability) to prioritize known and actively exploited vulnerabilities.

For logic flaws with no CVE, the manual insight gained from an API penetration test replaces the missing EPSS data: only actually tracing through the attack path shows whether a BOLA gap is iterable across all objects, or whether a business flow can be abused. The CVSS value then documents the technical severity; prioritization follows from the demonstrated business impact. This connection between a measurable finding and a traceable assessment is also the core of Why API Security as a discipline in its own right: generic severity values alone do not capture the specific risks of an interface.

Sources

Keep reading
ReferenceOWASP API Security Top 10 API1Broken Object Level Authorization FundamentalsWhy API Security