Wiki · Concept · Last reviewed June 25, 2026

Exploit Prediction Scoring System

The Exploit Prediction Scoring System, usually shortened to EPSS, is a FIRST project that estimates how likely a published CVE is to be exploited in the wild during the next 30 days.

Category: Concept Updated: June 25, 2026 Tags: AI security, vulnerability management, EPSS, CVSS, exploit prediction, governance

Definition

The Exploit Prediction Scoring System (EPSS) is a FIRST Special Interest Group project for estimating exploit likelihood for vulnerabilities identified by CVE. FIRST describes EPSS as a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days.

EPSS is not the same thing as CVSS, a proof of compromise, a vulnerability disclosure process, or a legal duty to patch. CVSS captures severity characteristics of a vulnerability. EPSS asks a narrower operational question: given current evidence and model features, how likely is this CVE to see observed exploitation soon?

For AI and agent systems, EPSS matters because modern AI stacks still depend on ordinary software: browsers, containers, model-serving services, identity providers, package managers, vector databases, orchestration layers, and tool servers.

How It Works

FIRST publishes an EPSS score for every CVE on a daily basis. The current data feed includes a CVE identifier, an EPSS value, and a percentile. The EPSS value is a probability between 0 and 1. The percentile shows where that score sits relative to other scored vulnerabilities.

The distinction between probability and percentile is important. A probability is the model's estimate of observed exploitation in the next 30 days. A percentile is a rank position. A vulnerability can have a small absolute probability while still ranking high compared with the long tail of low-likelihood CVEs. FIRST's guidance recommends communicating the probability as the main EPSS score and adding the percentile when it helps explain relative priority.

EPSS does not replace severity scoring. A low-severity vulnerability with a high EPSS score may need fast attention because exploitation is likely. A severe vulnerability with a low EPSS score may still matter because it affects a central identity service, public-facing model gateway, or regulated data system. The useful triage record keeps EPSS beside CVSS, asset exposure, business context, exploit evidence, and compensating controls.

Agent Context

Agentic systems create vulnerability-management pressure because they connect many ordinary services into action paths. A coding agent may touch repositories, package registries, CI logs, credentials, and local filesystem state. A browser agent may sit on top of browser engines, authentication sessions, screenshot pipelines, and task queues. A customer-service agent may combine retrieval, email, CRM access, and escalation tools.

EPSS helps triage the ordinary CVEs inside those paths. It does not capture prompt injection, unsafe delegation, memory poisoning, model behavior failures, weak tool authorization, or agent-specific escalation unless those problems are represented as CVEs. For that reason, EPSS belongs beside agent-specific review methods such as OWASP AI Vulnerability Scoring System, AI Agent Sandboxing, and AI Agent Observability.

Governance and Safety

A governance program can use EPSS as a dated triage signal. A good vulnerability record should preserve the CVE, EPSS probability, percentile, score date, severity source, affected asset, exposure, connected agent or model service, business owner, decision, exception rationale, and reassessment date.

The date matters because EPSS is refreshed daily. A score copied into a ticket without a timestamp may keep influencing decisions after the threat landscape changes. A mature program should recalculate, close stale exceptions, and show score drift when an ignored vulnerability becomes more likely to be exploited.

The governance risk is score automation without accountability. EPSS can improve prioritization, but it should not silently patch, defer, or accept risk by itself. Human owners still need to decide what happens when exploit likelihood, user impact, legal sensitivity, uptime risk, and operational capacity point in different directions.

Defense Pattern

Source Discipline

Claims about EPSS should cite FIRST material directly. The most important source distinction is between the official EPSS definition, the daily data fields, and explanatory guidance on probabilities and percentiles. Secondary dashboards can be useful for workflow, but they should not be treated as the source of the scoring method.

EPSS should also not be confused with AI Vulnerability Disclosure, CVE assignment, CVSS severity, known-exploited-vulnerability lists, or AI-specific scoring systems. Those artifacts can complement one another, but each answers a different governance question.

Spiralist Reading

Spiralism reads EPSS as a probability layer placed over institutional urgency. Security teams already know that not every vulnerability can be fixed first. EPSS makes one part of that triage explicit: the expected nearness of exploitation.

The number is useful when it sharpens responsibility. It is dangerous when it hides responsibility behind a dashboard. The healthy ritual is a documented argument over likelihood, exposure, severity, dependency, and the human owner willing to accept delay.

Open Questions

Sources

Return to Wiki