Wiki · Concept · Last reviewed July 10, 2026

Common Vulnerability Scoring System (CVSS)

CVSS is FIRST's open framework for communicating vulnerability characteristics and technical severity, using scores and vector strings that make scoring assumptions inspectable. It is a severity language, not a complete risk decision.

Category: Concept Published: June 25, 2026 Modified: July 10, 2026 Last reviewed: July 10, 2026 Tags: AI security, CVSS, vulnerability scoring, CVE, EPSS, governance

Snapshot

Maintainer: Forum of Incident Response and Security Teams (FIRST), through the CVSS Special Interest Group.
Current version: CVSS v4.0, with the official specification at document version 1.2 and a separate Consumer Implementation Guide.
Output: a 0.0 to 10.0 numerical severity score, a qualitative severity band, and a vector string that records the selected metric values.
Core distinction: CVSS Base severity is not local risk; deployment-specific decisions need Threat, Environmental, and organizational context.
AI relevance: AI systems inherit ordinary CVEs through packages, containers, browsers, model gateways, tool servers, identity systems, and observability agents.

Definition

The Common Vulnerability Scoring System (CVSS) is an open framework, owned and managed by FIRST, for communicating the characteristics and severity of vulnerabilities in software, hardware, and firmware. FIRST states that CVSS is currently at version 4.0 and that CVSS v4.0 resources include the specification, user guide, examples, calculator, FAQ, implementation guide, and data representations.

CVSS is not the same thing as CVE. CVE names a publicly disclosed vulnerability. CVSS describes the technical severity of a vulnerability through metric values, a score, and a vector string. It also is not the same thing as EPSS, SSVC, CISA KEV, VEX, or an organizational risk decision. Those artifacts answer adjacent questions: exploitation likelihood, decision priority, known exploitation, affected status, local exposure, or mission consequence.

The vector is the evidence-bearing part. Two vulnerabilities can share the same numerical score while having different attack paths, privilege requirements, user-interaction assumptions, vulnerable-system impacts, subsequent-system impacts, threat evidence, and environmental constraints. A score without the vector is a summary without its reasoning.

Boundary Tests

Not a vulnerability identifier: CVSS does not name the issue; CVE, advisory IDs, package identifiers, and vendor records do that.
Not exploit probability: CVSS can include Threat metrics, but EPSS is the dedicated FIRST signal for 30-day exploitation likelihood across CVEs.
Not known exploitation: CISA KEV indicates CISA-validated exploitation in the wild. A high CVSS score and a KEV listing are different evidence types.
Not affected status: CVSS does not say whether a specific product build or deployment is affected; VEX, testing, inventory, and vendor advisories answer that question.
Not patch priority by itself: CVSS Base is a severity baseline. Priority also depends on exposure, exploit evidence, compensating controls, asset criticality, safety impact, legal duties, and operational capacity.
Not interchangeable across versions: CVSS v3.1 and v4.0 vectors use different metric structures. Store the version explicitly and avoid mixing scores in one field.

How It Works

CVSS v4.0 uses four metric groups: Base, Threat, Environmental, and Supplemental. Base metrics describe intrinsic characteristics that are relatively stable across time and environments, such as exploitability and impact. Threat metrics account for changing evidence such as proof-of-concept availability or active exploitation. Environmental metrics adapt severity to a particular deployment. Supplemental metrics add context without changing the final score.

A CVSS assessment produces a numerical value from 0.0 to 10.0 and a vector string. The vector matters because the number alone hides the assumptions. FIRST's guidance asks publishers to provide both the score and the vector string so consumers can see how the score was derived. The v4.0 user guide also distinguishes score nomenclature such as CVSS-B, CVSS-BT, CVSS-BE, and CVSS-BTE, depending on whether Base, Threat, and Environmental metrics were used.

CVSS v4.0 also changed the shape of severity evidence. It separates impact on the vulnerable system from impact on subsequent systems, uses Attack Requirements alongside Attack Complexity, and treats Supplemental metrics such as Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, and Provider Urgency as contextual signals rather than score-changing inputs.

CVSS is strongest when a consumer enriches the Base score. FIRST's Consumer Implementation Guide strongly recommends using Threat and Environmental metrics to move from generalized Base assumptions toward deployment-specific severity. A published Base score can help normalize severity across advisories, but it cannot know whether a given AI deployment exposes the vulnerable component to the internet, connects it to sensitive data, or wraps it in an agent with privileged tools.

Current Context

As of July 10, 2026, CVSS v4.0 is the current FIRST standard. FIRST says the CVSS SIG is continuing to update documentation and examples after the initial November 2023 release, and NIST's National Vulnerability Database supports CVSS v4.0 data on vulnerability detail pages, search results, and its calculator when v4.0 data is available through NVD enrichment or CVE Program CNA or ADP contributions.

The policy context has moved away from treating CVSS as a standalone federal patch queue. CISA's Binding Operational Directive 26-04, issued June 10, 2026, supersedes BOD 19-02 and BOD 22-01 for Federal Civilian Executive Branch agencies. Its remediation urgency model uses asset exposure, KEV status, exploit automation, and technical impact. CISA's implementation guidance states that the directive no longer requires CVSS use for FCEB vulnerability prioritization, while still aligning with FIRST guidance that mature prioritization uses technical, threat, and environmental information.

The practical result is not that CVSS is obsolete. It is that CVSS is one column in a vulnerability decision record. The strongest 2026 workflow joins CVSS-B or enriched CVSS-BTE vectors to CVE identity, EPSS probability, KEV status, SSVC decision values, VEX affected status, SBOM or AI bill-of-materials evidence, public exposure, owner, exception rationale, and retest proof.

Agent Context

AI stacks make severity translation harder. A vulnerability in a package, vector database, model gateway, container image, browser automation layer, or tool server may be scored as an ordinary software flaw. Its operational impact changes when an agent can reach it, chain it with instructions, retrieve secrets, call APIs, or act under delegated identity.

For example, a browser-engine CVE can mean one thing inside a locked-down desktop and another inside a browser agent that visits untrusted pages while holding authenticated sessions. A deserialization flaw in a tool server can mean one thing in a lab and another when an autonomous workflow can submit inputs, read outputs, and pass retrieved data to downstream systems.

CVSS still belongs in the agent-security record because it captures the baseline technical shape of the flaw. It should then sit beside agent-specific evidence: tool permissions, memory scope, model route, sandbox boundary, identity provider, network exposure, observed exploitation, and whether the vulnerable code is present and reachable. For AI-specific amplification, OWASP AIVSS can use CVSS v4.0 as a technical baseline before adding agentic factors.

Governance and Safety

A governance-grade CVSS record should preserve the CVSS version, score, vector string, scorer, source URL, scoring date, affected CVE, product or package identity, affected version, evidence for each selected metric, and whether Threat or Environmental metrics were applied. If a scanner imports a vendor score, the record should say so rather than pretending the organization performed its own environmental assessment.

CVSS should not be used as a patch queue by itself. A severe vulnerability in an unreachable test system may be less urgent than a lower-scored flaw in a public agent tool with active exploitation. CISA's Known Exploited Vulnerabilities Catalog gives a separate signal for vulnerabilities exploited in the wild, while EPSS estimates exploitation likelihood and VEX can state product-specific affected status. CVSS supplies severity, not the whole decision.

Safety-sensitive and regulated deployments require extra care. CVSS v4.0 can carry Supplemental and Environmental safety context, but the score still has to be connected to system inventory, compensating controls, incident response, change management, and ownership. A medical device, industrial controller, identity service, election system, or AI agent with production write access can need escalation even when a raw Base score is not the highest item in the backlog.

Minimum Scoring Record

A useful CVSS record leaves enough evidence for a later reviewer to reconstruct the judgment rather than merely see a number copied from a scanner.

Vulnerability identity: CVE or advisory ID, affected product, package or component identifier, version evidence, vendor advisory, and disclosure date.
CVSS evidence: CVSS version, nomenclature such as CVSS-B or CVSS-BTE, numerical score, vector string, scorer, scoring source, scoring date, and rationale for non-obvious metric choices.
Threat evidence: EPSS score and date, KEV status, proof-of-concept or active-exploitation evidence, exploit automation evidence, and threat-intelligence source.
Environmental evidence: asset owner, public exposure, authentication boundary, reachable code path, compensating controls, data sensitivity, safety impact, agent tool access, and recovery constraints.
Decision evidence: patch, mitigation, removal, monitoring, exception, or acceptance decision; deadline; reviewer; rollback plan; retest result; and reassessment trigger.

Defense Pattern

Store the vector. A score without the vector is hard to audit, compare, or update.
Name the version. Do not mix CVSS v3.1 and v4.0 vectors or formulas in the same field.
Use the nomenclature. Label whether the score is CVSS-B, CVSS-BT, CVSS-BE, or CVSS-BTE so readers know which metric groups were applied.
Separate severity from risk. Add exposure, exploit evidence, asset criticality, data sensitivity, safety impact, and owner judgment.
Use local environment metrics. Base scores are useful, but deployment-specific controls and impacts change priority.
Preserve source provenance. Say whether the score came from FIRST guidance, a vendor advisory, NVD enrichment, a CNA/ADP contribution, a scanner, or a local analyst.
Re-score after architecture changes. Agent permissions, public exposure, compensating controls, data flows, or safety use can change the meaningful record.

Source Discipline

Claims about CVSS should cite FIRST's CVSS SIG, the exact specification version, or a linked FIRST resource. A vendor advisory may provide a valid CVSS score, but it is still a score from that source. A scanner may import, override, or recalculate scores. Those choices should be visible in the vulnerability record.

Current product and policy claims need their own sources. Use FIRST for the scoring standard, NVD for NVD enrichment behavior, CISA for KEV, Vulnrichment, SSVC, or BOD 26-04 requirements, OWASP for AIVSS, and vendor advisories or VEX statements for product-specific affected status. A secondary dashboard is not enough for a governance record unless it preserves the underlying source.

CVSS should not be confused with CVE identity, CPE or PURL package identity, SBOM contents, exploit prediction, known-exploited status, VEX status, or AI-specific scoring. Good triage keeps these fields separate and joins them deliberately.

Spiralist Reading

Spiralism reads CVSS as a ritual for making technical judgment legible. The number is not the truth. The vector is closer to the truth because it exposes the assumptions that produced the number.

In agentic systems, the deeper lesson is humility about inherited metrics. A machine that can act through tools changes the local meaning of a software flaw. CVSS gives the first grammar. Governance has to finish the sentence.

Open Questions

How often will organizations apply Threat and Environmental metrics rather than stopping at published Base scores?
How should CVSS vectors be represented inside SBOM, VEX, SPDX, CycloneDX, and AI-SBOM workflows?
Which agent-specific conditions should trigger re-scoring or an AIVSS assessment?
How can vulnerability queues show CVSS, EPSS, KEV, VEX, and exposure without collapsing them into one opaque score?

Sources

FIRST, Common Vulnerability Scoring System SIG, reviewed July 10, 2026.
FIRST, Common Vulnerability Scoring System version 4.0 Specification Document, document version 1.2, reviewed July 10, 2026.
FIRST, Common Vulnerability Scoring System version 4.0 User Guide, reviewed July 10, 2026.
FIRST, Common Vulnerability Scoring System version 4.0 Consumer Implementation Guide, document version 1.0, reviewed July 10, 2026.
FIRST, Common Vulnerability Scoring System version 4.0 Examples, reviewed July 10, 2026.
FIRST, Common Vulnerability Scoring System version 4.0 Calculator, reviewed July 10, 2026.
NIST National Vulnerability Database, CVSS v4.0 Official Support, June 27, 2024, reviewed July 10, 2026.
CISA, Known Exploited Vulnerabilities Catalog, reviewed July 10, 2026.
CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026, reviewed July 10, 2026.
CISA, BOD 26-04 Implementation Guidance, reviewed July 10, 2026.
FIRST, Exploit Prediction Scoring System, reviewed July 10, 2026.
OWASP Foundation, OWASP AI Vulnerability Scoring System, reviewed July 10, 2026.

Return to Wiki