Add a historical chart to visualize EPSS score trends over time

[ziadhany]

• We should first design a way to store EPSS history data.
• Create a chart to visualize the EPSS trend (score changes over time).

Related issue:

• VulnerableCode Insights #1276
• Improve display of the Severity table of the Essentials screen #1732

[shivamshrma09]

Hi @ziadhany,
I think this is a great idea Visualizing the trend through a chart will help developers quickly understand how a package's exploitability is evolving over time.

Here is my proposed plan:

• Storage: Add an EPSSHistory model to store daily snapshots (date, score, percentile) to ensure we maintain historical data instead of overwriting it.
• Pipeline: Build a daily Importer to fetch data from FIRST.org and an Improver to link it to existing vulnerabilities.
• Frontend: Integrate Chart.js in the vulnerability detail view to visualize the EPSS trend.

am i on right track?

[mmareg001]

Hi @shivamshrma09, I am also interested in contributing to this project for GSoC 2026.

Regarding your second point on pipeline, VulnerableCode already has a daily EPSS importer that fetches data from FIRST.org (if you review https://github.com/aboutcode-org/vulnerablecode/blob/main/vulnerabilities/importers/epss.py). So instead of building a new importer, we can extend the existing one or adjust how the output is stored.

I do agree on your point on storage. Creating a EPSSHistory model that stores the data collected from the daily importer eg: EPSS score, EPSS percentile and CVE id will allow us to store daily snapshots and historical data instead of overwriting it. This aligns well with the project requirement of understanding score changes over time.

I also agree on your point on frontend. Something like Chart.js or Plotly could handle the visualization. We just need an API endpoint that returns the date, EPSS score and percentile for a given CVE.

Anyways, I am still doing more research on this and @ziadhany can advise more.

[shivamshrma09]

Thanks for pointing that out, @mmareg001! You're right, leveraging the existing EPSS importer makes much more sense than building a new one from scratch. We can focus on updating the storage logic to use the new EPSSHistory model and then work on the API/Frontend.

@ziadhany, would you prefer us to extend the current importer or keep the history tracking as a separate 'Improver' task?

[ziadhany]

@shivamshrma09 we should first run EPSSImporterPipeline twice and check the data. I don’t think we should add a new model. If a new AdvisoryDataV2 object is created for each run when we run EPSSImporterPipeline, we should first review the data workflow and see if we can implement this without introducing a new model or affecting other importers. I think that would be better. (So I think there’s no need to edit the importer either.)

see EPSSImporterPipeline:

• https://github.com/aboutcode-org/vulnerablecode/blob/main/vulnerabilities/pipelines/v2_importers/epss_importer_v2.py

• vulnerablecode/vulnerabilities/pipes/advisory.py

  Line 292 in 74172c4

  def insert_advisory_v2(

Also, using Chart.js could be a good approach but it introduces an additional dependency. so I think we should handle this as part of:

• VulnerableCode Insights #1276