To see an EPSS score from a past day, add a date in the form YYYY-MM-DD to the FIRST EPSS API query for one CVE or a small batch. For bulk work, use the daily files in the public archive, which start on 2021-04-14. Both let you reconstruct what the score said when you decided.
Why you would want to
Someone asks, three months later, why a CVE sat in the backlog. Today's score cannot answer that, because scores change daily. What you need is the score on the day of the decision, plus what else you knew then. FIRST's own data page describes this use: pinning a request to a past date is useful when reconstructing a prioritization decision.
Option 1: the API for a few CVEs
The EPSS endpoint is https://api.first.org/data/v1/epss. Its documentation, which still marks the endpoint as beta, lists these filters.
| Parameter | What it does |
|---|---|
| cve | One or more CVE IDs separated by commas, up to 2000 characters |
| date | A date since 14 April 2021 showing the historic epss and percentile |
| scope=time-series | The last 30 days of score and percentile for a CVE |
| epss-gt, epss-lt | Filter by score |
| percentile-gt, percentile-lt | Filter by percentile |
A request for a past day looks like this.
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-40438&date=2022-02-28&pretty=true"
The response lists the cve, the epss value, the percentile and the date. The values come back as strings, so convert them before you compare.
Option 2: the archive for many CVEs
FIRST says the API is built for lookup, not bulk access, and should not be used to keep a local copy of all scores. For many CVEs or a long series, use the full daily archive that the data page points to on GitHub. Each file holds one day's scored population in the same three fields as the current CSV: cve, epss and percentile.
A simple routine looks like this.
- Decide the date you need, usually the ticket creation date or the date a patch was approved.
- Fetch that day's file from the archive.
- Filter the file to the CVEs in your inventory.
- Save the result next to the ticket, with the file name and model version header.
Watch for model version boundaries
The data page warns that each model version caused a score shift on the date it started publishing. If you compare a past score to a current one, check the version of each. A difference across a boundary may reflect the method. See why a score history jumps when the model changes.
What to save with the score
A score alone is thin evidence. Record the following at decision time.
- The EPSS probability and percentile, and the file date.
- Whether the CVE was on the CISA KEV list that day.
- Whether you had confirmed the component was present and reachable.
- The decision, the owner and the next review date.
That small record turns a vague memory into something an auditor or a new teammate can read. It also protects you from hindsight: a score that looks obviously high today may have been low on the day you chose.
Safeguard's SBOM and dependency scanning give you the presence record, and reachability analysis the second check, so the decision file holds your facts as well as the public score. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Step through the check and notice which facts about your own code would belong in the decision record beside the EPSS score.
Quick check
How far back do EPSS historical scores go?
The API documentation says the date parameter works for dates since 14 April 2021, and the archive files are available back to 2021-04-14.
Can I get a 30-day trend for one CVE in a single call?
Yes. The time-series scope returns the last 30 days, or what is available, of score and percentile for a CVE.
Sources
Last reviewed: 19 October 2026.
