unassigned severity while the score is set for the vulnerability

[hqbns]

Current Behavior

Hey guys,
I am using Dependecy track for a project and I just noticed that some vulnerabilities have the unassigned status while when you search the vulnerability on the NVD you see the actual score of the vulnerability.
Also, the link that Dependecy track gives you on the vulnerability clearly says the severity of the vulnerability so I do not understand why the status is unassigned .

Steps to Reproduce

1.upload a BOM with windows 10 family edition (version: 10.0.19045.3930)
2. Watch the latest vulnerabilities
The BOM I use only has windows family edition and here are some screenshots has an example of the issue.

Expected Behavior

I would expect to have the severity of the CVE instead of (UNASSIGNED ) as is it shown in NVD database.

Dependency-Track Version

4.12.6

Dependency-Track Distribution

Executable WAR

Database Server

H2

Database Server Version

No response

Browser

Mozilla Firefox

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[stohrendorf]

Could you check that this behaviour persists with setting the environment variable ALPINE_DATANUCLEUS_CACHE_LEVEL2_TYPE=none? In my own experience, the L2 cache produces strange errors at times similar to this one (it will be fixed in 4.13). If you can't change the configuration, try to re-start DT, since that will clear the cache, too.

[JoaquinDelgadoCarrascal]

Could you check that this behaviour persists with setting the environment variable ALPINE_DATANUCLEUS_CACHE_LEVEL2_TYPE=none? In my own experience, the L2 cache produces strange errors at times similar to this one (it will be fixed in 4.13). If you can't change the configuration, try to re-start DT, since that will clear the cache, too.

Hi @stohrendorf, I tried that and still doesn't work for me. Not even doing the export but also putting it as a restart option.

[hqbns]

Could you check that this behaviour persists with setting the environment variable ALPINE_DATANUCLEUS_CACHE_LEVEL2_TYPE=none? In my own experience, the L2 cache produces strange errors at times similar to this one (it will be fixed in 4.13). If you can't change the configuration, try to re-start DT, since that will clear the cache, too.

Hey @stohrendorf yes even when this parameter is set to none the problem persist form me.
Restarting DT does not work either