As a IDEasy user, I want to get security warnings if I am using outdated software with critical known CVEs so that I can keep my software secure.

This is the devonfw-ide story 1106 to be implemented for IDEasy.

ATTENTION: There is a specialty for git that is not typically managed by IDEasy (what might change see #47). For this also have a look at the old PR implementing this story in devonfw-ide.

Design

We have decided that we need to create our own source of information for this.
The reason is that the public CVE databases are generic for every software and therefore extremely large and without a paid subscription the APIs are rate limited.
Therefore a simple solution to directly access the CVE databases e.g. from NVD in IDEasy (e.g. via owasp-dependency-check library) will not work smooth. When installing IDEasy the entire CVE database has to be downloaded by every user of IDEasy and that will not work because due to rate limits it will fail and has to be continued the other day so the database might only be available after weeks. We also tried various other alternatives or online search APIs.
However, we came to the point that we want to do the following:

In our ide-urls repository we want to have potential security.json files per tool/edition (analog to dependency.json - see #131). So for a specific tool, like git, java or maven, we would have such a file containing all the CVEs for that tool. Since we only manage a very small subset of tools we will end up with a small fraction from the large generic CVE database. Further, we do not need a view properties out of that:

• ID (the unique identifier of the vulnerability CVE-2024-32002)
• severity (a floating point number in the range (0,10.0] where 0 would be no risk and 10 would mean highest risk with catastrophic impact)
• affected versions (one or multiple version ranges of the tool that are affected)

From the ID we can already generate an URL to the CVE (e.g. https://nvd.nist.gov/vuln/detail/CVE-2024-32002) where the user can find all the further details with description, etc. so we do not need to store that (saving storage and bandwidth) nor maintain it (e.g. if the description may be updated with more details).

So my suggestion for the JSON would therefore be (example for git/git/security.json):

{
  issues: [
    {"id":"CVE-2024-32002",
     "severity":9.0,
     "versions":[
       "(0,2.39.4)", "[2.40.0,2.40.2)"
     ]}
  ]
}

The top-level object with only the property issues could be omitted but is there for potential future extensions. Other unknown properties should threrefore be ignored without causing an error.
The issues property is an array with any number of CVEs known for the tool/edition.
(it could also be an object where the key is the CVE-ID and the value are the other properties but this is more complex to parse and map to Java)
A CVE can have multiple version ranges affected and also for a given version of a tool multiple CVEs can apply.
Therefore the earlier JSON schema did not fit perfectly to solve the problem.

With this JSON schema defined, we can divide this story into two independent parts that share the JSON schema as their only API and dependency. See the sub-issues for that and further details.