## 2 Background  
The idea of a Common Vulnerability Enumeration (CVE) was introduced in 1999 [10]. The authors of the CVE concept recognized the need for a consistent, unified and universal method of vulnerability description that enables stakeholders to mitigate interoperability issues. Before CVE, each vulnerability was marked by an individual set of methods, designed with a specific product in mind [10; 11; 12]. Consequently, comparing data from various vendors and managing vulnerability systems was a highly time-consuming task [10; 12]. The CVE concept has gained widespread acceptance in both the literature and industry, to the extent that it is now integrated not only in intrusion detection systems (IDSs) [13], but also across various sectors of the cybersecurity landscape [14; 15; 16]. Since 1999, a large number of software vendors and non-profit organizations have been developing, promoting, and implementing a variety of competing vulnerability assessment systems, for example, X-Force [17], Symantec [18], Microsoft [19], Redhat [20], Mozilla [21], Secunia [22], Vulpen [23], Google [24], VRSS [23], and CVSS [25]. Currently, software vendors X-Force, Symantec, Microsoft, Redhat, Mozilla, and Google [17; 18; 19; 20; 21; 24] continue to maintain their research departments, while the Secunia solution [22] is no longer being developed, and VRSS [23] was not successfully approved. The Common Vulnerability Scoring System (CVSS) was first introduced as a research project by the National Infrastructure Advisory Council (NIAC) in 2005 [25]. Due to some concerns from early adopters, work on a new version of the standard has been initiated. As a result, CVSS in version 2.0 [26] was introduced in 2007. In the next years, organizations such as Risk-based Security and the Open Security Foundation have published an open letter enumerating failures and errors regarding CVSS v2.0 [27]. The authors indicated a lack of specificity in the metrics and, consequently, due to the scores obtained, it was not possible to distinguish a vulnerability type and risk profile when assessing. Furthermore, the research indicated that CVSS requires extensive expertise on the exact impact of a vulnerability. Despite the demonstrated failures of the CVSS, this standard is still used today. Common Vulnerability Scoring System standards, CVSS v2 and CVSS v3.x, involve three types of score metrics: Base, Temporal, and Environmental. The base category represents the properties of a vulnerability that are constant over time. However, the base score may change depending on the information that requires an update of the score to allow for changes in the metric vector upon new information gathered. The temporal score is a modifier for the base vulnerability in time based on the maturity of an exploit, possible remediation techniques, and confidence of the vulnerability reports. Environmental score metrics are environment-specific modifiers that help to evaluate risk for particular ICT environments. As part of further improvements to the CVSS standard, new versions, v3.0 and v3.1, were introduced. Standard v3.0 implemented a new approach towards metric parameters and calculations, and the latest version focused on clarifying the ambiguous metrics [28]. CVSS v3.0 was presented in 2015 as an update for the CVSS v2.0 version. This standard demonstrates a new vulnerability calculation method and excludes both the target distribution, \(TD\) and the collateral damage potential, \(CDP\), from the environment score vector. CVSS v3.0 differs from v2.0 by refining vulnerability categorization and assigning vector features to assessment components. It maintains the three categories:  
* Base--describing constant parameters of vulnerability,
* Temporal--describing time-changing parameters,
* Environmental--describing the context of vulnerability within the environment.