Skip to content

Improve display of the Severity table of the Essentials screen #1732

Open

Description

@mjherzog

The Severity table on the Essentials screen is becoming very hard to read with so much data repeated at a row level.
One idea is to add a separate column for each System - Score combination and/or creating System subsections.
Using https://public.vulnerablecode.io/vulnerabilities/VCID-29te-f3et-aaac as an example:

  • There are many pairs of numeric and text scores from the same origin (URL). Since the text score is effectively an alias in these cases it would be better to see the cvss.31 and generic_textual values in separate columns on a single row for that origin. This is an extremely common pattern
  • With the increase in cvss versions and other systems it might also makes sense to have separate sections for cvss vs. epss especially because these scores are not comparable.

For this particular VCID there are also 15 instances (14 duplicates) for the epss Score

Activity

  1. self-assigned this
    on Aug 14, 2025
  2. ziadhany commented on Aug 14, 2025

    @ziadhany
    Member

    @mjherzog
    For VCID-29te-f3et-aaac, we have:

    • 91 EPSS values
    • 7 CVSS v3.1 values
    • 7 generic_textual values
    • 2 CVSS v3.1 qr values
    • 3 SSVC values/vectors

    The main issue here seems to be the large number of historical EPSS values, which makes the Severity table harder to read. Since we already have an EPSS tab, one possible solution would be to move all EPSS values into that tab and create a new section for example, EPSS History: with the 90 EPSS values and one url.

    or, we could add a separate column for each scoring system. Which approach do we prefer? I personally think having the EPSS tab contain all EPSS-related information would be better solution.

  3. mjherzog commented on Aug 17, 2025

    @mjherzog
    MemberAuthor

    @ziadhany For EPSS I think that we need to separate the data from the other Severity scores because it is a very different metric.
    And since it EPSS is time relative - "Specifically, EPSS is estimating the probability of observing any exploitation attempts against a vulnerability in the next 30 days." (https://www.first.org/epss/faq) it seems a good candidate for its own History tab.

    But, for the history I do not understand the data. For the example: https://public.vulnerablecode.io/vulnerabilities/VCID-29te-f3et-aaac there are several sets of items by EPSS Score but the "Found at:: URL is the same for all with the same data:

    {"status":"OK","status-code":200,"version":"1.0","access":"public","total":1,"offset":0,"limit":100,"data":[{"cve":"CVE-2024-39689","epss":"0.212330000","percentile":"0.954380000","date":"2025-08-17"}]}

    So it does not seem that we have useful historical data as currently presented.

  4. ziadhany commented on Aug 18, 2025

    @ziadhany
    Member

    @ziadhany For EPSS I think that we need to separate the data from the other Severity scores because it is a very different metric. And since it EPSS is time relative - "Specifically, EPSS is estimating the probability of observing any exploitation attempts against a vulnerability in the next 30 days." (https://www.first.org/epss/faq) it seems a good candidate for its own History tab.

    @mjherzog Agreed, we should not treat EPSS as just another severity score. A separate History tab is a good idea, and I also think a simple graph to show trends or sudden EPSS jumps would be very useful.

    But, for the history I do not understand the data. For the example: https://public.vulnerablecode.io/vulnerabilities/VCID-29te-f3et-aaac there are several sets of items by EPSS Score but the "Found at:: URL is the same for all with the same data:

    {"status":"OK","status-code":200,"version":"1.0","access":"public","total":1,"offset":0,"limit":100,"data":[{"cve":"CVE-2024-39689","epss":"0.212330000","percentile":"0.954380000","date":"2025-08-17"}]}

    So it does not seem that we have useful historical data as currently presented.

    {
        "cve": "CVE-2024-39689",   
        "epss": "0.212330000",         // Probability (21.2%) the CVE will be exploited in the next 30 days
        "percentile": "0.954380000",   // Rank compared to other CVEs (95.4th percentile, very high risk)
        "date": "2025-08-17"
    }
    

    So while we are storing the EPSS data correctly in the database (score, percentile, date, reference URL), the UI is currently showing only the score and URL, which makes it look like duplicate static data instead of a time series.

    I’m working on PR #1976 to sort EPSS entries by date, so we can start visualizing the data properly and build towards a useful history view.

  5. mjherzog commented on Aug 18, 2025

    @mjherzog
    MemberAuthor

    @ziadhany Sounds good and I expected the EPSS data to be a time-series, but I only see one date: 2025-08-17 ?

  6. ziadhany commented on Aug 19, 2025

    @ziadhany
    Member

    @ziadhany Sounds good and I expected the EPSS data to be a time-series, but I only see one date: 2025-08-17 ?

    @mjherzog Yes, EPSS is updated daily, and since it provides probabilities for the next 30 days, it can be considered a time series.

  7. mjherzog commented on Aug 19, 2025

    @mjherzog
    MemberAuthor

    So we should capture the actual date for each EPSS data point and show that in the history.

  8. ziadhany commented on Aug 19, 2025

    @ziadhany
    Member

    We are already doing that, but not on a daily basis (nor should it be necessary I think).
    My thought was that we could have a simple table or graph to display the data, while also showing the latest EPSS score in the EPSS tab.

    See for instance this: https://www.cvedetails.com/epss/CVE-2024-39689/epss-score-history.html`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions