Changes in score counting in UI

[carlosthe19916]

Context:

• Recent changes changed the API spec in regards of the scores
• The changes of the api spec were pushed to the UI at 🌱 [main] update client/openapi/trustd.yaml trustify-ui#984

UI e2e tests consequences:

• Testing of quarkus-bom vulnerability count changed:

  • From: 0 critical, 2 high, 13 medium, 1 low, 0 none, 0 unknown
  • To: 0 critical, 3 high, 10 medium, 1 low, 0 none, 2 unknown

• Old request: GET /api/v2/sbom/{id}/advisory response: old.json

• New request: GET /api/v3/sbom/{id}/advisory new.json

API Response Diff: old.json vs new.json

1. base_score is null for 3 items

These items had average_score/average_severity values in the old format but have base_score: null in the new:

Identifier	Old score	Old severity
CVE-2024-26308	5.5	medium
#CVE-2023-0044	5.3	medium
#CVE-2023-33201	5.3	medium

2. Score/Severity Value Differences

For 5 items, the base_score values differ from the old average_score/average_severity:

Identifier	Old score → New score	Old severity → New severity	Reason
GHSA-j288-q9x7-2f5v	6.5 → 5.3	medium → medium	Different base score
GHSA-prj3-ccx8-p6x4	7.5 → 8.2	high → high	Uses CVSS 4.0 instead of 3.1
#CVE-2023-24815	5.3 → 4.8	medium → medium	Different base score
#CVE-2023-2976	4.4 → 5.5	medium → medium	Different base score
#CVE-2023-34455	5.9 → 7.5	medium → high	Both score and severity changed

This suggests the old average_score was computed (e.g., averaging across all CVSS scores), while the new base_score picks a specific score (likely the highest-versioned CVSS or a designated "base").

3. One modified Date Change

CVE-2024-26308 status modified date changed: 2025-03-27T19:10:43.565Z → 2024-08-02T00:07:19.215Z (went backwards).

[carlosthe19916]

The data used for generating the previous responses are:

• Advisories: all files from https://github.com/guacsec/trustify-ui/tree/main/e2e/tests/common/dataset/advisory
• Sbom: https://github.com/guacsec/trustify-ui/blob/main/e2e/tests/common/dataset/sbom/quarkus-bom-2.13.8.Final-redhat-00004.json.bz2

[ctron]

I'm confused. It would be good if those tests would be in the trustify repo, so that we could find and fix such discrepancies when making backend changes. But I see the point that the UI needs tests too.

What I find weird is that the modified should have changed, as there was no change regarding that.

Just peeking at the first, CVE-2024-26308 doesn't have a CNA score, just and ADP one. Feels like having none as "base" makes sense in this case. But there could be additional ones.

[carlosthe19916]

I'm confused. It would be good if those tests would be in the trustify repo, so that we could find and fix such discrepancies when making backend changes. But I see the point that the UI needs tests too.

With AI it should be straightforward to create similar tests based on the ones that the UI has, but focusing only in the REST APIs. That's would be a good idea I think.

Just peeking at the first, CVE-2024-26308 doesn't have a CNA score, just and ADP one. Feels like having none as "base" makes sense in this case. But there could be additional ones.

So having base_score: null for CVE-2024-26308 seems correct right? No problem, thanks for the confirmation

[ctron]

CVE-2024-26308 doesn't seem to have any score.

For GHSA-j288-q9x7-2f5v I see a base score of 5.3 which is correct (but from the ADP) and a score of 6.5 from the advisory, which is correct too.

I did notice however, that the base score between the vulnerability and the "status" differs by the fact that one seems to include the ADP, while the other doesn't.

[ctron]

The modified date is indeed interesting, as this is the modification date from an ADP entry. which shouldn't affect the entry at all.

[ctron]

@carlosthe19916 which version did you compare? I assume "new" is the most recent main. What is "old"?

[carlosthe19916]

Old: GET /api/v2/sbom/{id}/advisory
New: GET /api/v3/sbom/{id}/advisory

So new is the most recent changes from main branch

And Old is the main branch without All the commits from today 10th April (around 14 commits) added today

[ctron]

What exactly is the "quarkus-bom"? Is it quarkus-bom-2.13.8.Final-redhat-00004.json.bz2?

[carlosthe19916]

The link to the sbom is in my comment above

[carlosthe19916]

So this one Sbom: https://github.com/guacsec/trustify-ui/blob/main/e2e/tests/common/dataset/sbom/quarkus-bom-2.13.8.Final-redhat-00004.json.bz2

[ctron]

I just reproduced the setup. Ingesting all advisories. Ingesting quarkus-bom-2.13.8.Final-redhat-00004.json.bz2. However, I get different results. And those look correct.

I'd like to understand how you ingest documents. As something seems off.

[carlosthe19916]

This is the specific block of code that does it https://github.com/guacsec/trustify-ui/blob/main/e2e/tests/api/dependencies/global.setup.ts#L14-L31

[carlosthe19916]

Ultimately is this function the one that uploads files https://github.com/guacsec/trustify-ui/blob/main/e2e/tests/api/helpers/general-helpers.ts#L5-L24

It is doing a POST to return /api/v2/{"sbom|advisory"} using "Content-Type": contentType

[ctron]

I'm neither a JS nor axios expert. How does it work?

[carlosthe19916]

Here is a plain curl script that does the same:

upload.zip

[ctron]

That looks like it's loading them one by one. I did that, and can't seem to reproduce the issue though.

[ctron]

This looks to me like a data issue. The test set contains a CVE file twice for the same CVE:

• https://github.com/guacsec/trustify-ui/blob/main/e2e/tests/common/dataset/advisory/cve/CVE-2024-26308-cve.json.bz2
• https://github.com/guacsec/trustify-ui/blob/main/e2e/tests/common/dataset/advisory/cve/cve-2024-26308.json.bz2

Depending on the order of ingestion, the tests fail or not.

A CVE project file however should not he there twice. But should be ingested in the correct order of being updated. That is ensured by the way CVE projects files are distributed.

My recommendation would be to fix the test data, and then test again, in order to verify.