Vulnerability

A vulnerability is a weakness or flaw in software that can be exploited to compromise the security, functionality, or integrity of a system.

To manage vulnerabilities at scale, the industry has developed complementary systems: databases to catalog them, identifiers to reference them uniquely, scoring frameworks to evaluate their severity, and models to predict real-world exploitation.

This page walks through each of these building blocks.

CVE Identifier

CVE (Common Vulnerabilities and Exposures) is a system managed by MITRE Corporation and funded by CISA Cybersecurity and Infrastructure Security Agency .

It assigns a unique reference number in the format CVE-YYYY-NNNNN (e.g., CVE-2021-44228 for Log4Shell).

This common identifier lets security teams worldwide reference the same vulnerability unambiguously.

CWE

CWE (Common Weakness Enumeration)* is a catalog of software weakness categories, also maintained by MITRE.

Where a CVE identifies a specific vulnerability instance, a CWE describes the underlying type of weakness that caused it.

For example, Log4Shell (CVE-2021-44228) is classified as [CWE-917] (Expression Language Injection).

Once a vulnerability is identified, the next question is: how severe is it?

CVSS

Not all vulnerabilities pose the same risk.

CVSS (Common Vulnerability Scoring System), developed and maintained by FIRST (Forum of Incident Response and Security Teams), helps teams prioritize which vulnerabilities to address first based on a score from 0.0 to 10.0.

FIRST defines the scoring methodology.

For each CVE, the base score is primarily assigned by analysts at the NVD (operated by NIST) and published in the NVD database.

Vendors and CNAs (CVE Numbering Authorities) may also publish their own scores.

Base Metrics

The Base Score is computed from these intrinsic characteristics of the vulnerability, which do not change over time:

• Attack Vector AV (network, adjacent, local, physical)
• Attack Complexity AC (low or high)
• Privileges Required PR (none, low, high)
• User Interaction UI (none or required)
• Scope S (unchanged or changed)
• Impact on Confidentiality C, Integrity I, Availability A

Temporal Metrics

Temporal Metrics adjust the Base Score based on how the situation around a vulnerability evolves:

• Exploit Code Maturity: is working exploit code publicly available?
• Remediation Level: has an official patch been released?
• Report Confidence: how well-confirmed is the vulnerability?

CVSS Score Ranges

Based on CVSS v3.1:

CVSS versions

Currently CVSS v3.1 is most commonly used, with CVSS v4.0 gradually being adopted.

Key Differences

CVSS has evolved over time to better reflect real-world exploitation.

Understanding the differences matters because the same vulnerability may have different scores depending on the version used.

CVSS v3.1 (released 2019):

• Well-established, widely adopted across industry
• Three metric groups: Base , Temporal , Environmental (optional)
• Score range: 0.0-10.0
• Focuses on technical severity of the vulnerability itself

CVSS v4.0 (released November 2023):

• New nomenclature:
  • Base → Base
  • Temporal → Threat
  • Environmental → Environmental + Supplemental
• Improved granularity: More nuanced scoring options for complex scenarios
• New metrics: Including Attack Requirements (AT), User Interaction, and Provider Urgency (U)..
• Better OT/ICS support: Addresses operational technology and critical infrastructure use cases
• Improved threat metrics: Better alignment with real-world exploitation patterns
• Score consistency improvements: Addresses some scoring anomalies from v3.1

Migration Timeline

• Transition period: 2024-2025 where both versions coexist
• Expected full adoption: 2026-2027 for most tooling and databases

Note that most SCA tools still primarily report CVSS v3.1 scores.

CVSS measures technical severity, but it does not predict whether a vulnerability will actually be exploited. The next framework addresses that gap.

EPSS

EPSS (Exploit Prediction Scoring System), also a FIRST project driven by a community of researchers, complements CVSS by predicting the likelihood that a vulnerability will be exploited in the wild within the next 30 days.

FIRST computes and publishes a daily EPSS score for every known CVE. Scores are freely available through the EPSS API and range from 0% to 100%.

What EPSS measures

• Exploit code availability and maturity
• Historical exploitation patterns
• Vulnerability characteristics
• Social media and dark web chatter
• Observed exploitation activity

Example interpretation

• EPSS score of 2%: Low probability of exploitation
• EPSS score of 50%: Moderate probability
• EPSS score of 90%+: Very high probability, likely actively exploited

KEV

KEV (Known Exploited Vulnerabilities) is a catalog maintained by CISA listing vulnerabilities that are actively being exploited in the wild. While EPSS predicts the probability of exploitation, the KEV catalog provides factual confirmation that a vulnerability is actively exploited. Key characteristics:

• Authoritative confirmation of active exploitation
• Includes binding operational directives for US federal agencies
• Typically includes remediation deadlines
• Updated regularly based on real-world threat intelligence

If a vulnerability appears in KEV, it should be treated as the highest priority regardless of CVSS score, as it represents confirmed active threat actor activity.

To see how CVE, CVSS, EPSS, and KEV come together in practice, consider the following real-world case.

Reachability Analysis

Reachability analysis determines whether your application actually uses the vulnerable code within a dependency.

Why it matters

• Reduces false positives and alert fatigue
• Helps prioritize remediation on vulnerabilities you can actually trigger
• Many reported vulnerabilities exist in code paths never executed by your application

Limitations

• Complex and not foolproof
• Indirect calls or future code changes could activate the vulnerability
• Requires advanced tooling - not all SCA tools provide this capability

Example: Log4Shell (CVE-2021-44228)

• CVSS Score: 10.0 (Critical)
• EPSS Score: 97.5% (when first disclosed)
• KEV Status: Yes, actively exploited
• Result: Highest possible priority requiring immediate remediation

This combination of maximum severity, near-certain exploitation probability, and confirmed active exploitation made Log4Shell one of the most critical vulnerabilities ever disclosed.

All of these systems feed into the tools that development teams use daily. Here is how SCA tools combine them.

How SCA Tools Use Vulnerability Data

Software Composition Analysis tools help organizations identify and prioritize vulnerabilities by combining multiple data sources:

• Component Matching: Scan components in your SBOM against CVE databases
• Severity Assessment: Retrieve CVSS scores published in the NVD to indicate severity
• Likelihood Estimation: Retrieve EPSS scores published by FIRST to assess the probability that a vulnerability will be exploited in the wild
• Threat Awareness: Flag components listed in the CISA KEV catalog to highlight vulnerabilities that are actively being exploited
• Remediation Prioritization: Combine severity (CVSS), exploitation likelihood (EPSS), and confirmed exploitation (KEV) to provide prioritized remediation recommendations

Vulnerability Indicators by Tool

Legend: ✅ Native | ⚠️ Limited | ❌ Not available | 🔜 Planned

Vulnerability Data Sources

Information about vulnerabilities is scattered across multiple sources, from initial disclosures by maintainers and researchers to aggregated databases consumed by security tools.

• Primary declaration (where maintainers/researchers first report):
  • Vendor security advisories (RustSec , npm Security Advisories, etc.)
  • GitHub repository advisories (maintainers publish directly)
  • CVE List (MITRE) - official registry
  • NVD (NIST) - ingests CVEs, enriches with scores (2-7 days lag)
• Aggregated for tools (consolidated for tool consumption):
  • GitHub Advisory Database : Aggregates NVD, vendor advisories + maintains reviewed advisories for supported ecosystems.
  • TrivyDB: Aggregates NVD, GitHub Advisories for Trivy scanner
  • GitLab Advisories: Aggregates GitHub Advisories + NVD for supported package managers (npm, Maven, PyPI, etc.)
  • JFrog Xray: Aggregates NVD + ecosystem-specific advisories for artifact scanning
• Commercial enrichment (proprietary research ahead of public databases):
  • Black Duck BDSA: Detects and publishes advisories 2-8 weeks ahead of NVD through independent monitoring