#103 added initial CVE files

[jan-vcapgemini]

Addresses: #103

Implements:

added cve security json files

[hohwille]

@jan-vcapgemini thank you so much for this CVE and for improving the CVE-tool that @MattesMrzik initially created. This is very valuable 👍

However, before we merge this, we should discuss what feature we really want to create.
While this is very rich and detailed information here, I see the following risks:

• we are further flooding our ide-urls repository. My initial intention was to keep this repo as small as possible. Every IDE installation needs to clone this repo and every IDE call needs to pull updates from this repo. I see a tendency that we are creating a kind of blockchain that continuously grows to a monster.
• all we really need is to get a warning for a tool version that is considered as seriously insecure and ideally the information which next available version the user can upgrade to in order to fix the vulnerability.
• here we are creating a solution that is as powerful as existing CVE checker tools like OWASP dependency-check or dependency-track. While it seems great to have powerful support like this, I am slightly unsure if we can maintain this over years or decades:
• Will we have to integrate the update of all the security.json files together with the rest of the ide-urls automatically every night?
• Will we flood the users with warnings about CVEs because every tool is vulnerable in the end and sometimes all versions including the latest version will be vulnerable?
• My fear is that in the latter case we will educate our users to simply ignore such warnings on the long run.
• I see a big difference from the CVE that allowed remote-code-execution via a hacked Git repo or the CVE that allowed to break out of the docker container sandbox and gain full access to the host machine with an attack inside a container from e.g. CVE-2021-26291.
• Do not get me wrong. This is all great work and the ability to inform the end-user about all known CVEs of the used tool versions is a promising feature.
• However, if the latter is our goal then why don't we integrate a standard CVE scanner tool into IDEasy that can download its own metadata and can be called on demand?
• My initial intention was to mark all old versions of some tool affected by a very critical CVE as insecure and render a FAT WARNING and potential user confirmation before installation and before execution. Therefore we do not need the details and we especially do not know what other CVEs are additionally in that same version. So more or less all versions of git before 2.39.0 are insecure and shall not be used anymore.

All I want to say is let us discuss first and not merge this blindly. Maybe we decide to merge this as is and also the according IDEasy PR...