#  SecScore: Enhancing the CVSS Threat Metric Group with Empirical Evidences

Miguel Santana  Banco de PortugalPortugal ,  Vinicius V. Cogo  LASIGE,
Informática, Faculdade de Ciências, Universidade de LisboaPortugal and  Alan
Oliveira de Sá  LASIGE, Informática, Faculdade de Ciências, Universidade de
LisboaPortugal

(2024)

###### Abstract.

_Background:_ Timely prioritising and remediating vulnerabilities are
paramount in the dynamic cybersecurity field, and one of the most widely used
vulnerability scoring systems (CVSS) does not address the increasing
likelihood of emerging an exploit code.
_Aims:_ We present SecScore, an innovative vulnerability severity score that
enhances CVSS Threat metric group with statistical models from empirical
evidences of real-world exploit codes.
_Method:_ SecScore adjusts the traditional CVSS score using an explainable and
empirical method that more accurately and promptly captures the dynamics of
exploit code development.
_Results:_ Our approach can integrate seamlessly into the assessment
/prioritisation stage of several vulnerability management processes, improving
the effectiveness of prioritisation and ensuring timely remediation. We
provide real-world statistical analysis and models for a wide range of
vulnerability types and platforms, demonstrating that SecScore is flexible
according to the vulnerability’s profile. Comprehensive experiments validate
the value and timeliness of SecScore in vulnerability prioritisation.
_Conclusions:_ SecScore advances the vulnerability metrics theory and enhances
organisational cybersecurity with practical insights.

††copyright: none††journalyear: 2024††conference: ; ;

##  1\. Introduction

Figure 1. Statistics on the yearly published vulnerabilities and exploit
maturity in VulDB (Pyxyp Inc., 2023) from $2000$ to $2023$.

Vulnerabilities are flaws that attackers can exploit in attempts to intrude a
system, leading to security failures if protective measures fail to refrain
them (Veríssimo et al., 2003). Vulnerability prevention and removal are
protective measures essential in safeguarding a system against potential
exploits and attacks. Organisations usually leverage vulnerability management
processes to detect, prioritise, remediate, and mitigate vulnerabilities,
whose automation directly propels their practicality (Foreman, 2019).

Several reports acknowledge the worrisome growth in the number of novel
identified vulnerabilities along the years (Greig, 2021; Laboratory, 2021).
For instance, the brown line in Figure 1 displays the yearly number of
published vulnerabilities in VulDB (Pyxyp Inc., 2023), which roughly grown
from approximately $1$k in 2000 to $5$k in 2010 and to $19$k in 2020. The
unbounded nature of this growth becomes even more evident as $27$k
vulnerabilities were published in 2022 and $32$k in 2023.

Vulnerability management processes rely upon widely-adopted vulnerability
identifiers (e.g., CVE ID (The MITRE Corporation, 2023)) and scores (e.g.,
CVSS (FIRST—Forum of Incident Response and Security Teams, Inc., 2023a), EPSS
(FIRST—Forum of Incident Response and Security Teams, Inc., 2023b)) to timely
prioritise that many vulnerabilities. CVSS (FIRST—Forum of Incident Response
and Security Teams, Inc., 2023a) (currently at version $v4$) stands as the
most prominent vulnerability score, featuring a Base component (called CVSS-B)
that serves mainly as a technical severity assessment for vulnerabilities—
_i.e., it does not fit for standalone risk evaluation_ (FIRST—Forum of
Incident Response and Security Teams, Inc., 2024).

Integrating this Base score with Threat and Environment metric groups composes
the CVSS-BTE (FIRST—Forum of Incident Response and Security Teams, Inc.,
2024), a more practical, adaptive vulnerability score variant. The Threat
metrics group adjusts the CVSS Base score based on the Exploit Maturity as a
means of estimating an increased (resp. decreased) likelihood of a
vulnerability being attacked due to the availability of a more (resp. less)
mature exploit technique or code (e.g., CVSS v3.1 (FIRST—Forum of Incident
Response and Security Teams, Inc., 2023a) categorises it in “Not Defined”,
“Unproven”, “Proof-of-Concept”, “Functional”, and “High”). Problems in this
approach include, but are not limited to, the fact that _CVSS saturates when
the maturity of an exploit code is “ Not Defined” and these status are
manually changed by experts (i.e., reactively, not time-dependent), taking
years to see them reflected in vulnerability databases_.

This reality is illustrated also in Figure 1 through the stacked bars and
table indicating that it takes seven years for the “Not Defined” category to
comprise less than $90\%$ of the yearly published vulnerabilities in VulDB
(Pyxyp Inc., 2023) and fifteen years to comprise less than $50\%$.
Furthermore, the “High” and “Functional” categories have never collectively
represented more than one-third of the yearly published vulnerabilities.
Nevertheless, _prioritising vulnerabilities clearly requires a timelier
approach to effectively become practical_.

The Exploit Prediction Scoring System (EPSS) (FIRST—Forum of Incident Response
and Security Teams, Inc., 2023b) is a machine learning (ML) approach for
estimating the probability of a software vulnerability being exploited within
the following 30 days. It complements CVSS since it produces a data-driven
score between 0 and 1 that is directly proportional to the likelihood of
exploitation of a given vulnerability in the wild. Although EPSS has been
improving its accuracy (from an F1-score of $0.299$ in EPSS v1 to $0.451$ in
v2, and $0.728$ in v3 (FIRST—Forum of Incident Response and Security Teams,
Inc., 2023b)), _it still requires better AI interpretability and seamless
integration with CVSS, as well as it must be recalculated for all known
vulnerabilities during each prioritisation round_.

In this work, we introduce SecScore, an innovative, empirical scoring system
that enhances the CVSS Threat metric group by directly integrating an
explainable metric, thereby enabling an effective vulnerability
prioritisation. This score is adeptly designed to be incorporated not only
within our proposed vulnerability management process, SecRush, but also
alongside other existing prioritisation methods, such as EPSS (FIRST—Forum of
Incident Response and Security Teams, Inc., 2023b), to ensure comprehensive
and timely remediation of vulnerabilities. In summary, the paper contributions
are:

  1. (1)

An empirical study into the likelihood of existing exploits for a wide range
of vulnerability profiles (§5.2);

  2. (2)

The formulation of SecScore, a vulnerability severity score that integrates
the knowledge from our empirical study into the CVSS Threat metric group (§4);

  3. (3)

An experimental evaluation of SecScore, demonstrating its value and timeliness
in vulnerability prioritisation (§5.3).

##  2\. Context and Background

This section contextualises vulnerability management processes, illustrating
where one can integrate SecScore, and provides an overview of the Common
Vulnerability Scoring System (CVSS) as the background for the modifications
proposed in SecScore.

###  2.1. Vulnerability Management Processes

Vulnerability management processes (VMPs) arrange vulnerability management
tasks into, typically, four to six consecutive stages according to the
organisational methodologies and technologies. In general, VMPs include
discovery/scanning, assessment/prioritisation, report, remediation,
verification/validation, and retrospective stages. Table 1 compares the stages
of several VMPs (Humphries, 2020; Rapid7, [n. d.]; Ascend, 2019; University,
2021; Tenable, 2020a; of Miami, [n. d.]; Cavalancia, 2020; for Disease Control
and Prevention, 2021). They differ on the number and naming of stages, the
automation of the discovery, the assessment and prioritisation order, the
position of the report stage (e.g., before or after remediation), and the
existence or absence of verification/validation.

Table 1. The stages of vulnerability management processes.

VMP | # | Stages
---|---|---
Exabeam (Humphries, 2020) | 4 |  _I_ | _E_ |  |  _Rem._ |  |  _Rep._
Rapid7 (Rapid7, [n. d.]) |  _S_ | _A_ |  |  _Add._ |  |  _Rep. ∗_
Ascend (Ascend, 2019) | 5 |  _D_ | _A_ |  _Rep._ |  _Rem._ |  _Ver._ |
Fordham U. (University, 2021) |  _D_ |  _Pri._  _Pl._ |  |  _Rem._ |  _Val._ |
Tenable (Tenable, 2020a) |  _D_ |  _A_  _Pri._ |  |  _Rem._ |  _M_ |
U. Miami (of Miami, [n. d.]) |  _P_  _S_ | _Def._ |  |  _Imp._ |  _RS_ |
AT&T (Cavalancia, 2020) | 6 |  _D_ |  _Pri._  _A_ |  |  _Rem._ |  _Ver._ |  _Rep._
CDC (for Disease Control and Prevention, 2021) |  _D_ |  _Pri._  _A_ |  _Rep._ |  _Rem._ |  _Ver._ |

_# = Num. of Stages, A= Assess, Add.= Pri.&Address, D= Discover, Def.= Define
Rem., E= Evaluate, I= Identify, Imp.= Implement Rem., M= Measure, P= Prepare,
Pl.= Plan, Pri.= Prioritise, Rem.= Remediate, Rep.= Report, RS= Rescan, S=
Scan, Val.= Validate, Ver.= Verify, ∗ Rep. and Cont. Management._

The discovery/scanning stage identifies vulnerabilities and associates them
with manually, systematically, or continuously collected catalogues of
organisation’s physical and virtual assets. The assessment/prioritisation
stage ranks the identified vulnerabilities based on their risk to the
organisation. Many VMPs already obtain risk scores for the identified
vulnerabilities from publicly-available open catalogues (e.g., the CVE by
MITRE (The MITRE Corporation, 2023)). However, the staggering proportion of
vulnerabilities classified at the highest risk level ultimately discredits the
current vulnerability risk assessment process. We propose SecScore, an
innovative vulnerability severity score for this VMP stage considering
statistical models built with empirical evidences from real-world exploit
codes.

Usually, the report stage documents the prioritised vulnerabilities to guide
resolution efforts with detailed, actionable mitigation plans. During the
remediation stage, vulnerabilities are mitigated based on their severity and
availability of patches. Misconfigurations must be corrected and unpatched
vulnerabilities must be continuously monitored to prevent escalation. If
included in the VMP, the verification/validation stage assesses the mitigation
effectiveness in reducing the organisation exposure to the prioritised
vulnerabilities. Cybersecurity teams may conduct standard routines or opt for
on-demand vulnerability scans to ensure that vulnerabilities were properly
managed. Finally, VMPs that include a retrospective stage usually promote
reflective meetings to review the overall VMP effectiveness, periodically
reporting the resolved vulnerabilities and providing insights into the ongoing
risk management process.

Four-stage VMPs (e.g., (Humphries, 2020; Rapid7, [n. d.])) are often
considered a simplistic approach that overlooks the cumulative impact of
fixing all vulnerabilities, fails to validate the risk reduction, neglects the
presence of exploits in the evaluation phase, and lacks continuous
vulnerability identification. Five-stage VMPs (e.g., (Ascend, 2019;
University, 2021; Tenable, 2020a; of Miami, [n. d.])) provide a more holistic
approach that confirms vulnerability mitigation and formally prioritises
vulnerabilities. Six-stage VMPs (e.g., (Cavalancia, 2020; for Disease Control
and Prevention, 2021)) focus on continuous risk evaluation and automated
discovery, although challenges remain in monitoring vulnerabilities without
patches and ensuring an effective prioritisation.

###  2.2. Common Vulnerability Scoring System

Vulnerability prioritisation challenges are frequently discussed in the
literature, highlighted by the various solutions based on diverse
vulnerability scoring systems. The Common Vulnerability Scoring System (CVSS)
(FIRST—Forum of Incident Response and Security Teams, Inc., 2023a), managed by
the Forum of Incident Response and Security Teams (FIRST), is a prominent
framework for assessing vulnerability severity. Although CVSS should not
determine alone vulnerability prioritisation (FIRST—Forum of Incident Response
and Security Teams, Inc., 2023a, 2024; Spring et al., 2021), it still serves
as a foundational metric for many prioritisation methodologies.

Introduced in 2005 (of Incident Response and Teams, 2005), CVSS has undergone
several updates. As of the end of 2023, CVSSv4 (FIRST—Forum of Incident
Response and Security Teams, Inc., 2024) has been officially adopted, though
many publicly-available vulnerability databases continue to use its
predecessor, CVSSv3.1 (of Incident Response and Teams, 2019). For this reason,
the present section details CVSSv3.1. Notwithstanding, SecScore is designed to
be compatible with both CVSSv3.1 and CVSSv4 (see Figures 3 and 4), ensuring
broad applicability across different versions as organisations transition to
the latest standard. Figure 2 provides an overview of the CVSSv3.1 equations
and metrics, which will be described next. The CVSSv3.1 score of a
vulnerability is computed considering three components: a Base Score
$\mathcal{B}$; a Temporal Score $\mathcal{T}$; and an Environmental Score
$\mathcal{E}$.

The CVSSv3.1 Base Score $\mathcal{B}$ is calculated using the impact
$\mathcal{I}$ and exploitability $\mathcal{X}$ of the vulnerability. Impact
$\mathcal{I}$ is derived from Equation 2, involving the Impact Sub-Score
$\mathit{ISS}$ and the scope metric $S$. $\mathit{ISS}$ assesses the
vulnerability’s effects on the Confidentiality $C$, Integrity $I$, and
Availability $A$ of an asset. Scope $S$ determines whether the vulnerability’s
impact is confined withing the same security authority
($S=\overline{Changed}$) or extends beyond it ($S=Changed$), affecting
additional resources. Exploitability $\mathcal{X}$ is determined by Equation
3, which incorporates the base metrics of Attack Vector ($AV$), Attack
Complexity ($AC$), Privileges Required ($PR$), and User Interaction ($UI$).
The Base Score $\mathcal{B}$ is then calculated using Equation 5, which
includes a roundup operation $\mathcal{R}$ to the nearest tenth, ensuring the
result is the smallest decimal equal to or greater than the input, as detailed
in Equation 4.

CVSSv3.1 Scores and Metrics: Base Score ($\mathcal{B}$) Attack Vector
($\mathit{AV}$) Exploitability Attack Complexity ($\mathit{AC}$) Score
($\mathcal{X}$) Privileges Required ($\mathit{PR}$) User Interaction
($\mathit{UI}$) Scope Scope ($S$) Score ($\mathcal{S}$) Impact Confidentiality
($C$) Score ($\mathcal{I}$) Integrity ($I$) Availability ($A$) Temporal
Exploit Code Maturity ($E$) Score ($\mathcal{T}$) Remediation Level
($\mathit{RL}$) Report Confidence ($\mathit{RC}$) Environmental Security
Requirements ($C_{R}$, $I_{R}$, $A_{R}$) Score ($\mathcal{E}$) Modified Base
Metrics ($X_{M}$, where
$X\in\\{\mathit{AV},\mathit{AC},\mathit{PR},\mathit{UI},S,C,I,A,\mathit{ISS}\\}$)
Other Definitions: $\mathit{ISS}$ Original Impact Sub-Score. $\mathcal{R}$
Round up (i.e., _ceil_) operation with scale of one. CVSSv3.1 Base Score
($\mathbf{\mathcal{B}}$): (1)
$\mathit{ISS}=1-\big{[}\left(1-C\right)\times\left(1-I\right)\times\left(1-A\right)\big{]}$
(2) $\mathcal{I}=\begin{cases}6.42\times\mathit{ISS}&\text{if
}S=\overline{Changed}\\\\[4.0pt]
[7.52\times\left(\mathit{ISS}-0.029\right)-&\text{if }S=Changed\\\
~{}~{}3.25\times\left(\mathit{ISS}-0.02\right)^{15}]&\\\ \end{cases}$ (3)
$\mathcal{X}=8.22\times AV\times AC\times PR\times UI$ (4)
$\mathcal{R}(n)=\lceil n\times 10\rceil/10$ (5)
$\mathcal{B}=\begin{cases}0&\text{if }\mathcal{I}\leq 0\\\\[4.0pt]
\mathcal{R}\left(\min\left[\left(\mathcal{I}+\mathcal{X}\right),10\right]\right)&\text{if
}\mathcal{I}>0\text{, }\\\ &S=\overline{Changed}\\\\[4.0pt]
\mathcal{R}\left(\min\left[1.08\times\left(\mathcal{I}+\mathcal{X}\right),10\right]\right)&\text{if
}\mathcal{I}>0\text{, }\\\ &S=Changed\end{cases}$ CVSSv3.1 Temporal Score
($\mathbf{\mathcal{T}}$): (6) $\mathcal{T}=\mathcal{R}(\mathcal{B}\times
E\times\mathit{RL}\times\mathit{RC})$ CVSSv3.1 Environmental Score
($\mathbf{\mathcal{E}}$): (7)
$\begin{split}&\mathit{ISS_{M}}=\min\big{[}1-((1-C_{R}\times C_{M})\times\\\
&~{}~{}(1-I_{R}\times I_{M})\times(1-A_{R}\times
A_{M})),0.915\big{]}\end{split}$ (8)
$\mathcal{I}_{M}=\begin{cases}6.42\times\mathit{ISS_{M}}&\text{if
}S_{M}=\overline{Changed}\\\\[4.0pt]
\big{[}7.52\times(\mathit{ISS_{M}}-0.029)-3.25\times&\text{if
}S_{M}=Changed\\\ ~{}~{}(\mathit{ISS_{M}}\times 0.9731-0.02)^{13}\big{]}&\\\
\end{cases}\\\ \\\ $ (9)
$\mathcal{X}_{M}=8.22\times\mathit{AV_{M}}\times\mathit{AC_{M}}\times\mathit{PR_{M}}\times\mathit{UI_{M}}$
(10)
$\mathcal{E}=\begin{cases}\begin{split}&\mathcal{R}\big{(}\mathcal{R}(\min\big{[}(\mathcal{I}_{M}+\mathcal{X}_{M}),&\text{if
}S_{M}=\overline{Changed}\\\
&~{}~{}10\big{]})\times\mathit{RC}\times\mathit{RL}\times E\big{)}\\\\[4.0pt]
&\mathcal{R}\big{(}\mathcal{R}(\min\big{[}1.08\times(\mathcal{I}_{M}+\mathcal{X}_{M}),&\text{if
}S_{M}=Changed\\\ &~{}~{}10\big{]})\times\mathit{RC}\times\mathit{RL}\times
E\big{)}\end{split}\end{cases}$ Figure 2. CVSSv3.1 metrics overview and
equations.

The CVSS Temporal Score $\mathcal{T}$ is derived from the Base Score
$\mathcal{B}$ using Equation 6 and incorporates factors prone to change over
time: the state of exploit techniques (Exploit Code Maturity $E$), the
availability of remediation (Remediation Level $RL$), and the confidence in
the vulnerability description (Report Confidence $RC$). Note that, although
Equation 6 is referred to as temporal, it does not imply a dependency on time
_per se_ ; rather, the Temporal Score $\mathcal{T}$ changes only when experts
reassess the vulnerability status and update the values of $E$, $RL$, or $RC$.
Noticeable, this temporal metric became the Threat metric group in CVSSv4,
which for clarity, we may use them interchangeably in many discussions in our
paper.

The Environmental Score $\mathcal{E}$ tailors the CVSS score to reflect the
importance of the affected IT asset within its organisation. Similar to the
Base Score $\mathcal{B}$, $\mathcal{E}$ depends on the impact and
exploitability of the vulnerability. However, for $\mathcal{E}$, these
components are adjusted to fit the organisational context and are known as the
modified impact $\mathcal{I}_{M}$ and modified exploitability
$\mathcal{X}_{M}$. $\mathcal{I}_{M}$ is derived from Equation 8, using the
modified Impact Sub-Score $\mathit{ISS}_{M}$ and the modified confidentiality,
integrity, and availability metrics ($C_{M}$, $I_{M}$, and $A_{M}$), which are
adaptations of those used in the standard impact calculation. Additionally,
the security metrics $C_{R}$, $I_{R}$, and $A_{R}$ allow for further
customisation, adjusting the CVSS score based on the criticality of the
confidentiality, integrity, and availability of the organisation asset. The
modified exploitability $\mathcal{X}_{M}$ uses Equation 9, which involves the
modified Attack Vector $AV_{M}$, Attack Complexity $AC_{M}$, Privileges
Required $PR_{M}$, and User Interaction $UI_{M}$. These metrics are customised
by the organisation’s analysts to reflect the specific environmental
conditions surrounding the affected asset.

The Environmental Score $\mathcal{E}$ is finally calculated according to
Equation 10, which incorporates the modified Scope metric ($S_{M}$) and
integrates the temporal metrics—Exploit Code Maturity $E$, Remediation Level
$RL$, and Report Confidence $RC$—similarly to how they are used in the
computation of the Temporal Score $\mathcal{T}$ as per Equation 6. Following
this CVSSv3.1 overview, the discussion will shift to explore other existing
scoring systems.

##  3\. Related Work

###  3.1. Temporal and Dynamic Scoring in CVSS

Although CVSSv3.1 includes temporal and environmental scores, these metrics
are not inherently time-dependent since they are only updated upon
reevaluation by experts when significant changes in the vulnerability’s status
occur. This method, however, often fails to capture the dynamics of threat
environments where the likelihood of exploitability can increase over time due
to advancements in attacker capabilities and other external factors. CVSSv4
renamed the temporal score to the threat metric group, which aims to provide a
more continuous reflection of the current threat landscape. This transition
underscores a critical shift from a predominantly reactive model to one that
proactively adapts to emerging threats, enhancing the ability to prioritise
vulnerabilities more effectively based on real-world risk assessments.
Following a similar observation, Minohara _et al._ (Minohara and Shimakawa,
2023) propose evolving the score of a vulnerability over time from its initial
CVSSv3.1 metrics (Base, Temporal, or Environmental) to a score augmented by
the maximum Exploitability Score $\mathcal{X}$, assuming that exploitability
is time-dependent only. However, their approach contrasts with the static
nature of CVSSv3.1 exploitability metrics ($AV$, $AC$, $PR$, $UI$), which
typically remain unchanged. This method may also obscure critical differences
among vulnerabilities by equalising scores over time, complicating
prioritisation. Our work, SecScore (detailed in Section 4), counters theirs by
integrating a real-world data-driven statistical model into CVSS, dynamically
estimating the probability of exploit code development, offering a practical
and evolving alternative to the static $E$ metric.

###  3.2. ML Approaches for Vulnerability Scoring

Recently, the application of machine learning (ML) to enhance vulnerability
assessments has also gained traction. Sharma _et al._ (Sharma et al., 2023)
propose a hybrid scoring system that recalibrates the weights of impact and
exploitability scores in CVSSv2, showing improvements over traditional static
models where impact consistently outweighs exploitability. Kuhn _et al._ (Kühn
et al., 2023) explores deep learning to automate the prediction of CVSSv3 base
metrics, aiming to expedite and improve the labour-intensive scoring process.
Albanese _et al._ (Albanese et al., 2023) and another study (Zeng et al.,
2022) explore models that assess the likelihood and exposure of vulnerable
components and model attacker preferences, respectively, through advanced
machine learning techniques. These approaches demonstrate a shift towards
automating and enhancing the accuracy of vulnerability assessments (Sharma et
al., 2023; Kühn et al., 2023; Albanese et al., 2023; Zeng et al., 2022).

Abuabed _et al._ (Abuabed et al., 2023), on the other hand, focus on
evaluating the feasibility of each attack by considering attack vectors,
attack complexity, and authentication metrics through threat modelling.
However, our research with SecScore prioritises the exploitability of
vulnerabilities to address them effectively. This focus is critical as only
about $4\%$ of CVEs have public exploit code released within the first year of
publication, and when such code appears, it is typically published within two
days (Householder et al., 2020). These observations underscore the urgency to
prioritise and swiftly address critical vulnerabilities.

###  3.3. Predictive and Exploitability Modeling

Jacobs et al. (Jacobs et al., 2020) introduced a model to prioritise
vulnerabilities by predicting their exploit “in the wild” instead of
“published exploits” in line with (Allodi, 2015). The proposed model presented
three practical strategies for vulnerability remediation: CVSS scores,
published exploits, and vulnerability attributes. They evaluated each strategy
using a rules-based approach and a machine learning model. Ultimately, they
built a machine learning model with the obtained dataset. The proposal
presented good accuracy, efficiency, and coverage results compared to CVSS.

The EPSS (FIRST—Forum of Incident Response and Security Teams, Inc., 2023b)
represents a significant evolution in vulnerability scoring by estimating the
likelihood of exploitation using predictive models. Spanning three versions,
EPSS has advanced from a basic model using 16 features in EPSSv1 to a
sophisticated XGBoost model analysing 1,477 variables in EPSSv3. This
progression includes expanding data sources to include real-time data from
multiple security databases and social media, enhancing the system’s
responsiveness to new threats (Jacobs et al., 2021, 2023). Although EPSS has
been improving its accuracy (from an F1-score of $0.299$ in EPSS v1 (Jacobs et
al., 2021) to $0.451$ in v2 (Jacobs et al., 2023), and $0.728$ in v3
(FIRST—Forum of Incident Response and Security Teams, Inc., 2023b)), concerns
regarding input data integrity, model transparency for AI interpretability,
seamless integration with CVSS, and adaptability to new trends persist (Jacobs
et al., 2023). Additionally, EPSS must be recomputed for all known
vulnerabilities during each prioritisation round, which increases the required
computational resources for the vulnerability management process.

###  3.4. Statistical Relational Learning Approaches

Unique methodologies to assess vulnerability exploitability involve
statistical and relational learning. A notable study (Figueiredo et al., 2023)
employs the RDN-Boost algorithm within a Statistical Relational Learning (SRL)
framework to analyse the relationships between products, vulnerabilities, and
exploits, providing insights into the challenges of generic vulnerabilities.
This approach underscores the complexity of accurately predicting exploit code
associations and the need for tailored models to effectively address specific
scenarios (Figueiredo et al., 2023). However, estimating the probability of an
exploit code or technique being related to a given vulnerability was beyond
their scope.

###  3.5. Emerging Trends and Open Challenges

The field continues to evolve, with ongoing research highlighting the
limitations of current methods and the necessity for continuous development.
The dynamic nature of cyber threats necessitates that vulnerability scoring
systems like CVSS adapt to changing conditions, enhancing their ability to
predict and mitigate risks effectively. This is particularly critical as the
context in which vulnerabilities exist can dramatically alter their impact and
represent a greater (or lesser) risk over time (Howland, 2021). The present
work considers the need to adapt the CVSS in order to better address the
aforementioned constraints identified in the literature. To this end, it
proposes an improvement in the computation of the CVSS Threat metric group
(the equivalent to the Temporal metric in CVSSv3.1) with empirical evidences.

##  4\. SecScore

SecScore is built on top of CVSS (FIRST—Forum of Incident Response and
Security Teams, Inc., 2023a), leveraging its strengths and adding mechanisms
for better prioritisation of vulnerabilities in risk-based management
processes. Although in this paper the discussion about SecScore occurs mainly
around CVSSv3.1111Of the two most recent CVSS versions, CVSSv3.1 has the most
classifications available., its modularity also allows it to be applied to
other CVSS versions. For this reason, in addition to detailing the SecScore
applied on CVSSv3.1, this section also presents its formulation on CVSSv4 as
reference.

Definitions: $\mathit{t}$ Time (in weeks) since the CVE publication date.
$\mu$ Location parameter of the AL distribution. $\lambda$ Scale parameter of
the AL distribution. $\kappa$ Asymmetry parameter of the AL distribution.
$E_{min}$ Minimum value that $E$ can assume in CVSSv3.1. $E_{max}$ Maximum
value that $E$ can assume in CVSSv3.1. Asymetric Laplace (AL) CDF
($\mathbf{\mathit{F}}$): (11) $F(t;\
\mu,\lambda,\kappa)=\begin{cases}\dfrac{\kappa^{2}}{1+\kappa^{2}}\
e^{\tfrac{\lambda}{\kappa}(t-\mu)}&\text{if }t\leq\mu\\\\[8.0pt]
1-\dfrac{1}{1+\kappa^{2}}\ e^{-\lambda\kappa(t-\mu)}&\text{if
}t>\mu\end{cases}$ SecScore Model for Exploit Maturity
($\mathbf{\mathit{E_{\mathbb{S}}}}$): (12)
$E_{\mathbb{S}}(t)=E_{min}+(E_{max}-E_{min})\times F(t;\ \mu,\lambda,\kappa)$
SecScore Temporal Metrics Group Score
($\mathbf{\mathit{\mathbb{S}}_{\mathcal{T}}}$): (13)
$\mathbb{S}_{\mathcal{T}}(t)=\mathcal{R}(\mathcal{B}\ \times RC\ \times
RL)\times E_{\mathbb{S}}(t)$ SecScore Environmental Metrics Group Score
($\mathbf{\mathit{\mathbb{S}}_{\mathcal{E}}}$): (14)
$\mathbb{S}_{\mathcal{E}}(t)\\!\\!=\\!\\!\begin{cases}\begin{split}&\mathcal{R}(\mathcal{R}(\min\big{[}(\mathcal{I}_{M}\\!+\\!\mathcal{X}_{M}),10\big{]})\times&\text{if
}\\!S_{M}\\!=\\!\overline{Changed}\\\
&~{}~{}\mathit{RC}\times\mathit{RL})\times E_{\mathbb{S}}(t)\\\\[4.0pt]
&\mathcal{R}(\mathcal{R}(\min\big{[}1.08\times(\mathcal{I}_{M}+\mathcal{X}_{M}),&\text{if
}\\!S_{M}\\!=\\!Changed\\\ &~{}~{}10\big{]})\times RC\times RL)\times
E_{\mathbb{S}}(t)\end{split}\end{cases}$ Figure 3. SecScore metrics and
equations applied to CVSSv3.1.

SecScore leverages a set of well-established CVSS metrics that are often
quantified through careful expert assessments. The idea behind SecScore is not
to be an alternative to CVSS, but to complement it in order to address one of
its main limitations for vulnerability prioritisation (Spring et al., 2021;
Howland, 2021; Spring et al., 2018; Tenable, 2020a, b, c; Vulcan, 2019),
considering the real-world dynamics of exploit code development. Specifically,
SecScore converts the Exploit Code Maturity metric $E$ into a model
$E_{\mathbb{S}}(t)$ that takes into account the probability of existing an
exploit code to the vulnerability. Under this approach, SecScore reassess the
CVSS Temporal and Environmental Scores using a statistical model fitted to a
dataset containing historical information of vulnerabilities. Furthermore,
SecScore is parameterised and can be customised for diverse vulnerability
profiles, according to its type or platform.

As shown in Section 2.2, although CVSS has a temporal metric $E$ to express
the exploit code maturity, it is updated only when experts modify it based on
perceived changes with respect to available exploit codes. This method of
updating $E$ is limited, since the continuous efforts of hackers (white hat or
black hat) can make exploit codes/techniques exist even if they are not
publicly known. This means that the likelihood of having an unknown exploit
code/technique for a given vulnerability tends to increase over time, and this
effect is not expressed in $E$ as a function of time.

The lack of time effect in the CVSS, specially regarding to $E$, may lead to
an unoptimised or flawed prioritisation process. In a simple example, think
about two vulnerabilities $V_{1}$ and $V_{2}$ that are published in the CVE
Database in different dates ($V_{1}$ before $V_{2}$), both classified with the
same CVSS score. At a given time $t_{n}$ after the publication of the two
vulnerabilities, considering that the CVSS metrics remain unchanged, it would
be difficult to discern which would be priority based on the CVSS score, given
the way it is computed. However, it is reasonable to hypothesise that in
$t_{n}$ the probability of having an exploit code/technique for $V_{1}$ tends
to be greater than the probability of having an exploit code/technique for
$V_{2}$, since $V_{1}$ tends to be older than $V_{2}$.

Definitions: $EQ5$ Macrovector for E with 3 levels:
$\big{[}\\{0,\mathit{E:A}\\},\\{1,E:P\\},\\{2,E:U\\}\big{]}$ $E_{min}$ Minimum
value that $E$ can assume in CVSSv4, where: (15)
$E_{min}=\frac{\mathbb{S}_{CVSS_{v4}}\big{\rvert}_{EQ5=2}}{\mathbb{S}_{CVSS_{v4}}\big{\rvert}_{EQ5=0}}$
$E_{max}$ Maximum value that $E$ can assume in CVSSv4, where: (16) $E_{max}=1$
SecScore Model for Exploit Maturity ($\mathbf{\mathit{E_{\mathbb{S}}}}$): (17)
$E_{\mathbb{S}}(t)=E_{min}+(E_{max}-E_{min})\times F(t;\ \mu,\lambda,\kappa)$
SecScore Threat Metrics Group Score
($\mathbf{\mathit{\mathbb{S}}_{\mathcal{T}}}$): (18)
$\mathbb{S}_{\mathcal{T}}(t)=\mathbb{S}_{CVSS_{v4}}\big{\rvert}_{EQ5=0}\
\times E_{\mathbb{S}}(t),$ Figure 4. SecScore metrics and equations applied to
CVSSv4.

SecScore aims to address this situation and others whose prioritisation can be
better implemented by observing the effect of time on the probability of
having an exploit code/technique for the vulnerability. In CVSSv3.1, the
approach of converting $E$ to $E_{\mathbb{S}}(t)$ is applied to CVSS’s
Temporal (6) and Environmental (10) equations, which are rewritten as (13) and
(14), respectively, in which $\mathbb{S}_{\mathcal{T}}(t)$ and
$\mathbb{S}_{\mathcal{E}}(t)$ are the Temporal and Environmental Scores
provided by SecScore, respectively. The computation of $E_{\mathbb{S}}(t)$ is
done according to Equation 12, wherein $E_{min}$ is the minimum value that $E$
can assume in CVSS (i.e., 0.91 for the Unproven status in CVSSv3.1), and
$E_{max}$ is the maximum value that $E$ can assume in CVSS (i.e., 1 for the
High or Not Defined statuses in CVSSv3.1).

The asymmetric Laplace (AL) distribution is a generalisation of the Laplace
distribution (Kozubowski and Podgórski, 2000), and its CDF is used in SecScore
to model the probability of existing an exploit code/technique for the
vulnerability in a given time $t$ after its CVE date. The parameters
$\\{\mu,\lambda,\kappa\\}$ are adjusted to fit the CDF (11) to a vulnerability
dataset. It should be noted that in SecScore, the CDF (11) was chosen so that
$\\{\mu,\lambda,\kappa\\}$ can be adjusted and accurately represent
vulnerabilities of different types, programming languages, platforms, among
others. The performance of the AL CDF in representing the probability of
existence of exploit codes is compared with the performance of other CDFs in
Section 5.

Equation 12 converts the AL CDF $F(t;\ \mu,\lambda,\kappa)$ into an exploit
code maturity metric $E_{\mathbb{S}}(t)$ that varies over the time from
$E_{min}$ to $E_{max}$, as the probability of an existing exploit
code/technique increases. Note that, in some cases the exploit code/technique
may exist even before the official publication of the vulnerability in the CVE
database (Householder et al., 2020; Chen et al., 2019), and this effect is
supported by Equation 12 since Equation 11 admits $F(t;\
\mu,\lambda,\kappa)>0$ for $t\leq 0$.

Another aspect to highlight is the non-inclusion of $E_{\mathbb{S}}(t)$ in the
rounding operation $\mathcal{R}$. The goal is to allow vulnerabilities to be
distinguished even in cases where the difference between their SecScore has a
smaller scale than one decimal place. This approach considers the release of
an exploit as a crucial factor for a prioritisation strategy and, when
comparing different vulnerabilities, where even small differences in
$E_{\mathbb{S}}(t)$ can indicate the greater or lesser probability of an
exploit emerging for each one of them. Furthermore, applying $\mathcal{R}$ to
$E_{\mathbb{S}}(t)$ could nullify its effect in distinguishing vulnerabilities
for prioritisation, especially in low CVSS scores.

In addition to providing a continuous update of the vulnerability score based
on the probability of having an exploit code for it over time, SecScore also
gives better treatment to vulnerabilities whose Exploit Code Maturity metric
is classified as Not Defined. Note that, in all analysed CVSS versions
(FIRST—Forum of Incident Response and Security Teams, Inc., 2023a, 2024), when
the Exploit Code Maturity metric is classified as Not Defined then $E=1$, such
as if it is classified as High, which is a pessimistic approach. A better way
to handle these cases is especially relevant since, according to (Pyxyp Inc.,
2023) and shown in Figure 1, the vast majority of vulnerabilities have $E$
classified as Not Defined. The problem is that by adopting this pessimistic
strategy, the CVSS of most vulnerabilities (notably those classified as Not
Defined) is raised to the same level as those in which $E$ is known to be
High. Consequently, former vulnerabilities are prone to counter-productively
dispute priority directly with the latter. In this sense, SecScore can benefit
most vulnerabilities (i.e., those where $E$ is Not Defined) since, supported
by statistical data, it does not immediately assign them the maximum $E$
score.

As previously mentioned, the SecScore model is designed to be explainable and
flexible to be applied to different CVSS versions. For this reason, we also
present in Figure 4 the SecScore applied to CVSSv4, the most recent CVSS
version although with fewer vulnerabilities classified than CVSSv3.1. Note
that the SecScore Model for Exploit Maturity $E_{\mathbb{S}}(t)$, expressed by
Equation 17 in CVSSv4, is the same as Equation 12 in CVSSv3.1. The value of
$E_{max}=1$ is also the same in both cases. The difference is in the
definition of $E_{min}$, which in CVSSv3.1 is tabulated (of Incident Response
and Teams, 2019), but in the case of CVSSv4 it is calculated by Equation 15,
where $\mathbb{S}_{CVSS_{v4}}\big{\rvert}_{EQ5=0}$ and
$\mathbb{S}_{CVSS_{v4}}\big{\rvert}_{EQ5=2}$ are the maximum and minimum
CVSSv4 scores that the vulnerability receives, respectively, according to what
is attributed to the CVSSv4 macrovector $EQ5$ (which represents the Exploit
Maturity (FIRST—Forum of Incident Response and Security Teams, Inc., 2024)).
Finally, in Equation 18, $E_{\mathbb{S}}(t)$ is multiplied by
$\mathbb{S}_{CVSS_{v4}}\big{\rvert}_{EQ5=0}$ so that
$\mathbb{S}_{\mathcal{T}}(t)$ varies proportionally to the probability of
existing an exploit code, as in Equations 13 and 14 of CVSSv3.1.

##  5\. Evaluation

This section describes the dataset used to evaluate the SecScore (§5.1),
presents a comprehensive statistical analysis on publicly available
vulnerability data (§5.2), and demonstrates the effect of the SecScore on
vulnerability prioritisation (§5.3).

###  5.1. Experimental Datasets

We downloaded snapshots (on April $2^{nd}$, 2023) of the following three well-
known vulnerability databases and produced a dataset that complementarily
aggregates their data:

  * •

_CVE_ (The MITRE Corporation, 2023), with more than $266$k CVE
entries.222https://cve.mitre.org/data/downloads/allitems.csv.

  * •

_ExploitDB_ (OffSec Services Limited, 2023), with more than $45$k exploit
entries.333https://gitlab.com/exploit-
database/exploitdb/-/blob/main/files_exploits.csv.

  * •

_CVEdetails_ (SecurityScorecard, Inc., 2023), with the CVSS base score of more
than $27$k CVEs.444https://www.cvedetails.com/vulnerability-list.php.

The resulting dataset contains information about $27$k CVEs that are common to
all three databases. The gathered data includes the CVE assignment date
(between 2001 and 2022), a publicly known exploit (with its publication date),
and a CVSS base score assigned. It sizes approximately $2.6$MB and is publicly
available on Zenodo555https://zenodo.org/records/11123116. The left part of
Table 2 details this resulting dataset, presenting the number of CVEs
according to their types and affected platforms.

###  5.2. Statistical Analysis on Publicly-Available Vulnerabilities

As discussed in Section 4, SecScore reassesses the CVSS Score taking into
account the probability of the existence of an exploit code/technique for a
vulnerability over time. In SecScore, such probability is modelled using the
CDF of the asymmetric Laplace (AL) distribution, which can be adjusted to
different vulnerability profiles by finding the appropriate
$\\{\mu,\lambda,\kappa\\}$ according to the characteristic of interest (e.g.,
the vulnerability type, or platform). This section presents the results
obtained with this _data mining empirical approach(Storey et al., 2020)_ and
compares its accuracy with other statistical distributions, namely the Laplace
(L) and the Skewed Normal (SN) distribution. All distributions were fitted to
the dataset using the maximum likelihood estimation method.

To evaluate the ability of the SecScore model to accurately represent
different vulnerability profiles, the dataset was organised into three
categories:

  * •

General: which contains all vulnerabilities of the dataset;

  * •

Type: which organises the vulnerabilities into four subcategories, according
to their types in (Security, 2023): DoS; Local; Remote; and Webapps.

  * •

Platform: which organises the vulnerabilities into 24 subcategories, according
to their platform classification in (Security, 2023): Android; iOS; Linux;
macOS; Windows; etc.

Figure 5. Histogram of the time between the Exploit Code date and the CVE
publication date.

The profile of the General category is shown in Figure 5, where the histogram
presents the number of weeks elapsed from the CVE date to the Exploit date of
all 27,432 vulnerabilities considered in this study. This figure provides a
global view of the time it takes for a known vulnerability to have its exploit
developed, based on the ExploitDB data. A negative number of weeks means that
an exploit code/technique was available before the CVE date.

Table 2. The Dataset and the size of its subsets organised according to the CVE types and affected platforms; Mean Squared Error (MSE) for Skewed Normal (SN), Laplace (L), and Asymmetric Laplace (AL) distributions; Parameters of the AL distribution. Platforms with less than ten vulnerabilities were omitted. Datasets | Mean Squared Error (MSE) | Parameters of the AL Distribution
---|---|---
Category |  Subcategory | Size | Skewed Normal | Laplace | Asym. Laplace | $\mathbf{\mu}$ | $\mathbf{\lambda}$ | $\mathbf{\kappa}$
General |  all | $27432$ | $1.045\text{\times}{10}^{-04}$ | $5.539\text{\times}{10}^{-05}$ | $5.459\text{\times}{10}^{-05}$ | $-2.857\text{\times}{10}^{-01}$ | $2.179\text{\times}{10}^{01}$ | $9.075\text{\times}{10}^{-01}$
Type |  DoS | $4022$ | $1.669\text{\times}{10}^{-04}$ | $1.106\text{\times}{10}^{-04}$ | $1.086\text{\times}{10}^{-04}$ | $1.429\text{\times}{10}^{-01}$ | $1.859\text{\times}{10}^{01}$ | $9.493\text{\times}{10}^{-01}$
Local | $2348$ | $8.441\text{\times}{10}^{-05}$ | $5.603\text{\times}{10}^{-05}$ | $5.258\text{\times}{10}^{-05}$ | $7.143\text{\times}{10}^{-01}$ | $3.210\text{\times}{10}^{01}$ | $7.757\text{\times}{10}^{-01}$
Remote | $4653$ | $6.494\text{\times}{10}^{-05}$ | $4.254\text{\times}{10}^{-05}$ | $4.078\text{\times}{10}^{-05}$ | $-3.840\text{\times}{10}^{-07}$ | $3.734\text{\times}{10}^{01}$ | $7.513\text{\times}{10}^{-01}$
Webapps | $16409$ | $2.937\text{\times}{10}^{-04}$ | $2.024\text{\times}{10}^{-04}$ | $2.027\text{\times}{10}^{-04}$ | $-4.286\text{\times}{10}^{-01}$ | $1.524\text{\times}{10}^{01}$ | $1.071\text{\times}{10}^{00}$
Platform |  aix | $38$ | $1.329\text{\times}{10}^{-04}$ | $1.141\text{\times}{10}^{-04}$ | $1.139\text{\times}{10}^{-04}$ | $5.143\text{\times}{10}^{00}$ | $2.929\text{\times}{10}^{01}$ | $9.655\text{\times}{10}^{-01}$
Android | $109$ | $1.237\text{\times}{10}^{-04}$ | $1.208\text{\times}{10}^{-04}$ | $1.017\text{\times}{10}^{-04}$ | $7.143\text{\times}{10}^{-01}$ | $1.566\text{\times}{10}^{01}$ | $4.828\text{\times}{10}^{-01}$
asp1 | $1087$ | $3.810\text{\times}{10}^{-04}$ | $2.577\text{\times}{10}^{-04}$ | $2.532\text{\times}{10}^{-04}$ | $-4.286\text{\times}{10}^{-01}$ | $1.096\text{\times}{10}^{01}$ | $1.229\text{\times}{10}^{00}$
bsd2 | $106$ | $1.914\text{\times}{10}^{-04}$ | $1.461\text{\times}{10}^{-04}$ | $1.437\text{\times}{10}^{-04}$ | $5.714\text{\times}{10}^{-01}$ | $2.938\text{\times}{10}^{01}$ | $8.551\text{\times}{10}^{-01}$
cfm | $42$ | $5.631\text{\times}{10}^{-04}$ | $5.041\text{\times}{10}^{-04}$ | $5.008\text{\times}{10}^{-04}$ | $-1.429\text{\times}{10}^{-01}$ | $3.108\text{\times}{10}^{01}$ | $8.365\text{\times}{10}^{-01}$
cgi | $445$ | $2.995\text{\times}{10}^{-04}$ | $2.562\text{\times}{10}^{-04}$ | $2.540\text{\times}{10}^{-04}$ | $-3.499\text{\times}{10}^{-09}$ | $2.694\text{\times}{10}^{01}$ | $1.309\text{\times}{10}^{00}$
hardware | $1117$ | $1.429\text{\times}{10}^{-04}$ | $1.002\text{\times}{10}^{-04}$ | $9.306\text{\times}{10}^{-05}$ | $2.857\text{\times}{10}^{-01}$ | $1.878\text{\times}{10}^{01}$ | $7.879\text{\times}{10}^{-01}$
HP-UX | $19$ | $3.927\text{\times}{10}^{-05}$ | $3.406\text{\times}{10}^{-05}$ | $3.940\text{\times}{10}^{-05}$ | $7.000\text{\times}{10}^{00}$ | $4.970\text{\times}{10}^{01}$ | $2.012\text{\times}{10}^{00}$
iOS | $46$ | $4.638\text{\times}{10}^{-04}$ | $4.367\text{\times}{10}^{-04}$ | $3.855\text{\times}{10}^{-04}$ | $-1.000\text{\times}{10}^{00}$ | $7.168\text{\times}{10}^{00}$ | $1.750\text{\times}{10}^{-01}$
java | $222$ | $1.215\text{\times}{10}^{-04}$ | $9.771\text{\times}{10}^{-05}$ | $8.519\text{\times}{10}^{-05}$ | $1.571\text{\times}{10}^{00}$ | $1.680\text{\times}{10}^{01}$ | $6.608\text{\times}{10}^{-01}$
jsp | $269$ | $2.536\text{\times}{10}^{-04}$ | $1.801\text{\times}{10}^{-04}$ | $1.741\text{\times}{10}^{-04}$ | $-2.857\text{\times}{10}^{-01}$ | $1.338\text{\times}{10}^{01}$ | $8.006\text{\times}{10}^{-01}$
Linux3 | $2146$ | $1.002\text{\times}{10}^{-04}$ | $5.569\text{\times}{10}^{-05}$ | $5.431\text{\times}{10}^{-05}$ | $8.571\text{\times}{10}^{-01}$ | $2.559\text{\times}{10}^{01}$ | $8.485\text{\times}{10}^{-01}$
macOS | $80$ | $2.719\text{\times}{10}^{-03}$ | $2.674\text{\times}{10}^{-03}$ | $2.710\text{\times}{10}^{-03}$ | $1.414\text{\times}{10}^{01}$ | $9.927\text{\times}{10}^{00}$ | $8.082\text{\times}{10}^{-01}$
multiple | $1927$ | $1.273\text{\times}{10}^{-04}$ | $8.930\text{\times}{10}^{-05}$ | $8.518\text{\times}{10}^{-05}$ | $1.857\text{\times}{10}^{00}$ | $2.058\text{\times}{10}^{01}$ | $8.733\text{\times}{10}^{-01}$
Novell | $16$ | $7.719\text{\times}{10}^{-05}$ | $6.048\text{\times}{10}^{-05}$ | $6.387\text{\times}{10}^{-05}$ | $8.571\text{\times}{10}^{-01}$ | $1.657\text{\times}{10}^{01}$ | $1.189\text{\times}{10}^{00}$
osx | $229$ | $1.694\text{\times}{10}^{-04}$ | $1.213\text{\times}{10}^{-04}$ | $1.005\text{\times}{10}^{-04}$ | $-1.429\text{\times}{10}^{-01}$ | $1.470\text{\times}{10}^{01}$ | $6.365\text{\times}{10}^{-01}$
PHP | $13261$ | $3.656\text{\times}{10}^{-04}$ | $2.662\text{\times}{10}^{-04}$ | $2.637\text{\times}{10}^{-04}$ | $-4.286\text{\times}{10}^{-01}$ | $1.456\text{\times}{10}^{01}$ | $1.128\text{\times}{10}^{00}$
python | $21$ | $2.935\text{\times}{10}^{-03}$ | $2.775\text{\times}{10}^{-03}$ | $2.542\text{\times}{10}^{-03}$ | $5.472\text{\times}{10}^{-09}$ | $5.063\text{\times}{10}^{00}$ | $3.694\text{\times}{10}^{-01}$
ruby | $13$ | $9.859\text{\times}{10}^{-04}$ | $9.943\text{\times}{10}^{-04}$ | $9.561\text{\times}{10}^{-04}$ | $-5.286\text{\times}{10}^{00}$ | $5.109\text{\times}{10}^{-03}$ | $1.085\text{\times}{10}^{-04}$
sco | $12$ | $9.151\text{\times}{10}^{-04}$ | $8.974\text{\times}{10}^{-04}$ | $8.768\text{\times}{10}^{-04}$ | $1.400\text{\times}{10}^{01}$ | $1.641\text{\times}{10}^{01}$ | $2.143\text{\times}{10}^{00}$
Solaris4 | $87$ | $1.092\text{\times}{10}^{-04}$ | $9.905\text{\times}{10}^{-05}$ | $9.846\text{\times}{10}^{-05}$ | $3.143\text{\times}{10}^{00}$ | $7.539\text{\times}{10}^{01}$ | $9.213\text{\times}{10}^{-01}$
Unix | $127$ | $8.597\text{\times}{10}^{-05}$ | $6.952\text{\times}{10}^{-05}$ | $6.939\text{\times}{10}^{-05}$ | $2.000\text{\times}{10}^{00}$ | $5.345\text{\times}{10}^{01}$ | $1.111\text{\times}{10}^{00}$
Windows5 | $5906$ | $6.039\text{\times}{10}^{-05}$ | $3.541\text{\times}{10}^{-05}$ | $3.269\text{\times}{10}^{-05}$ | $-1.429\text{\times}{10}^{-01}$ | $3.231\text{\times}{10}^{01}$ | $7.502\text{\times}{10}^{-01}$
xml | $55$ | $4.063\text{\times}{10}^{-04}$ | $3.691\text{\times}{10}^{-04}$ | $3.110\text{\times}{10}^{-04}$ | $-4.801\text{\times}{10}^{-09}$ | $6.180\text{\times}{10}^{00}$ | $2.664\text{\times}{10}^{-01}$
1 asp = {ashx, asp, aspx}; 2 bsd = {bsd, bsd_x86, freebsd, freebsd_x86,
freebsd_x86-64, netbsd_x86, openbsd};
3 linux = {linux, linux_mips, linux_x86, linux_x86-64}; 4 solaris = {solaris,
solaris_sparc, solaris_x86};
5 Windows = {Windows, Windows_x86, Windows_x86-64}

Figure 5 also presents the corresponding cumulative distribution of the
General case, and graphically compares how the CDF of the AL, L and SN
distributions fit to the complete dataset (i.e., without separating
vulnerabilities by type or platform). For a better assessment on how accurate
these distributions represent the General case, it is computed the mean
squared error (MSE) of the CDF of each distribution in relation to the
dataset. Considering all vulnerabilities, the most accurate distribution is
the AL with $MSE_{AL}=$5.459\text{\times}{10}^{-05}$$, followed by the L
distribution with $MSE_{L}=$5.539\text{\times}{10}^{-05}$$, and the SN
distribution with $MSE_{SN}=$1.045\text{\times}{10}^{-04}$$. The AL
distribution parameters that provide this $MSE_{AL}$ are
$\\{\mu,\lambda,\kappa\\}=\\{$-2.857\text{\times}{10}^{-01}$,\
$2.179\text{\times}{10}^{01}$,\ $9.075\text{\times}{10}^{-01}$\\}$. In the
General case, the slight better performance of the AL distribution over the L
distribution is attributed to its asymmetry adjustment capability. In fact,
when observing Figure 5, it can be seen a slight asymmetry between the left
and right sides of the histogram (i.e., before and after the CVE date,
respectively). This asymmetry expresses the existence of different dynamics in
the development of exploits before and after the CVE date, suggesting that
there is some degree of influence of the CVE publication on the development of
exploits. Concerning the SN distribution, although its skewness property also
allows it to be adjusted to asymmetric distributions, the results show that
the AL distribution still fits better to the General dataset.

Recall that the SecScore model was developed to be flexible and capable of
representing different vulnerability profiles, with this customisation being
achieved through the adjustment of the parameters $\\{m,\lambda,\kappa\\}$ of
the AL distribution. To demonstrate the accuracy and adjustability of
SecScore, the same analysis is carried out for the 28 different vulnerability
profiles, which correspond to the aforementioned vulnerability subcategories:
4 different types of vulnerability; and 24 different platforms to which they
belong.

Table 2 compares the accuracy of the AL, L, and SN distributions on these 28
vulnerability profiles, providing the MSE obtained with each statistical
model. The lowest MSE of each vulnerability profile (dataset subcategory) is
highlighted. Note that in most cases the AL distribution presents the best
performance (i.e., the lowest MSE). In the best case, the MSE of the AL
distribution is $3.269\text{\times}{10}^{-05}$, and in the worst case, it is
$2.710\text{\times}{10}^{-03}$, which indicates the good accuracy of the AL
distribution when representing a wide range of vulnerability profiles. The
only cases in which the L distribution slightly outperforms the AL
distribution are on the vulnerabilities whose type is WebApps or the platforms
are HP-UX, macOS, and Novell. Even so, it can be noted that in these cases
where the L distribution performs better, the accuracy gap to the AL
distribution is not significant, with the largest MSE difference being equal
to $3.6\text{\times}{10}^{-05}$ in the case of macOS.

Figure 6. Cumulative distribution of exploit codes per vulnerability types.

Note that in these cases, the worse performance of the AL distribution in
relation to L can be attributed to the fitting algorithm, since the AL
distribution admits a solution equal to that obtained by L. This means that
the CDF obtained with L can also be obtained with AL, incorporating the
parameters of L into the AL distribution and assigning $\kappa=1$.

Figure 6 shows the probability of having an exploit code over time (taking the
CVE date as reference) for the four different types of vulnerability,
according to the dataset. This figure also presents the CDF of the SN, L, and
AL distributions in order to allow a comparison of how each model fits the
different exploit code probability profiles. In complement to the MSE data
presented in Table 2, this figure graphically shows the accuracy of the AL
distribution in representing the exploit code probability profile of these
different types of vulnerabilities.

The same representation is seen in Figure 7 for vulnerabilities organised
according to examples of programming languages (namely asp, java, php, and
python), showing the accuracy of the AL distribution in representing the
exploit code probability profile of these vulnerability subcategories. More
examples with similar observations can be found on the cumulative
distributions of OS-related (Figure 8) and mobile-related (Figure 9)
vulnerabilities. The $\\{\mu,\lambda,\kappa\\}$ values of the AL distribution
of all vulnerability subcategories considered in this study are presented in
Table 2 for reference.

Figure 7. Cumulative distribution of exploit codes per programming language.

###  5.3. SecScore Effect on Vulnerability Prioritisation

This section demonstrates the effects of SecScore on the prioritisation of
vulnerabilities. All SecScore values herein presented are computed based on
the CVSSv3.1 which, although less recent than CVSSv4, still has more scores on
databases available than the latter. However, it is worth highlighting that
the SecScore reasoning is also applicable to CVSSv4, as discussed in Section
4.

Figure 8. Cumulative distribution of exploit codes of OS-related
vulnerabilities.

To illustrate the effect of SecScore on the vulnerability prioritisation
process, we compare its evolution over time for different vulnerabilities.
Figure 10 highlights six examples of vulnerabilities of different platforms,
published between 2020 and 2021 with $7\leq$ CVSSv3.1 $\leq 8$. The dashed and
solid lines represent the SecScore evolution before and after the
vulnerability’s CVE date ($C_{Date}$), respectively. The cross marks represent
the date ($E_{Date}$) when the vulnerability’s exploit code was published in
_ExploitDB_.

All vulnerabilities highlighted in Figure 10 received the same
CVSS${}_{v3.1}=7.5$, with the exception of CVE-2021-46417 which received a
CVSS${}_{v3.1}=7.8$. Note that, one could not rank them in a prioritisation
process based only on their common CVSS of $7.5$. However, some
vulnerabilities may have the exploit code developed before others, as shown in
Figure 10, which the prioritisation process could take into account. Using
SecScore enables one to obtain different scores for these vulnerabilities and
better prioritise them by taking into account the current time elapsed since
the $C_{Date}$. This benefit can be verified in different examples contained
in Figure 10, as explained in the following remarks:

#### (R1)

Although the CVE-2020-15160 and CVE-2020-13927 vulnerabilities have close
$C_{Date}$ and both have CVSS${}_{v3.1}=7.5$, the SecScore of CVE-2020-15160
remains higher than the SecScore of CVE-2020-13927 over the time. This is
because the probability of existing an exploit for PHP vulnerabilities tends
to increase faster over time than for vulnerabilities of the multiple
subcategory, according to the statistics presented in Section 5.2. Note also
that, even the $C_{Date}$ of CVE-2020-15160 being only 17 days after the
$C_{Date}$ of CVE-2020-13927, the CVE-2020-15160 already has a higher SecScore
at its $C_{Date}$. The reason is that the probability of existing an exploit
code for a PHP vulnerability at its $C_{Date}$ is greater than in the case of
a multiple vulnerability, according to the statistics. The anticipated growth
of such a probability is depicted by the dashed line of CVE-2020-15160.
Following the time, it is possible to see that the $E_{Date}$ of
CVE-2020-15160 indeed occurs before the $E_{Date}$ of CVE-2020-13927, which
reinforces that CVE-2020-15160 must be prioritised as indicated by SecScore.
This decision would not be possible to conclude by considering only their
CVSS.

Figure 9. Cumulative distribution of exploit codes of vulnerabilities related
to mobile OSes.

#### (R2)

We can also compare the behaviour of SecScore in an example with different
vulnerabilities of the same platform and with the same CVSSv3.1. This is the
case of CVE-2020-15160, CVE-2021-24762, CVE-2021-24946, and CVE-2021-26599,
which are all about PHP. Note that, although these vulnerabilities have
different $C_{Date}$, they would all be levelled if analysed from the CVSSv3.1
perspective only. However, we can observe that the $E_{Date}$ of these
vulnerabilities (i.e., the date they had an exploit code published in
_ExploitDB_) occur in the following sequence: CVE-2020-15160, [CVE-2021-24762,
CVE-2021-24946], and CVE-2021-26599. This means that it would be better to
prioritise them in this order, considering the sequence in which their
exploits would appear. SecScore allows vulnerabilities to be prioritised in
advance (i.e., even before the exploit emerges) based on the increased
likelihood of an exploit being created. In fact, we can observe that the
SecScore of CVE-2020-15160 always remains above the SecScore of
[CVE-2021-24762, CVE-2021-24946] which, in turn, have their SecScore always
above the SecScore of CVE-2021-26599. If, for example, a security analyst
prioritise these vulnerabilities in week 60 of Figure 10, SecScore would
consistently place them in that ordering thanks to its AL-based statistical
model.

#### (R3)

SecScore also allows vulnerabilities with different CVSS values to be
consistently re-ranked and prioritised taking into account the likelihood of
an exploit code emerging over the time. This is the case for CVE-2021-46417 (a
Linux vulnerability with CVSS${}_{v3.1}=7.8$) in relation to CVE-2021-24762,
CVE-2021-24946, and CVE-2021-26599 (all PHP vulnerabilities with
CVSS${}_{v3.1}=7.5$). Note that at $C_{Date}$ of CVE-2021-46417, and in the
following weeks, the CVE-2021-46417 has a lower SecScore than the other three.
This means that based on the SecScore, those three PHP vulnerabilities would
have a higher priority than CVE-2021-46417, even though the latter has a
higher CVSS value. In fact, the use of SecScore in this prioritisation is
advantageous since the $E_{Date}$ of the three PHP vulnerabilities indeed
occur before the $E_{Date}$ of CVE-2021-46417, making reasonable to mitigate
these PHP vulnerabilities first.

Figure 11 provides another example of how SecScore addresses the effect of
time in the prioritisation of vulnerabilities, by leveraging statistical data
regarding the likelihood of existing an exploit code for each vulnerability.
In this figure, three CVEs of different platforms (multiple and PHP) are
highlighted as examples, all published in 2020 with CVSS${}_{v3.1}=4.3$. The
analysis of these examples is provided in the following remarks:

#### (R4)

CVE-2020-6519 and CVE-2020-11023 illustrate a case similar to that discussed
in remark (R2). These vulnerabilities are from the same platform (PHP), but
their CVE was disclosed on different dates, with the $C_{Date}$ of
CVE-2020-6519 being an earlier date than that of CVE-2020-11023. Considering
that these vulnerabilities are from the same platform, they have the same
statistical profile regarding the probability of an exploit code appearing.
However, due to the earlier $C_{Date}$ of CVE-2020-6519, its SecScore always
remains above the SecScore of CVE-2020-11023. This means that SecScore
suggests a greater prioritisation of CVE-2020-6519 than CVE-2020-11023 over
time, which proves to be productive since the $E_{Date}$ of the former
actually occurs before the $E_{Date}$ of the latter. This prioritisation would
also not be possible based solely on the CVSSv3.1 since both vulnerabilities
would have the same score in that scoring system.

Figure 10. SecScore evolution over time: vulnerabilities in different
platforms published in 2020-2022 ($7\leq$ CVSSv3.1 $\leq 8$).

#### (R5)

In another case, one can note that CVE-2020-11023 has its $C_{Date}$ earlier
than CVE-2020-23839 and, therefore, has a higher SecScore when CVE-2020-23839
is published. However, over time, the SecScore of CVE-2020-23839 ends up
surpassing the SecScore of CVE-2020-11023. This occurs due to two factors that
derive from the statistics of PHP vulnerabilities. First, in its $C_{Date}$,
CVE-2020-23839 has a greater probability of having an exploit code than
CVE-2020-11023 had in its $C_{Date}$, reducing the SecScore distance of both.
Secondly, the probability of an exploit code emerging for PHP vulnerabilities
grows faster than for vulnerability of the subcategory multiple, according to
the AL-based statistical models obtained in this study. In fact, the increase
in the SecScore values of CVE-2020-23839 in relation to those of
CVE-2020-11023 ends up providing better prioritisation, since the $E_{Date}$
of CVE-2020-23839 occurs before the $E_{Date}$ of CVE-2020-11023, as shown in
Figure 11. This is another example of prioritisation that would not be
possible based only on the equal CVSSv3.1 of these vulnerabilities, indicating
the value and timeliness of SecScore’s statistical models to the
prioritisation process.

Figure 11. SecScore evolution over time: vulnerabilities in different
platforms published in 2020 ($4\leq$ CVSSv3.1 $\leq 5$).

These examples demonstrate the contribution of SecScore to the vulnerability
prioritisation process, but do not exhaust the cases in which this can be
verified. SecScore not only leverages the information provided by CVSS but
also incorporates the time-dependent likelihood of existing an exploit code
for the vulnerabilities. By making use of statistical data on exploit codes,
SecScore incorporates the time into the score computation, making it
consistently change over time according to the vulnerability’s profile.

Another important aspect to highlight is that the vast majority of
vulnerabilities initially have their Exploit Code Maturity metric set to Not
Defined (i.e., $E=1$), and this classification tends to remain the same for
many years, as seen in Figure 1. It means that these vulnerabilities receive
the maximum score regarding this metric, being levelled with vulnerabilities
whose Exploit Code Maturity is classified as High. This can be
counterproductive from a prioritisation perspective, since the vulnerabilities
where $E$ is Not Defined in many cases an exploit code still does not exist.
In SecScore, the AL-based $E_{\mathbb{S}}(t)$ model presented in Figure 3
causes the value of the Exploit Code Maturity to vary dynamically over time
from the minimum value admitted by CVSS to its maximum (i.e., from Unproven to
High), in a manner proportional to the probability of the existence of an
exploit code. This approach gives fairer scores to vulnerabilities whose
exploit code is classified as Not Defined, allowing them to gain priority as
the probability of existing an exploit code increases (as shown in Figures 10
and 11). Evidently, if at any point an exploit code appears,
$E_{\mathbb{S}}(t)$ needs to be set to its maximum value (and so will do
SecScore), regardless of the time elapsed, exactly how it is done reactively
in CVSS nowadays.

It is worth mentioning that the results shown in this section do not take into
account other variables often used in a risk-based management process. The aim
here was to demonstrate how SecScore can contribute to vulnerability
prioritisation by leveraging statistical models built with empirical evidence
from real-world exploit codes. Notwithstanding, one can always integrate
SecScore with other works that use threat intelligence to specialise
vulnerability metrics (e.g., adapting the CVSS Environmental metric group
(Hore et al., 2023)) for the organisational infrastructure context (Walkowski,
2022).

##  6\. Conclusions

This paper presented SecScore, an innovative vulnerability risk score that
enhances the CVSS Threat metric group with empirical evidences for better
vulnerability prioritisation. SecScore leverages the well stablished metrics
and background from CVSS to complement it for vulnerability prioritisation in
risk-based management processed. SecScore is more explainable than related
works using machine learning and is flexible to be integrated into the
prioritisation stage from multiple vulnerability management processed reviewed
in Section 2. Moreover, the design of SecScore conducted to an empirical study
into the likelihood of existing exploits for a vulnerability (see Section 5.2)
and an experimental evaluation of SecScore (see Section 5.3), demonstrating
timeliness for vulnerability prioritisation.

### Acknowledgements

This work was partially supported by the Digital European Programme under the
ref. 101083770 and the Recovery and Resilience Plan (PRR) within the scope of
the Recovery and Resilience Mechanism (MRR) of the EU, framed in the Next
Generation EU within ATTRACT project, with ref. 774, and by the Fundação para
a Ciência e Tecnologia (FCT) through the LASIGE Research Unit, ref.
UIDB/00408/2020 (https://doi.org/10.54499/UIDB/00408/2020) and ref.
UIDP/00408/2020 (https://doi.org/10.54499/UIDP/00408/2020).

## References

  * (1)
  * Abuabed et al. (2023) Zaina Abuabed, Ahmad Alsadeh, and Adel Taweel. 2023.  STRIDE threat model-based framework for assessing the vulnerabilities of modern vehicles.  _Computers & Security_ 133 (2023), 103391.  https://doi.org/10.1016/j.cose.2023.103391
  * Albanese et al. (2023) Massimiliano Albanese, Ibifubara Iganibo, and Olutola Adebiyi. 2023.  A framework for designing vulnerability metrics.  _Computers & Security_ 132 (2023), 103382.  https://doi.org/10.1016/j.cose.2023.103382
  * Allodi (2015) Luca Allodi. 2015.  The Heavy Tails of Vulnerability Exploitation. Proc. of the International Symposium on Engineering Secure Software and Systems (ESSOS), 133–148.  https://doi.org/10.1007/978-3-319-15618-7_11
  * Ascend (2019) Team Ascend. 2019.  The Five Stages of Vulnerability Management.  https://blog.teamascend.com/stages-of-vulnerability-management.
  * Cavalancia (2020) Nick Cavalancia. 2020.  Vulnerability management explained.  https://cybersecurity.att.com/blogs/security-essentials/vulnerability-management-explained.
  * Chen et al. (2019) Haipeng Chen, Rui Liu, Noseong Park, and V.S. Subrahmanian. 2019.  Using Twitter to Predict When Vulnerabilities Will Be Exploited. In _Proc. of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining (KDD)_. 3143–3152.  https://doi.org/10.1145/3292500.3330742
  * Figueiredo et al. (2023) Cainã Figueiredo, João Gabriel Lopes, Rodrigo Azevedo, Daniel Vieira, Lucas Miranda, Gerson Zaverucha, Leandro Pfleger de Aguiar, and Daniel Sadoc Menasché. 2023.  A Statistical Relational Learning Approach Towards Products, Software Vulnerabilities and Exploits.  _IEEE Transactions on Network and Service Management (TNSM)_ (2023), 1–1.  https://doi.org/10.1109/TNSM.2023.3234554
  * FIRST—Forum of Incident Response and Security Teams, Inc. (2023a) FIRST—Forum of Incident Response and Security Teams, Inc. 2023a.  Common Vulnerability Scoring System (CVSS).  https://www.first.org/cvss/
  * FIRST—Forum of Incident Response and Security Teams, Inc. (2023b) FIRST—Forum of Incident Response and Security Teams, Inc. 2023b.  Exploit Prediction Scoring System (EPSS).  https://www.first.org/epss/
  * FIRST—Forum of Incident Response and Security Teams, Inc. (2024) FIRST—Forum of Incident Response and Security Teams, Inc. 2024.  Common Vulnerability Scoring System version 4.0 Specification Document - Version: 1.1.  https://www.first.org/cvss/v4-0/cvss-v40-specification.pdf
  * for Disease Control and Prevention (2021) Center for Disease Control and Prevention. 2021.  Vulnerability Management Life Cycle.  https://www.cdc.gov/cancer/npcr/tools/security/vmlc.htm.
  * Foreman (2019) Park Foreman. 2019.  _Vulnerability Management_.  CRC Press.
  * Greig (2021) Jonathan Greig. 2021.  With 18,378 vulnerabilities reported in 2021, NIST records fifth straight year of record numbers.  https://www.zdnet.com/article/with-18376-vulnerabilities-found-in-2021-nist-reports-fifth-straight-year-of-record-numbers/.
  * Hore et al. (2023) Soumyadeep Hore, Fariha Moomtaheen, Ankit Shah, and Xinming Ou. 2023.  Towards Optimal Triage and Mitigation of Context-Sensitive Cyber Vulnerabilities.  _IEEE Transactions on Dependable and Secure Computing (TDSC)_ 20, 2 (2023), 1270–1285.  https://doi.org/10.1109/TDSC.2022.3152164
  * Householder et al. (2020) Allen D. Householder, Jeff Chrabaszcz, Trent Novelly, David Warren, and Jonathan M. Spring. 2020.  Historical Analysis of Exploit Availability Timelines. In _Proc. of the 13th USENIX Workshop on Cyber Security Experimentation and Test (CSET)_.  https://www.usenix.org/conference/cset20/presentation/householder
  * Howland (2021) Henry Howland. 2021.  CVSS: Ubiquitous and Broken.  _Digital Threats: Research and Practice_ (2021).  https://doi.org/10.1145/3491263
  * Humphries (2020) Sam Humphries. 2020.  4 Stages of Vulnerability Management: A Process for Risk Mitigation.  https://www.exabeam.com/information-security/vulnerability-management/.
  * Jacobs et al. (2020) Jay Jacobs, Sasha Romanosky, Idris Adjerid, and Wade Baker. 2020.  Improving vulnerability remediation through better exploit prediction.  _Journal of Cybersecurity_ 6 (1 2020).  Issue 1. https://doi.org/10.1093/cybsec/tyaa015
  * Jacobs et al. (2021) Jay Jacobs, Sasha Romanosky, Benjamin Edwards, Idris Adjerid, and Michael Roytman. 2021.  Exploit Prediction Scoring System (EPSS).  _Digital Threats: Research and Practice_ 2 (7 2021), 1–17.  Issue 3. https://doi.org/10.1145/3436242
  * Jacobs et al. (2023) Jay Jacobs, Sasha Romanosky, Octavian Suciu, Ben Edwards, and Armin Sarabi. 2023.  Enhancing Vulnerability Prioritization: Data-Driven Exploit Predictions with Community-Driven Insights. In _Proc. of the IEEE European Symposium on Security and Privacy Workshops (EuroS &PW)_. IEEE, 194–206.  https://doi.org/10.1109/EuroSPW59978.2023.00027
  * Kozubowski and Podgórski (2000) Tomasz J Kozubowski and Krzysztof Podgórski. 2000.  A multivariate and asymmetric generalization of Laplace distribution.  _Computational Statistics_ 15 (2000), 531–540.  https://doi.org/10.1007/PL00022717
  * Kühn et al. (2023) Philipp Kühn, David N Relke, and Christian Reuter. 2023.  Common vulnerability scoring system prediction based on open source intelligence information sources.  _Computers & Security_ 131 (2023), 103286.  https://doi.org/10.1016/j.cose.2023.103286
  * Laboratory (2021) Information Technology Laboratory. 2021.  CVSS Severity Distribution Over Time.  https://nvd.nist.gov/general/visualizations/vulnerability-visualizations/cvss-severity-distribution-over-time.
  * Minohara and Shimakawa (2023) Takashi Minohara and Masaya Shimakawa. 2023.  Security Risk Growth Models for Software Vulnerability Assessment. In _Proc. of the 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W)_. IEEE, 32–35.  https://doi.org/10.1109/DSN-W58399.2023.00026
  * of Incident Response and Teams (2005) Forum of Incident Response and Security Teams. 2005.  Complete CVSS v1 Guide.  https://www.first.org/cvss/v1/guide.
  * of Incident Response and Teams (2019) Forum of Incident Response and Security Teams. 2019.  Common Vulnerability Scoring System v3.1: Specification Document.  https://www.first.org/cvss/v3.1/specification-document.
  * of Miami ([n. d.]) University of Miami. [n. d.].  Vulnerability Management.  https://web.archive.org/web/20230920064111/https://security.it.miami.edu/services/vulnerability-management/index.html.
  * OffSec Services Limited (2023) OffSec Services Limited. 2023.  Exploit Database - Exploits for Penetration Testers, Researchers, and Ethical Hackers.  https://www.exploit-db.com/.
  * Pyxyp Inc. (2023) Pyxyp Inc. 2023.  VulDB - Vulnerability Database.  https://vuldb.com/
  * Rapid7 ([n. d.]) Rapid7. [n. d.].  Vulnerability Management Process: Scanning, Prioritizing, and Remediating.  https://www.rapid7.com/fundamentals/vulnerability-management-and-scanning/.
  * Security (2023) OffSec Offensive Security. 2023.  ExploitDB - The official Exploit-Database repository.  https://gitlab.com/exploit-database/exploitdb.
  * SecurityScorecard, Inc. (2023) SecurityScorecard, Inc. 2023.  CVE security vulnerability database.  https://www.cvedetails.com/
  * Sharma et al. (2023) Abhishek Sharma, Sangeeta Sabharwal, and Sushama Nagpal. 2023.  A hybrid scoring system for prioritization of software vulnerabilities.  _Computers & Security_ 129 (2023), 103256.  https://doi.org/10.1016/j.cose.2023.103256
  * Spring et al. (2021) Jonathan Spring, Eric Hatleback, Allen Householder, Art Manion, and Deana Shick. 2021.  Time to Change the CVSS?  _IEEE Security & Privacy_ 19, 2 (2021), 74–78.  https://doi.org/10.1109/MSEC.2020.3044475
  * Spring et al. (2018) Jonathan Spring, Eric Hatleback, Allen D. Householder, Art Manion, and Deana Shick. 2018.  _Towards Improving CVSS_.  Technical Report. Carnegie Mellon University.
  * Storey et al. (2020) Margaret-Anne Storey, Neil A Ernst, Courtney Williams, and Eirini Kalliamvakou. 2020.  The who, what, how of software engineering research: a socio-technical framework.  _Empirical Software Engineering_ 25 (2020), 4097–4129.  https://doi.org/10.1007/s10664-020-09858-z
  * Tenable (2020a) Tenable. 2020a.  _How to Implement Risk-based Vulnerability Management_.  Technical Report. Tenable, Inc. 1–10 pages.
  * Tenable (2020b) Tenable. 2020b.  _Risk-based Vulnerability Management: Focus On The Vulnerabilities That Pose The Greatest Risk_.  Technical Report. Tenable, Inc. 1–14 pages.
  * Tenable (2020c) Tenable. 2020c.  _Your Answer to the Vulnerability Overload Problem: Risk-based Vulnerability Management_.  Technical Report. Tenable, Inc. 1–2 pages.
  * The MITRE Corporation (2023) The MITRE Corporation. 2023.  Common Vulnerabilities and Exposures (CVE).  https://www.cve.org
  * University (2021) Fordham University. 2021.  Vulnerability Management Procedure.  https://www.fordham.edu/info/29071/vulnerability_management_procedure.
  * Veríssimo et al. (2003) Paulo Esteves Veríssimo, Nuno Ferreira Neves, and Miguel Pupo Correia. 2003.  Intrusion-Tolerant Architectures: Concepts and Design. In _Architecting Dependable Systems_ , Rogério de Lemos, Cristina Gacek, and Alexander Romanovsky (Eds.). Springer, 3–36.  https://doi.org/10.1007/3-540-45177-3_1
  * Vulcan (2019) Vulcan. 2019.  _Vulnerability Management 2020: Navigating to New Heights_.  Technical Report. Vulcan Cyber Ltd. 1–10 pages.  https://www.bitpipe.com/detail/RES/1589403842_44.html
  * Walkowski (2022) Michał Walkowski. 2022.  VMC (OWASP Vulnerability Management Center).  https://github.com/DSecureMe/vmc.
  * Zeng et al. (2022) Zhen Zeng, Zhun Yang, Dijiang Huang, and Chun-Jen Chung. 2022.  LICALITY—Likelihood and Criticality: Vulnerability Risk Prioritization Through Logical Reasoning and Deep Learning.  _IEEE Transactions on Network and Service Management (TNSM)_ 19, 2 (2022), 1746–1760.  https://doi.org/10.1109/TNSM.2021.3133811