Deep transfer learning with fine-tuning (e.g., BERT with task-specific classification layer(s)) |  • Can improve the performance for tasks with small data (e.g., real-world exploit prediction) |  • Require target task to have similar nature as source task
Deep constrastive learning (e.g., Siamese neural networks) |  • Can improve performance for tasks with small data • Robust to class imbalance (e.g., CWE classes) |  • Computationally expensive (two inputs instead of one) • Do not directly produce class-wise probabilities
Deep multi-task learning |  • Can share features for predicting multiple tasks (e.g., CVSS metrics) simultaneously • Reduce training/maintenance cost |  • Require predicted tasks to be related • Hard to tune the performance of individual tasks
Element: Evaluation Technique
Single k-CV without test |  • Easy to implement • Reduce the randomness of results with multiple folds |  • No separate test set for validating optimized models (can resolve with separate test set(s)) • Maybe infeasible for expensive DL models • Use future data/SVs for training, may bias results
Single/multiple random train/ test with/without val (using val to tune hyperparameters) |  • Easy to implement • Reduce the randomness of results (the multiple version) |  • May produce unstable results (the single version) • Maybe infeasible for expensive DL models (the multiple version) • Use future data/SVs for training, may bias results
Single/multiple time-based train/test with/without val (using val to tune hyper- parameters) |  • Consider the temporal properties of SVs, simulating the realistic evaluation of ever-increasing SVs in practice • Reduce the randomness of results (the multiple version) |  • Similar drawbacks for the single & multiple versions as the random counterparts • May result in uneven/small splits (e.g., many SVs in a year)
Element: Evaluation Metric
F1-Score/Precision/Recall (classification) |  • Suitable for imbalanced data (common in SV assess- ment tasks) |  • Do not consider True Negatives in a confusion matrix (can resolve with Matthews Correlation Coefficient (MCC))
Accuracy (classification) |  • Consider all the cells in a confusion matrix |  • Unsuitable for imbalanced data (can resolve with MCC)
Area Under the Curve (AUC) (classification) |  • Independent of prediction thresholds |  • May not represent real-world settings (i.e., as models in practice mostly use fixed classification thresholds) • ROC-AUC may not be suitable for imbalanced data (can resolve with Precision-Recall-AUC)
Mean absolute (percentage) error/Root mean squared error (regression) |  • Show absolute performance of models |  • Maybe hard to interpret a value on its own without domain knowledge (i.e., whether an error of $x$ is sufficiently effective)
Correlation coefficient ($r$)/ Coef. of determination ($R^{2}$) (regression) |  • Show relative performance of models (0 – 1), where 0 is worst & 1 is best |  • $R^{2}$ always increases when adding any new feature (can resolve with adjusted $R^{2}$)

We extract and analyze the five key elements for data-driven SV assessment:
(i) Data sources, (ii) Model features, (iii) Prediction models, (iv)
Evaluation techniques and (v) Evaluation metrics. These elements correspond to
the four main steps in building data-driven models: data collection (data
sources), feature engineering (model features), model training (prediction
models) and model evaluation (evaluation techniques/metrics) [15, 197]. We
present the most common practices for each element in Table 12.

####  1 Data Sources

Identifying and collecting rich and reliable SV-related data are the first
tasks to build data-driven models for automating SV assessment tasks. As shown
in Table 12, a wide variety of data sources have been considered to accomplish
the five identified themes.

Across the five themes, NVD [16] and CVE [66] have been the most prevalently
used data sources. The popularity of NVD/CVE is mainly because they publish
expert-verified SV information that can be used to develop prediction models.
Firstly, many studies have considered SV descriptions on NVD/CVE as model
inputs. Secondly, the SV characteristics on NVD have been heavily used as
assessment outputs in all the themes, e.g., CVSS Exploitability metrics for
Exploitation, CVSS Impact/Scope metrics for Impact, CVSS severity score/levels
for Severity, CWE for Type, CWE/CPE for Miscellaneous tasks. Thirdly, external
sources on NVD/CVE have enabled many studies to obtain richer SV information
(e.g., exploitation availability/time [93] or vulnerable code/crashes [60,
61]) and extract relationships among multiple SV sources to develop a
knowledge graph of SVs (e.g., [154, 184]). However, NVD/CVE still suffer from
information inconsistencies [171, 141, 142] and missing relevant external
sources (e.g., SV fixing code) [198]. Such issues motivate future work to
validate/clean NVD data and utilize more sources for code-based SV assessment
(see section 9).

To enrich the SV information on NVD/CVE, many other security advisories and SV
databases have been commonly leveraged by the reviewed studies, notably
ExploitDB [67], Symantec [68, 199], SecurityFocus [72], CVE Details [187] and
OSVDB. Most of these sources disclose PoC (ExploitDB and OSVDB) and/or real-
world (Symantec and Security Focus) exploits. However, real-world exploits are
much rarer and different compared to PoC ones [33, 55]. It is recommended that
future work should explore more data sources (other than the ones in Table 3)
and better methods to retrieve real-world exploits, e.g., using semi-
supervised learning [200] to maximize the data efficiency for exploit
retrieval and/or few-shot learning for tackling the extreme exploit data
imbalance issue [201]. Additionally, CVE Details and OSVDB are SV databases
like NVD yet with a few key differences. CVE Details explicitly monitors
Exploit-DB entries that may be missed on NVD and provides a more user-friendly
interface to view/search SVs. OSVDB also reports SVs that do not appear on NVD
(without CVE-ID), but this site was discontinued in 2016.

Besides official/expert-verified data sources, we have seen an increasing
interest in mining SV information from informal sources that also contain non-
expert generated content such as social media (e.g., Twitter) and darkweb.
Especially, Twitter has been widely used for predicting exploits as this
platform has been shown to contain many SV disclosures even before official
databases like NVD [33, 140]. Recently, darkweb forums/sites/markets have also
gained traction as SV mentions on these sites have a strong correlation with
their exploits in the wild [48, 49]. However, SV-related data on these
informal sources are much noisier because they neither follow any pre-defined
structure nor have any verification and they are even prone to fake news [33].
Thus, the data integrity of these sources should be checked, potentially by
checking the reputation of posters, to avoid inputting unreliable data to
prediction models and potentially producing misleading findings.

####  2 Model Features

Collected raw data need to be represented by suitable features for training
prediction models. There are three key types of feature representation methods
in this area: term frequency (e.g., BoW, tf-idf and n-grams), DL learned
features (e.g., BERT and word2vec) and source/expert-defined metadata (e.g.,
CVSS metrics and CPE on NVD or tweet properties on Twitter), as summarized in
Table 12.

Regarding the term-frequency based methods, BoW has been the most popular one.
Its popularity is probably because it is one of the simplest ways to extract
features from natural language descriptions of SVs and directly compatible
with popular ML models (e.g., Linear SVM, Logistic regression and Random
forest) in section 3. Besides plain term count/frequency, other studies have
also considered different weighting mechanisms such as inverse document
frequency weighting (tf-idf) or tf-igm [128] inverse gravity moment weighting
(tf-igm). Tf-igm has been shown to work better than BoW and tf-idf at
classifying severity [124, 125]. Future work is still needed to evaluate the
applicability and generalizability of tf-igm for other SV assessment tasks.

Recently, Neural Network (NN) or DL based features such as word2vec [202] and
BERT [80] have been increasingly used to improve the performance of predicting
CVSS exploitation/impact/severity metrics [21, 103], CWE types [150] and SV
information retrieval [177, 178, 179]. Compared to BoW and its variants, NN
and DL can extract more efficient and context-aware features from vast SV data
[203]. NN/DL techniques rely on distributed representation to encode SV-
related words using fixed-length vectors much smaller than a vocabulary size.
Moreover, these techniques capture the sequential order and context (nearby
words) to enable better SV-related text comprehension (e.g., SV vs. general
exploit). Importantly, these NN/DL learned features can be first trained in a
non-SV domain with abundant data (e.g., Wikipedia pages [82]) and then
transferred/fine-tuned in the SV domain to address limited/imbalanced SV data
[56]. The main concern with these sophisticated NN/DL features is their
limited interpretability, which is an exciting future research area [204].

The metadata about SVs can also complement the missing information in
descriptions or code for SV assessment. For example, prediction of exploits
and their characteristics have been enhanced using CVSS metrics [49], CPE
[106] and SV types [57] on NVD. Additionally, Twitter-related statistics
(e.g., number of followers, likes and retweets) have been shown to increase
the performance of predicting SV exploitation, impact and severity [33, 93].
Recently, alongside features extracted from vulnerable code, the information
about a software development process and involved developers have also been
extracted to predict SV fixing effort [185]. Currently, metadata-based and
text-based features have been mainly integrated by concatenating their
respective feature vectors (e.g., [140, 92, 48, 49]). An alternative yet
unexplored way is to build separate models for each feature type and then
combine these models using meta-learning (e.g., model stacking [205]).

####  3 Prediction Models

The extracted features enter a wide variety of ML/DL-based prediction models
shown in Table 12 to automate various SV assessment tasks. Classification
techniques have the largest proportion, while regression and unsupervised
techniques are less common.

Linear SVM [206] has been the most frequently used classifier, especially in
the Exploitation, Impact and Severity themes. This popularity is reasonable as
Linear SVM works well with the commonly used features, i.e., BoW and tf-idf,
as mentioned in section 2. Besides Linear SVM, Random forest, Naïve Bayes and
Logistic regression have also been common classification models. In recent
years, advanced boosting models (e.g., XGBoost [78] and LGBM [79]), and more
lately, DL techniques (e.g., CNN [120] and (Bi-)LSTM with attention [117])
have been increasingly utilized and shown better results than simple ML models
like Linear SVM or Logistic regression. In this area, some DL models are
essential for certain tasks, e.g., building SV knowledge graph from multiple
sources with graph neural networks [115]. DL models also offer solutions to
data-related issues such as addressing class imbalance (e.g., deep Siamese
network [207]) or improving data efficiency (e.g., deep multi-task learning
[116]). Whenever applicable, it is recommended that future work should still
consider simple baselines alongside sophisticated ones as simple methods can
perform on par with advanced ones [208].

Besides classification, various prediction models have also been investigated
for regression (e.g., predicting exploit time, severity score and fixing
time). Linear SVM has again been the most commonly used regressor as SV
descriptions have usually been the regression input. Notably, many studies in
the Severity theme did not build regression models to directly obtain the
severity score (e.g., [96, 98, 100, 101, 22]). Instead, they used the formulas
defined by assessment frameworks (e.g., CVSS versions 2/3 [110, 111] or WIVSS
[136]) to compute the severity score from the base metrics predicted by
respective classification models. We argue that more effort should be invested
in determining the severity score directly from SV data as these severity
formulas can be subjective [209]. We also observe that there is still limited
use of DL models for regression compared to classification.

In addition to supervised (classification/regression) techniques, unsupervised
learning has also been considered for extracting underlying patterns of SV
data, especially in the Type theme. Latent Dirichlet Allocation (LDA) [30] has
been the most commonly used topic model to identify latent topics/types of SVs
without relying on a labeled taxonomy. The identified topics were mapped to
the existing SV taxonomies such as CWE [156] and OWASP [157, 158]. The topics
generated by topic models like LDA can also be used as features for
classification/regression models [105] or building topic-wise models to
capture local SV patterns [210]. However, definite interpretations for
unsupervised outputs are challenging to obtain as they usually rely on human
judgement [211].

####  4 Evaluation Techniques

It is important to evaluate a trained model to ensure the model meets certain
requirements (e.g., advancing the state-of-the-art). The evaluation generally
needs to be conducted on a different set of data other than the training set
to avoid overfitting and objectively estimate model generalizability [119].
The commonly used evaluation techniques are summarized in Table 12.

The reviewed studies have mostly used one or multiple validation and/or test
sets212121Validation set(s) helps optimize/tune a model (finding the best
task/data-specific hyperparameters), and test set(s) evaluates the
optimized/tuned model. Using only validation set(s) means evaluating a model
with default/pre-defined hyperparameters. to evaluate their models, in which
each validation/test set has been either randomly or time-based selected.
Specifically, k-fold cross-validation has been one of the most commonly used
techniques. The number of folds has usually been 5 or 10, but less standard
values like 4 [60] have also been used. However, k-fold cross-validation uses
all parts of data at least once for training; thus, there is no hidden test
set to evaluate the optimal model with the highest (cross-)validation
performance.

To address the lack of hidden test set(s), a common practice in the studied
papers has been to split a dataset into single training and test sets,
sometimes with an additional validation set for tuning hyperparameters to
obtain an optimal model. Recently, data has been increasingly split based on
the published time of SVs to better reflect the changing nature of ever-
increasing SVs [23].222222This study is presented in Chapter 2. However, the
results reported using single validation/test sets may be unstable (i.e.,
unreproducible results using different set(s)) [212].

To ensure both the time order and reduce the result randomness, we recommend
using multiple splits of training and test sets in combination with time-based
validation in each training set. Statistical analyses (e.g., hypothesis
testing and effect size) should also be conducted to confirm the reliability
of findings with respect to the randomization of models/data in multiple runs
[213].

####  5 Evaluation Metrics

Evaluating different aspects of a model requires respective proper metrics.
The popular metrics for evaluating the tasks in each theme are given in Table
12.

Across the five themes, Accuracy, Precision, Recall and F1-Score [214] have
been the most commonly used metrics because of a large number of
classification tasks in the five themes. However, Accuracy is not a suitable
measure for SV assessment tasks with imbalanced data (e.g., SVs with real-
world exploits vs. non-exploited SVs). The sample size of one class is much
smaller than the others, and thus the overall Accuracy would be dominated by
the majority classes. Besides these four commonly used metrics, AUC based on
the ROC curve (ROC-AUC) [214] has also been considered as it is threshold-
independent. However, we suggest that ROC-AUC should be used with caution in
practice as most deployed models would have a fixed decision threshold (e.g.,
0.5). Instead of ROC-AUC, we suggest Matthews Correlation Coefficient [214]
(MCC) as a more meaningful evaluation metric to be considered as it explicitly
captures all values in a confusion matrix, and thus has less bias in results.

For regression tasks, various metrics have been used such as Mean absolute
error, Mean absolute percentage error, Root mean squared error [22] as well as
Correlation coefficient ($r$) and Coefficient of determination ($R^{2}$)
[185]. Note that adjusted $R^{2}$ should be preferred over $R^{2}$ as $R^{2}$
would always increase when adding a new (even irrelevant) feature.

A model can have a higher value of one metric yet lower values of
others.232323https://stackoverflow.com/questions/34698161 Therefore, we
suggest using a combination of suitable metrics for a task of interest to
avoid result bias towards a specific metric. Currently, most studies have
focused on evaluating model effectiveness, i.e., how well the predicted
outputs match the ground-truth values. Besides effectiveness, other aspects
(e.g., efficiency in training/deployment and robustness to input changes) of
models should also be evaluated to provide a complete picture of model
applicability in practice.

###  9 Chapter Summary

SV assessment is crucial to optimize resource utilization in addressing SVs at
scale. This phase has witnessed radical transformations following the
increasing availability of SV data from multiple sources and advances in data-
driven techniques. We presented a taxonomy to summarize the five main
directions of the research work so far in this area. We also identified and
analyzed the key practices to develop data-driven models for SV assessment in
the reviewed studies.

Despite the great potential of data-driven approaches for SV assessment, we
highlighted the following three open challenges limiting the practical
application of the field:242424The presented challenges are the ones that have
been addressed in this thesis. More challenges related to data-driven SV
assessment can be found in Chapter 6.

  1. 1.

Unrealistic evaluation settings for report-level SV assessment models. Most of
the reviewed studies have evaluated their prediction models without capturing
many factors encountered during the deployment of such models to production.
Specifically, the models used in practice would require to handle new SV data
over time. In the context of report-level SV assessment, Out-of-Vocabulary
(OoV) words in SV descriptions of new SVs need to be properly accommodated to
avoid performance degradation of prediction models. The impact of using time-
based splits rather than random splits (e.g., k-fold cross-validation) for
these models to avoid leaking unseen (future) patterns to the model training
also requires further investigation. We address the first challenge in Chapter
2.

  2. 2.

Untimely SV assessment models. Although SV descriptions have been commonly
used as model inputs (see section 1), these descriptions are usually published
long after SVs introduced/discovered [25] and even after SV are fixed [215,
216] in codebases. One potential solution to this issue is to directly perform
SV assessment using (vulnerable) source code. The key benefit of using
vulnerable code for SV assessment is that such code is always
available/required before SV fixing. Thus, performing code-based SV assessment
can be done even when SV reports are not (yet) available. Version control
systems like GitHub252525https://github.com can provide such vulnerable code
for SV assessment. Leveraging data from these version control systems, we
address the second challenge in Chapters 3 and 4, in which data-driven SV
assessment is investigated on the code function and code commit levels,
respectively.

  3. 3.

Lack of utilization of developers’ real-world SV concerns. The current SV data
hardly contain specific developers’ concerns and practices when addressing
real-world SVs. Developer Question & Answer (Q&A) platforms like Stack
Overflow262626https://stackoverflow.com and Security
StackExchange272727https://security.stackexchange.com contain millions of
posts about different challenges and solutions shared by millions of
developers when tackling different software-related issues in real-world
scenarios. The rich data on Q&A sites can be collected and analyzed to
determine the key concerns that practitioners are facing while addressing SV
in practice. Such SV concerns can be incorporated into other technical metrics
like CVSS metrics for more thoroughly assessing and prioritizing SVs. For
example, the fixing effort of SVs may depend on the technical difficulty of
implementing the respective mitigation strategies in a language or system of
interest. We address the third challenge in Chapter 5.

###  10 Appendix - Ever-Growing Literature on Data-Driven SV Assessment

Given that data-driven SV assessment is an emerging field, there have been
many new contributions in this area since this literature review was conducted
in April 2021. In this appendix, we would like to briefly outline the recent
trends in data-driven SV assessment from May 1, 2021 to February 28, 2022 (at
the time of writing this thesis). We have also maintained a website
(https://github.com/lhmtriet/awesome-vulnerability-assessment) to keep track
of the latest contributions of data-driven SV assessment for researchers and
practitioners in the field.

To obtain new papers from May 2021 to February 2022, we followed the same
methodology of study selection, as described in section 2. We obtained 228 new
studies returned from the search on the online databases. We then applied the
inclusion/exclusion criteria, as given in Table 2, on the titles, abstracts
and full-texts of the curated papers to obtain the list of relevant papers.
After the filtering steps, we selected 18 papers relevant to data-driven SV
assessment from May 2021 to February 2022.282828We do not claim that this list
of updated papers is complete, yet we believe that we have covered the
representative ones. It should also be noted that we did not include our own
papers as these papers would be presented in subsequent chapters of this
thesis. The categorization of these selected papers into the five themes, as
described in section 3, is given in Table 13.

Table 13: The mapping between the themes/tasks and the respective studies collected from May 2021 to February 2022. Theme/Task | Studies
---|---
Exploitation Prediction |  [217], [218], [219], [220], [221], [222], [223], [224], [225]
Impact Prediction |  [218], [219], [220], [222], [225]
Severity Prediction |  [218], [219], [220], [222], [225]
Type Prediction |  [226], [227], [228], [229], [230]
Miscellaneous Tasks |  [218], [231], [232], [233], [234]

The key patterns and practices of these 18 papers are summarized as follows:

  * •

All the tasks tackled by the studies have aligned with the ones presented in
this literature review, reinforcing the robustness of our taxonomy presented
in Fig. 1.

  * •

Among the themes, Exploitation has attracted the most contributions from these
new studies, similar to that of the reviewed papers prior to May 2021. In
addition, prediction of the CVSS exploitability, impact, and severity metrics
is still the most common task. However, it is encouraging to see that more
studies have worked on CVSS version 3.1, which is closer to the current
industry standard.

  * •

Regarding data sources, NVD/CVE is still most prevalently used. Besides CAPEC
[122], MITRE ATT&CK Framework292929https://attack.mitre.org/ is a new source
of attack patterns being utilized [217].

  * •

Regarding model features, BERT [80] has been commonly used to extract
contextual feature embeddings from SV descriptions for various tasks.

  * •

Regarding prediction models, DL techniques, which are mainly based on CNN
and/or (Bi-)LSTM with attention, have been increasingly used to improve the
performance of the tasks.

  * •

Regarding evaluation techniques and evaluation metrics, since most of the
tasks are the same as before, evaluation practices have largely stayed the
same as the ones presented in sections 4 and 5.

Overall, the three key practical challenges presented in section 9 are still
not addressed by the new studies. Thus, we believe that our
contributions/solutions to address these challenges in this thesis would set
the foundation for future research to further improve the practical
applicability of SV assessment using data-driven approaches.

##  Chapter 2 Automated Report-Level Software Vulnerability Assessment with
Concept Drift

Related publication: This chapter is based on our paper titled “Automated
Software Vulnerability Assessment with Concept Drift” published in the 16th
International Conference on Mining Software Repositories (MSR), 2019 (CORE A)
[23].

In our literature review in Chapter 1, Software Engineering researchers are
increasingly using Natural Language Processing (NLP) techniques to automate
Software Vulnerability (SV) assessment using SV descriptions in public
repositories. However, the existing NLP-based approaches suffer from _concept
drift_. This problem is caused by a lack of proper treatment of new (out-of-
vocabulary) terms for evaluating unseen SVs over time. To perform automated SV
assessment with _concept drift_ using SV descriptions present in SV reports,
in Chapter 2, we propose a systematic approach that combines both character
and word features. The proposed approach is used to predict seven
Vulnerability Characteristics (VCs). The optimal model of each VC is selected
using our customized time-based cross-validation method from a list of eight
NLP representations and six well-known Machine Learning models. We use the
proposed approach to conduct large-scale experiments on more than 100,000 SVs
in National Vulnerability Database (NVD). The results show that our approach
can effectively tackle the _concept drift_ issue of the SVs’ descriptions
reported from 2000 to 2018 in NVD even without retraining the model. In
addition, our approach performs competitively compared to the existing word-
only method. We also investigate how to build compact _concept-drift_ -aware
models with much fewer features and give some recommendations on the choice of
classifiers and NLP representations for report-level SV assessment.

###  1 Introduction

Software Vulnerability (SV) reports in public repositories, such as National
Vulnerability Database (NVD) [16], have been widely leveraged to automatically
predict SV characteristics using data-driven approaches (see Chapter 1).
However, data in these SV reports have the temporal property since many new
terms appear in the descriptions of SVs. Such terms are a result of the
release of new technologies/products or the discovery of a zero-day attack or
SV; for example, NVD received more than 13,000 new SVs in 2017 [16]. The
appearance of new concepts makes SV data and patterns change over time [160,
152, 156], which is known as _concept drift_ [34]. For example, the keyword
Android has only started appearing in NVD since 2008, the year when Google
released Android. We assert that such new SV terms can cause problems for
building report-level SV assessment models.

Previous studies [22, 49, 32] have suffered from _concept drift_ as they have
usually mixed new and old SVs in the model validation step. Such approach
accidentally merges new SV information with existing one, which can lead to
biased results. Moreover, the previous work of SV analysis [22, 20, 49, 32,
97, 95, 47] used predictive models with only word features without reporting
how to handle novel or extended concepts (e.g., new versions of the same
software) in new SVs’ descriptions. Research on machine translation [235, 236,
237, 238] has shown that unseen (Out-of-Vocabulary (OoV)) terms can make
existing word-only models less robust to future prediction due to their
missing information. For SV prediction, Han et al. [21] did use random
embedding vectors to represent the OoV words, which still discards the
relationship between new and old concepts. Such observations motivated us to
tackle the research problem “How to handle the _concept drift_ issue of the SV
descriptions in public repositories to improve the robustness of automated
report-level SV assessment?” It appears to us that it is important to address
the issue of _concept drift_ to enable the practical applicability of
automated SV assessment tools. To the best of our knowledge, there has been no
existing work to systematically address the _concept drift_ issue in report-
level SV assessment.

To perform report-level SV assessment with _concept drift_ using SV
descriptions in public repositories, we present a Machine Learning (ML) model
that utilizes both character-level and word-level features. We also propose a
customized time-based version of cross-validation method for model selection
and validation. Our cross-validation method splits the data by year to embrace
the temporal relationship of SVs. We evaluate the proposed model on the
prediction of seven Vulnerability Characteristics (VCs), i.e.,
Confidentiality, Integrity, Availability, Access Vector, Access Complexity,
Authentication, and Severity. Our key contributions are:

  1. 1.

We demonstrate the _concept drift_ issue of SVs using concrete examples from
NVD.

  2. 2.

We investigate a customized time-based cross-validation method to select the
optimal ML models for SV assessment. Our method can help prevent future SV
information from being leaked into the past in model selection and validation
steps.

  3. 3.

We propose and extensively evaluate an effective Character-Word Model (CWM) to
assess SVs using the descriptions with _concept drift_. We also investigate
the performance of low-dimensional CWM models. We provide our models and
associated source code for future research at
https://github.com/lhmtriet/MSR2019.

Chapter organization. Section 2 introduces SV descriptions and VCs. Section 3
describes our proposed approach. Section 4 presents the experimental design of
this work. Section 5 analyzes the experimental results and discusses the
findings. Section 6 identifies the threats to validity. Section 7 covers the
related works. Section 8 concludes and suggests some future directions.

###  2 Background

Figure 1: Frequencies of each class of the seven VCs.

Software Vulnerability (SV) assessment is an important step in the SV
lifecycle, which determines various characteristics of detected SVs [10]. Such
characteristics support developers to understand the nature of SVs, which can
inform prioritization and remediation strategies. For example, if an SV can
severely damage the confidentiality of a system, e.g., allowing attackers to
access/steal sensitive information, this SV should have a high fixing
priority. A fixing protocol to ensure confidentiality can then be followed,
e.g., checking/enforcing privileges to access the affected component/data.

National Vulnerability Database [16] (NVD) is one of the most popular and
trustworthy sources for SV assessment. NVD is maintained by governmental
bodies (National Cyber Security and Division of the United States Department
of Homeland Security). This site inherits unique SV identifiers and
descriptions from Common Vulnerabilities and Exposures (CVE) [66]. For SV
assessment, NVD provides expert-verified assessment metrics, namely Common
Vulnerability Scoring System (CVSS) [29], for each reported SV.

CVSS is one of the most commonly used frameworks by both researchers and
practitioners to perform SV assessment. There are two main versions of CVSS,
namely versions 2 and 3, in which version 3 only came into effect in 2015.
CVSS version 2 is still widely used as many SVs prior to 2015 can yet pose
threats to contemporary systems. For instance, the SV with CVE-2004-0113 first
found in 2004 was exploited in 2018 [239]. Hence, we adopt the assessment
metrics of CVSS version 2 as the outputs for the SV assessment models in this
study.

CVSS version 2 provides metrics to quantify the three main aspects of SVs,
namely exploitability, impact, and severity. We focus on the base metrics
because the temporal metrics (e.g., exploit availability in the wild) and
environmental metrics (e.g., potential impact outside of a system) are
unlikely obtainable from project artifacts (e.g., SV code/reports) alone.
Specifically, the base Exploitability metrics examine the technique (Access
Vector) and complexity to initiate an exploit (Access Complexity) as well as
the authentication requirement (Authentication). The base Impact metrics of
CVSS focus on the system Confidentiality, Integrity, and Availability. The
Exploitation and Impact metrics are used to compute the Severity of SVs.
Severity approximates the criticality of an SV. Nevertheless, relying solely
on Severity may be insufficient because an SV with medium severity may still
have high impacts as it is considerably complex to be exploited. It is
important to assign a high fixing priority to such an SV as an affected system
would face tremendous risks in case of a successful cyber-attack. Therefore,
in this study, we consider all the base metrics of CVSS version 2 (i.e.,
Confidentiality, Integrity, Availability, Access Vector, Access Complexity,
Authentication and Severity), as shown in Fig. 1, for developing SV assessment
models. From the perspective of ML, predicting CVSS metrics is a
classification problem, which can be solved readily using ML algorithms. It is
noted that Access Vector, Access Complexity and Authentication characteristics
suffer the most from the issue of imbalanced data, in which the number of
elements in the minority class is much smaller compared to those of the other
classes.

###  3 The Proposed Approach

####  1 Approach Overview

Figure 2: Workflow of our proposed model for report-level software
vulnerability assessment with _concept drift_.

The overall workflow of our proposed approach is given in Fig. 2. Our approach
consists of three processes: model selection, model building and prediction.
The first two processes work on the training set, while the prediction process
performs on either a separate testing set or new SV descriptions. The first
model selection has two steps: Text preprocessing and Time-based k-fold cross-
validation. The text preprocessing step (see section 2) is necessary to reduce
noise in text to build a better assessment model. Next, the preprocessed text
enters the time-based k-fold cross-validation step to select the optimal
classifier and Natural Language Processing (NLP) representations for each VC.
It should be noted that this step only tunes the word-level models instead of
the combined models of both word and character features. One reason is that
the search space of the combined model is much larger than that of the word-
only model since we at least have to consider different NLP representations
for character-level features. The computational resource to extract character-
level n-grams is also more than that of word-level counterparts. Section 3
provides more details about the time-based k-fold cross-validation method.

Next comes the model building process with four main steps: (_i_) word n-grams
generation, (_ii_) character n-grams generation, (_iii_) feature aggregation
and (_iv_) character-word model building. Steps (_i_) and (_ii_) use the
preprocessed text in the previous process to generate word and character
n-grams based on the identified optimal NLP representations of each VC. The
word n-grams generation step (_i_) here is the same as the one in the time-
based k-fold cross-validation of the previous process. An example of the word
and character n-grams in our approach is given in Table 1. Such character
n-grams increase the probability of capturing parts of OoV terms due to
_concept drift_ in SV descriptions. Subsequently, both levels of the n-grams
and the optimal NLP representations are input into the feature aggregation
step (_iii_) to extract features from the preprocessed text using our proposed
algorithm in section 4. This step also combines the aggregated character and
word vocabularies with the optimal NLP representations of each VC to create
the feature models. We save such models to transform data of future
prediction. In the last step (_iv_), the extracted features are trained with
the optimal classifiers found in the model selection process to build the
complete character-word models for each VC to perform automated report-level
SV assessment with _concept drift_.

In the prediction process, a new SV description is first preprocessed using
the same text preprocessing step. Then, the preprocessed text is transformed
to create features by the feature models saved in the model building process.
Finally, the trained character-word models use such features to determine each
VC.

Table 1: Word and character n-grams extracted from the sentence “Hello World”. ‘_’ represents a space. n-grams | Words | Characters
---|---|---
1 | Hello, World | H, e, l, l, o, W, o, r, l, d
2 | Hello World | He, el, ll, lo, o_, _W, Wo, or, rl, ld

####  2 Text Preprocessing of SV Descriptions

The text preprocessing is an important step for any NLP task [240]. We use the
following text preprocessing techniques: (_i_) removal of stop words and
punctuations, (_ii_) conversion to lowercase and (_iii_) stemming. The stop
words are combined from the default lists of the _scikit-learn_ [241] and
_nltk_ [242] libraries. We only remove the punctuations followed by at least
one space or the ones at the end of a sentence. This punctuation removal
method keeps important words in the software and security contexts such as “
_input.c_ ”, “ _man-in-the-middle_ ”, “ _cross-site_ ”.

Subsequently, the stemming step is done using the Porter Stemmer algorithm
[243] in the _nltk_ library. Stemming is needed to avoid two or more words
with the same meaning but in different forms (e.g., “ _allow_ ” vs. “ _allows_
”). The main goal of stemming is to retrieve consistent features (words), thus
any algorithm that can return each word’s root should work. Researchers may
use lemmatization, which is relatively slower as it also considers the
surrounding context.

####  3 Model Selection with Time-based k-Fold Cross-Validation

Figure 3: Our proposed time-based cross-validation method. Note: x is the
final year in the original training set and k is the number of cross-
validation folds.

We propose a time-based cross-validation method (see Fig. 3) to select the
best classifier and NLP representation for each VC. The idea has been inspired
by the time-series domain [244]. As shown in Fig. 2, our method has four
steps: (_i_) data splitting, (_ii_) word n-grams generation, (_iii_) feature
transformation, and (_iv_) model training and evaluation. Data splitting
explicitly considers the time order of SVs to ensure that in each pass/fold,
the new information of the validation set does not exist in the training set,
which maintains the temporal property of SVs. New terms can appear at
different time during a year; thus, the preprocessed text in each fold is
split by year explicitly, not by equal sample size as in traditional time-
series splits;111https://scikit-
learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.html
e.g., SVs from 1999 to 2010 are for training and those in 2011 are for
validation in a pass/fold.

Table 2: The eight configurations of NLP representations used for model selection. Note: ‘✓’ is selected, ‘-’ is non-selected. Configuration | Word n-grams | tf-idf
---|---|---
1 | 1 | -
2 | 1 | ✓
3 | 1-2 | -
4 | 1-3 | -
5 | 1-4 | -
6 | 1-2 | ✓
7 | 1-3 | ✓
8 | 1-4 | ✓

After data splitting in each fold, we use the training set to generate the
word n-grams. Subsequently, with each of the eight NLP configurations in Table
2, the feature transformation step uses the word n-grams as the vocabulary to
transform the preprocessed text of both training and validation sets into the
features for building a model. We create the NLP configurations from various
values of n-grams combined with either term frequency or tf-idf measure. Uni-
gram with term frequency is also called Bag-of-Words (BoW). These NLP
representations have been selected since they are popular and have performed
well for SV analysis [22, 49, 95]. For each NLP configuration, the model
training and evaluation step trains six classifiers (see section 3) on the
training set and then evaluates the models on the validation set using
different evaluation metrics (see section 4). The model with the highest
average cross-validated performance is selected for a VC. The process is
repeated for every VC, then the optimal classifiers and NLP representations
are returned for all seven VCs.

####  4 Feature Aggregation Algorithm

We propose Algorithm 1 to combine word and character n-grams in the model
building process to create features for our character-word model. Six inputs
of the algorithm are (_i_) input descriptions, (_ii_) word n-grams, (_iii_)
character n-grams, (_iv_) the minimum, (_v_) the maximum number of character
n-grams, and (_vi_) the optimal NLP configuration of a VC. The main output is
a feature matrix containing the term weights of the documents transformed by
the aggregated character and word vocabularies to build the character-word
models. We also output the character and word feature models for future
prediction of VCs.

1

Input: List of SV descriptions: ${D}_{in}$

Set of word-level n-grams:
${F}_{w}=\\{{{f}_{1w}},{{f}_{2w}},...,{{f}_{nw}}\\}$

Set of character-level n-grams:
${F}_{c}=\\{{{f}_{1c}},{{f}_{2c}},...,{{f}_{mc}}\\}$

The minimum and maximum character n-grams: ${min}_{n-gram}$ and
${max}_{n-gram}$

The optimal NLP configuration of the current VC: _config_

Output: The aggregated data matrix: ${\mathbf{X}}_{agg}$

The word and character feature models: ${\text{model}}_{w},{\text{model}}_{c}$

2

3$slt\\_chars\leftarrow\emptyset$

4

5foreach  _${f}_{i}\in{F}_{c}$_ do

6 $tokens\leftarrow{f}_{i}$ trimmed and split by space

7

8 if  _(size of $tokens$ = 1) and ((length of the first element in $tokens$)
$>$ 1)_ then

9 $slt\\_chars\leftarrow slt\\_chars+\\{tokens\\}$

10

11

12

13 $diff\\_words\leftarrow{F}_{w}-slt\\_chars$

14

15
${\text{model}}_{w}\leftarrow\text{Feature\\_transformation}(diff\\_words,config)$

16

17
${\text{model}}_{c}\leftarrow\text{Feature\\_transformation}(slt\\_chars,{min}_{n-gram}-1,{max}_{n-gram},config)$

18

19 ${\mathbf{X}}_{word}\leftarrow{D}_{in}$ transformed with
${\text{model}}_{w}$

20 ${\mathbf{X}}_{char}\leftarrow{D}_{in}$ transformed with
${\text{model}}_{c}$

21
${\mathbf{X}}_{agg}\leftarrow\text{horizontal\\_append}({\mathbf{X}}_{word},{\mathbf{X}}_{char})$

22

23 return ${\mathbf{X}}_{agg}$, ${\text{model}}_{w}$, ${\text{model}}_{c}$

Algorithm 1 Feature aggregation algorithm to transform the documents with the
aggregated word and character-level features.

Steps 2-7 of the algorithm filter the character features. More specifically,
step 3 removes (trims) spaces from both ends of each feature. Then, we split
such feature by space(s) to determine how many words to which the character(s)
belongs. Subsequently, steps 4-6 retain only the character features that are
parts of single words (size of $tokens$ = 1), except the single characters
such as $x$, $y$, $z$ ((length of the first element in $tokens$) $>$ 1). The
n-gram characters with space(s) in between represent more than one word, which
can make a classifier more prone to overfitting. Similarly, single characters
are too short and they can belong to too many words, which is likely to make a
model hardly generalizable. In fact, ‘ _a_ ’ is a meaningful single character,
but it has been already removed as a stop word. The characters can even
represent a whole word (e.g., “ _attack_ ” token with
${max}_{n-gram}\geq\,6$). In such cases, step 8 removes duplicated word-level
features (${F}_{w}-slt\\_chars$). Based on the assumption that unseen or
misspelled terms can share common characters with existing words, such choice
can enhance the probability of a model capturing the OoV words in new
descriptions. Retaining only the character features also helps reduce the
number of features and model overfitting. After that, steps 9-10 define the
feature models ${\text{model}}_{w}$ and ${\text{model}}_{c}$ using the word
($diff\\_words$) and character ($slt\\_chars$) vocabularies, respectively,
along with the NLP configurations to transform the input documents into
feature matrices for building an assessment model. Steps 11-12 then use the
two defined word and character models to actually transform the input
documents into the feature matrices ${\mathbf{X}}_{word}$ and
${\mathbf{X}}_{word}$, respectively. Step 13 concatenates the two feature
matrices by columns. Finally, step 14 returns the final aggregated feature
matrix ${\mathbf{X}}_{agg}$ along with the word and character feature models
${\text{model}}_{w}$ and ${\text{model}}_{c}$.

###  4 Experimental Design and Setup

All the classifiers and NLP representations (n-grams, term frequency and tf-
idf) in this work were implemented in the _scikit-learn_ [241] and _nltk_
[242] libraries in Python. Our code ran on a fourth-generation Intel Core
i7-4200HQ CPU (four cores) running at 2.6 GHz with 16 GB of RAM.

####  1 Research Questions

Our research aims at addressing the _concept drift_ issue in SVs’ descriptions
to improve the robustness of both model selection and prediction steps of
report-level SV assessment. Specifically, we evaluate our two-phase character-
word models. The first phase selects the optimal word-only models for each VC.
The second phase incorporates character features to build character-word
models. We raise and answer four Research Questions (RQs):

  * •

RQ1: _Is our time-based cross-validation more effective than a non-temporal
method to handle concept drift in the model selection step for report-level SV
assessment?_ To answer RQ1, we first identify the new terms in SV
descriptions. We associate such terms with their release or discovery years.
We then use qualitative examples to demonstrate information leakage in the
non-temporal model selection step. We also quantitatively compare the
effectiveness of the proposed time-based cross-validation method with a
traditional non-temporal one for addressing the temporal relationship in the
context of report-level SV assessment.

  * •

RQ2: _Which are the optimal models for multi-classification of each SV
characteristic?_ To answer RQ2, we present the optimal models (i.e.,
classifiers and NLP representations) using word features for each VC selected
by a five-fold time-based cross-validation method (see section 3). We also
compare the performance of different classes of models (single vs. ensemble)
and NLP representations to give recommendations for future use.

  * •

RQ3: _How effective is our character-word model to perform automated report-
level SV assessment with concept drift?_ For RQ3, we first demonstrate how the
OoV phrases identified in RQ1 can affect the performance of the existing word-
only models. We then highlight the ability of the character features to handle
the _concept drift_ issue of SVs. We also compare the performance of our
character-word model with those of the word-only (without handling _concept
drift_) and character-only models.

  * •

RQ4: _To what extent can low-dimensional model retain the original
performance?_ The features of our proposed model in RQ3 are high-dimensional
and sparse. Hence, we evaluate a dimensionality reduction technique (i.e.,
Latent Semantic Analysis [245]) and the sub-word embeddings (i.e., fastText
[196, 246]) to show how much information of the original model is approximated
in lower dimensions. RQ4 findings can facilitate the building of more
efficient _concept-drift_ -aware predictive models.

####  2 Dataset

We retrieved 113,292 SVs from NVD in JSON format. The dataset contains the SVs
from 1988 to 2018. We discarded 5,926 SVs that contain “** REJECT **” in their
descriptions since they had been confirmed duplicated or incorrect by experts.
Seven VCs of CVSS 2 (see section 2) were used as our SV assessment metrics. It
turned out that there are 2,242 SVs without any value of CVSS 2. Therefore, we
also removed such SVs from our dataset. Finally, we obtained a dataset
containing 105,124 SVs along with their descriptions and the values of seven
VCs indicated previously. For evaluation purposes, we followed the work in
[22] to use the year of 2016 to divide our dataset into training and testing
sets with the sizes of 76,241 and 28,883, respectively. The primary reason for
splitting the dataset based on the time order is to consider the temporal
relationship of SVs.

####  3 Machine Learning Models for Report-Level SV Assessment

To solve our multi-class classification (report-level SV assessment) problem,
we used six well-known ML models. These classifiers have achieved great
results in recent data science competitions such as Kaggle [247]. We provide
brief descriptions and the hyperparameters of each classifier below.

  * •

Naïve Bayes (NB) [248] is a simple probabilistic model that is based on Bayes’
theorem. This model assumes that all the features are conditionally
independent with respect to each other. In this study, NB had no tuning
hyperparameter during the validation step.

  * •

Logistic Regression (LR) [249] is a linear classifier in which the logistic
function is used to convert a linear output into a respective probability. The
one-vs-rest scheme was applied to split the multi-class problem into multiple
binary classification problems. In this work, we selected the optimal value of
the regularization parameter for LR from the list of values: 0.01, 0.1, 1, 10,
100.

  * •

Support Vector Machine (SVM) [206] is a classification model in which a
maximum margin is determined to separate the classes. For NLP, the linear
kernel is preferred because of its more scalable computation and sparsity
handling [250]. The tuning regularization values of SVM are the same as LR.

  * •

Random Forest (RF) [251] is a bagging model in which multiple decision trees
are combined to reduce the variance and sensitivity to noise. The complexity
of RF is mainly controlled by (_i_) the number of trees, (_ii_) maximum depth,
and (_iii_) maximum number of leaves. (_i_) tuning values were: 100, 300, 500.
We set (_ii_) to _unlimited_ , which makes the model the highest degree of
flexibility and easier to adapt to new data. For (_iii_), the tuning values
were 100, 200, 300 and _unlimited_.

  * •

XGBoost - Extreme Gradient Boosting (XGB) [78] is a variant Gradient Boosting
Tree Model (GBTM) in which multiple weak tree-based classifiers are combined
and regularized to enhance the robustness of the overall model. Three
hyperparameters of XGB that require tuning were the same as RF. It should be
noted that the _unlimited_ value of the maximum number of leaves is not
applicable to XGB.

  * •

Light Gradient Boosting Machine (LGBM) [79] is a light-weight version of GBTM.
Its main advantage is the scalability since the sub-trees are grown in a leaf-
wise manner rather than depth-wise of other GBT algorithms. Three
hyperparameters of LGBM that require tuning were the same as XGB.

In this work, we considered NB, LR and SVM as single models, while RF, XGB and
LGBM as ensemble models.

####  4 Evaluation Metrics

Our multi-class classification problem can be decomposed into multiple binary
classification problems. To define the standard evaluation metrics for a
binary problem [22, 20, 21], we first describe four possibilities as follows.

  * •

True positive (_TP_): The classifier correctly predicts that an SV has a
particular characteristic.

  * •

False positive (_FP_): The classifier incorrectly predicts that an SV has a
particular characteristic.

  * •

True negative (_TN_): The classifier correctly predicts that an SV does not
have a particular characteristic.

  * •

False negative (_FN_): The classifier incorrectly predicts that an SV does not
have a particular characteristic.

Based on _TP_ , _FP_ , _TN_ , _FN_ , _Accuracy_ , _Precision_ , _Recall_ and
_F1-Score_ can be defined accordingly in (1), (2), (3), (4).

$Accuracy\,\,=\,\,\frac{TP\,+\,TN}{TP+\,FP\,+\,TN\,+\,FN}$ (1)

$Precision\,=\,\frac{TP}{TP\,+\,FP}$ (2)

$Recall\,=\,\frac{TP}{TP\,+\,FN}$ (3)

$F1-Score\,=\,\frac{2\,\times\,Precision\,\times\,Recall}{Precision\,+\,Recall}$
(4)

Whilst _Accuracy_ measures the global performance of all classes, _F1-Score_
(a harmonic mean of _Precision_ and _Recall_) evaluates each class separately.
Such local estimate like F1-Score is more favorable to the imbalanced VCs such
as Access Vector, Access Complexity, Authentication, Severity (see Fig. 1). In
fact, there are several variants of _F1-Score_ for a multi-class
classification problem, namely _Micro_ , _Macro_ and Weighted _F1-Scores_. In
the case of multi-class classification, _Micro F1-Score_ is actually the same
as _Accuracy_. For _Macro_ and _Weighted F1-Scores_ , the former does not
consider class distribution (the number of elements in each class) for
computing _F1-Score_ of each class; whereas, the latter does. To account for
the balanced and imbalanced VCs globally and locally, we used _Accuracy_ ,
_Macro_ , and _Weighted F1-Scores_ to evaluate our models. For model
selection, if there was a performance tie among models regarding _Accuracy_
and/or _Macro F1-Score_ , _Weighted F1-Score_ would be chosen as the
discriminant criterion. The reason is that _Weighted F1-Score_ can be
considered a compromise between _Macro F1-Score_ and _Accuracy_. If the tie
still existed, the less complex model with the smaller number of
hyperparameters would be selected as per the Occam’s razor principle [252]. In
the last tie scenario, the model with shorter training time would be chosen.

Figure 4: The number of new terms from 2000 to 2017 of SV descriptions in NVD.

###  5 Experimental Results and Discussion

####  1 RQ1: Is Our Time-Based Cross-Validation More Effective Than a Non-
Temporal Method to Handle Concept Drift in The Model Selection Step for
Report-Level SV Assessment?

Figure 5: Examples of new terms in NVD corresponding to new products,
software, cyber-attacks from 2000 to 2018. Note: The year of release/discovery
is put in parentheses.

We performed both qualitative and quantitative analyses to demonstrate the
relationship between _concept drift_ and the model selection step of report-
level SV assessment. Firstly, it is intuitive that data of SVs intrinsically
change over time because of new products, software and attack vectors. The
number of new terms appearing in the NVD descriptions each year during the
period from 2000 to 2017 is given in Fig. 4. On average each year, there were
7345 new terms added to the vocabulary. Moreover, from 2015 to 2017, the
number of new terms had been consistently increasing and achieved an all-time
high value of 14684 in 2017. We also highlight some concrete examples about
the terms appearing in the database after a particular technology, product or
attack was released in Fig. 5. There seems to be a strong correlation between
the time of appearance of some new terms in the descriptions and their years
of release or discovery. Such unseen terms contained many concepts about new
products (e.g., _Firefox_ , _Skype_ , and _iPhone_), operating systems (e.g.,
_Android_ , _Windows Vista/7/8/10_), technologies (e.g., _Ajax_ , _jQuery_ ,
and _Node.js_), attacks (e.g., _Code Red_ , _Slammer_ , and _Stuxnet_ worms).
There were also the extended forms of existing ones such as the updated
versions of Java Standard Edition (Java SE) each year. These qualitative
results depict that if the time property of SVs is not considered in the model
selection step, then future terms can be mixed with past ones. Such
information leakage can result in a discrepancy in the real-world model
performance.

Figure 6: Performance differences between the validated and testing _Weighted
F1-Scores_ of our time-based validation and a normal cross-validation methods.

In fact, the main goal of the validation step is to select the optimal models
that can exhibit similar behavior on unseen data. Next, our approach
quantitatively compared the degree of model overfitting between our time-based
cross-validation method and a stratified non-temporal one used in [22, 20].
For each method, we computed the _Weighted F1-Scores_ difference between the
cross-validated and testing results of the optimal models found in the
validation step (see Fig. 6). The model selection and selection criteria
procedures of the normal cross-validation method were the same as our temporal
one. Fig. 6 shows that traditional non-temporal cross-validation was
overfitted in four out of seven cases (i.e., Availability, Access Vector,
Access Complexity, and Authentication). Especially, the degrees of overfitting
of non-temporal validation method were 1.8, 4.7 and 1.8 times higher than
those of the time-based version for Availability, Access Vector, and Access
Complexity, respectively. For the other three VCs, both methods were similar,
in which the differences were within 0.02. Moreover, on average, the _Weighted
F1-Scores_ on the testing set of the non-temporal cross-validation method were
only 0.002 higher than our approach. This value is negligible compared to the
difference of 0.02 (ten times more) in the validation step. It is worth noting
that a similar comparison also held for non-stratified non-temporal cross-
validation. Overall, both qualitative and quantitative findings suggest that
the time-based cross-validation method should be preferred to lower the
performance overestimation and mis-selection of report-level SV assessment
models due to the effect of _concept drift_ in the model selection step.

The summary answer to RQ1: The qualitative results show that many new terms
are regularly added to NVD, after the release or discovery of the
corresponding software products or cyber-attacks. Normal random-based
evaluation methods mixing these new terms can inflate the cross-validated
model performance. Quantitatively, the optimal models found by our time-based
cross-validation are also less overfitted, especially two to five times for
Availability, Access Vector and Access Complexity. It is recommended that the
time-based cross-validation should be adopted in the model selection step for
report-level SV assessment.

####  2 RQ2: Which are the Optimal Models for Multi-Classification of Each SV
Characteristic?

The answer to RQ1 has shown that the temporal cross-validation should be used
for selecting the optimal models in the context of report-level SV assessment.
RQ2 presents the detailed results of the first phase of our model.
Specifically, we used our five-fold time-based cross-validation to select the
optimal word-only model for each of the seven VCs from six classifiers (see
section 3) and eight NLP representations (see Table 2). We followed the
guidelines of the previous work [22] to extract only the words appearing in
more than 0.1% of all descriptions as features for RQ2.

Table 3: Optimal hyperparameters found for each classifier. Classifier | Hyperparameters
---|---
NB | None
LR | Regularization value:
\+ 0.1 for term frequency
\+ 10 for tf-idf
SVM | Kernel: linear
Regularization value: 0.1
RF | Number of trees: 100
Max. depth: unlimited
Max. number of leaf nodes: unlimited
XGB | Number of trees: 100
Max. depth: unlimited
Max. number of leaf nodes: 100
LGBM | Number of trees: 100
Max. depth: unlimited
Max. number of leaf nodes: 100

Firstly, each classifier was tuned using random VCs to select its optimal set
of hyperparameters. Such selected hyperparameters are reported in Table 3. It
is worth noting that we utilized local optimization as a filter to reduce the
search space. We found that 0.1 was a consistently good value of
regularization coefficient for SVM. Unlike SVM, for LR, 0.1 was suitable for
term frequency representation; whereas, 10 performed better for the case of
tf-idf. One possible explanation is that LR provides a decision boundary that
is more sensitive to hyperparameter. Additionally, although tf-idf with
l2-normalization helps a model converge faster, it usually requires more
regularization to avoid overfitting [253]. For ensemble models, more
hyperparameters need tuning, as mentioned in section 3. Regarding the maximum
number of leaves, the optimal value for RF was _unlimited_ , which is expected
since it would give more flexibility to the model.

Table 4: Optimal models and results after the validation step. Note: The NLP configuration number is put in parentheses. SV characteristic |  Classifier (config) | _Accuracy_ |  _Macro_ _F1-Score_ |  _Weighted_ _F1-Score_
---|---|---|---|---
Confidentiality | LGBM (1) | 0.839 | 0.831 | 0.840
Integrity | XGB (4) | 0.861 | 0.853 | 0.861
Availability | LGBM (1) | 0.785 | 0.783 | 0.782
Access Vector | XGB (7) | 0.936 | 0.643 | 0.914
Access Complexity | LGBM (1) | 0.771 | 0.553 | 0.758
Authentication | LR (3) | 0.973 | 0.626 | 0.972
Severity | LGBM (5) | 0.814 | 0.763 | 0.811

However, for XGB and LGBM, the _unlimited_ value was not available. In fact,
the higher value did not improve the performance, but significantly increased
the computational time. As a result, we chose 100 to be the number of leaves
for XGB and LGBM. Similarly, we obtained 100 as a good value for the number of
trees of each ensemble model. We noticed that the maximum depth of ensemble
methods was the hyperparameter that affected the validation result the most;
the others did not change the performance dramatically. Finally, we got a
search space of size of 336 in the cross-validation step ((six classifiers)
$\times$ (eight NLP configurations) $\times$ (seven characteristics)). The
optimal validation results after using our five-fold time-based cross-
validation method in section 3 are given in Table 4.

Table 5: Average cross-validated _Weighted F-scores_ of term frequency vs. tf-idf grouped by six classifiers. | Classifier
---|---
| NB | LR | SVM | RF | XGB | LGBM
Term frequency | 0.781 | 0.833 | 0.835 | 0.843 | 0.846 | 0.846
tf-idf | 0.786 | 0.832 | 0.831 | 0.836 | 0.843 | 0.844
Table 6: Average cross-validated _Weighted F-scores_ of uni-gram vs. n-grams (2 $\leq$ n $\leq$ 4) grouped by six classifiers. Classifier | 1-gram | 2-grams | 3-grams | 4-grams
---|---|---|---|---
NB | 0.756 | 0.778 | 0.784 | 0.785
LR | 0.821 | 0.835 | 0.836 | 0.836
SVM | 0.823 | 0.835 | 0.836 | 0.837
RF | 0.838 | 0.840 | 0.838 | 0.838
XGB | 0.844 | 0.845 | 0.846 | 0.846
LGBM | 0.845 | 0.845 | 0.845 | 0.845
Figure 7: Average cross-validated _Weighted F1-Score_ s comparison between
ensemble and single models for each VC.

Besides each output, we also examined the validated results across different
types of classifiers (single vs. ensemble models) and NLP representations
(n-grams and tf-idf vs. term frequency). Since the NLP representations mostly
affect the classifiers, their validated results are grouped by six classifiers
in Tables 5 and 6. The result shows that tf-idf did not outperform term
frequency for five out of six classifiers. This result agrees with the
existing work [22, 20]. It seemed that n-grams with n $>$ 1 improved the
result. We used a one-sided non-parametric Wilcoxon signed rank test [254] to
check the significance of such improvement of n-grams (n $>$ 1). The $p$-value
was 0.169, which was larger than 0.01 (the significance level). Thus, we were
unable to accept the improvement of n-grams over uni-gram. Furthermore, there
was no performance improvement after increasing the number of n-grams. The
above-reported three observations implied that the more complex NLP
representations did not provide a statistically significant improvement over
the simplest BoW (configuration 1 in Table 2). This argument helped explain
why three out of seven optimal models in Table 4 were BoW.

Table 7: $P$-values of H0: Ensemble models $\leq$ Single models for each VC. SV characteristic |  $p$-value
---|---
Confidentiality | $3.261\times 10^{-5}$
Integrity | $9.719\times 10^{-5}$
Availability | $3.855\times 10^{-5}$
Access Vector | $2.320\times 10^{-3}$
Access Complexity | $1.430\times 10^{-5}$
Authentication | $1.670\times 10^{-3}$
Severity | $1.060\times 10^{-7}$

Along with the NLP representations, we also investigated the performance
difference between single (NB, LR, and SVM) and ensemble (RF, XGB, and LGBM)
models. The average _Weighted F1-Scores_ grouped by VCs for single and
ensemble models are illustrated in Fig. 7. The ensemble models seemed to
consistently demonstrate the superior performance compared to the single
counterparts. We also observed that the ensemble methods produced mostly
consistent results (i.e., small variances) for Access Vector and
Authentication characteristics. We performed the one-sided non-parametric
Wilcoxon signed rank tests [254] to check the significance of the better
performance of the ensemble over the single models. Table 7 reports the
$p$-values of the results from the hypothesis testing. The tests confirmed
that the superiority of the ensemble methods was significant since all
$p$-values were smaller than the significance level of 0.01. The validated
results in Table 4 also affirmed that six out of seven optimal classifiers
were ensemble (i.e., LGBM and XGB). It is noted that the XGB model usually
took more time to train than the LGBM model, especially for tf-idf
representation. Our findings suggest that LGBM, XGB and BoW should be
considered as baseline classifiers and NLP representations for report-level SV
assessment.

The summary answer to RQ2: LGBM and BoW are the most frequent optimal
classifiers and NLP representations. Overall, the more complex NLP
representations such as n-grams, tf-idf do not provide a statistically
significant performance improvement than BoW. The ensemble models perform
statistically better than single ones. It is recommended that the ensemble
classifiers (e.g., XGB and LGBM) and BoW should be used as baseline models for
report-level SV assessment.

####  3 RQ3: How Effective is Our Character-Word Model to Perform Automated
Report-Level SV Assessment with Concept Drift?

The OoV terms presented in RQ1 actually directly have an impact on the word-
only models. Such missing features can make a model unable to produce reliable
results. Especially when no existing term is found (i.e., all features are
zero), a model would have the same output regardless of the context. To answer
RQ3, we first tried to identify such all-zero cases in the SV descriptions
from 2000 to 2018. For each year from 2000 to 2018, we split the dataset into
(_i_) training set (data from the previous year backward) for building the
vocabulary, and (_ii_) testing set (data from the current year to 2018) for
checking the vocabulary existence. We found 64 cases from 2000 to 2018 in the
testing data, in which all the features were missing (see Appendix 9). We used
the terms appearing at least 0.1% in all descriptions. It should be noted that
the number of all-zero cases may be reduced using a larger vocabulary with the
trade-off for larger computational time. We also investigated the descriptions
of these vulnerabilities and found several interesting patterns. The average
length of these abnormal descriptions was only 7.98 words compared to 39.17 of
all descriptions. It turned out that the information about the threats and
sources of such SVs was limited. Most of them just included the assets and
attack/SV types. For example, the vulnerabilities with ID of CVE-2016-10001xx
had nearly the same format “Reflected XSS in WordPress plugin” with the only
differences were the name and version of the plugin. This format made it hard
for a model to evaluate the impact of each SV separately. Another issue was
due to specialized or abbreviated terms such as $/redirect?url=XSS,SEGV,CSRF$
without proper explanation. The above issues suggest that SV descriptions
should be written with sufficient information to enhance the comprehensibility
of SVs.

For RQ3, the solution to the issue of the word-only models using character-
level features is evaluated. We considered the non-stop-words with high
frequency (i.e., appearing in more than 10% of all descriptions) to generate
the character features. Using the same 0.1% value as RQ2 increased the
dimensions more than 30 times, but the performance only changed within 0.02.
According to Algorithm 1, the output minimum number of character n-grams was
chosen to be two. We first tested the robustness of the character-only models
by setting the maximum number of characters to only three. For each year y
from 1999 to 2017, we used such character model to generate the characters
from the data of the considering year y backward. We then verified the
existence of such features using the descriptions of the other part of the
data (i.e., from year _y_ \+ 1 towards 2018). Surprisingly, the model using
only two-to-three-character n-grams could produce at least one non-zero
feature for all the descriptions even using only training data in 1999 (i.e.,
the first year in our dataset based on CVE-ID). Such finding shows that our
approach is stable to SV data changes (_concept drift_) in testing data from
2000 to 2018 even with the limited amount of data and without retraining.

Figure 8: The relationship between the size of vocabulary and the maximum
number of character n-grams.

Next, to increase the generalizability of our approach, values of 3-10 were
considered for selecting the maximum number of character n-grams based on
their corresponding vocabulary sizes (see Fig. 8). Using the elbow method in
cluster analysis [255], six was selected since the vocabulary size did not
increase dramatically after this point. The selected minimum and maximum
values of character n-grams matched the minimum and average word lengths of
all NVD descriptions in our dataset, respectively.

We then used the feature aggregation algorithm (see section 4) to create the
aggregated features from the character n-grams (2 $\leq$ n $\leq$ 6) and word
n-grams to build the final model set and compared it with two baselines: Word-
only Model (WoM) and Character-only Model (CoM).

Table 8: Performance (_Accuracy_ , _Macro F1-Score_ , _Weighted F1-Score_) of our character-word vs. word-only and character-only models. SV characteristic | Our optimal model (CWM) | Word-only model (WoM) | Character-only model (CoM)
---|---|---|---
_Accuracy_ |  _Macro_ _F1-Score_ |  _Weighted_ _F1-Score_ | _Accuracy_ |  _Macro_ _F1-Score_ |  _Weighted_ _F1-Score_ | _Accuracy_ |  _Macro_ _F1-Score_ |  _Weighted_ _F1-Score_
Confidentiality | 0.727 | 0.717 | 0.728 | 0.722 | 0.708 | 0.723 | 0.694 | 0.683 | 0.698
Integrity | 0.763 | 0.749 | 0.764 | 0.763 | 0.744 | 0.764 | 0.731 | 0.718 | 0.734
Availability | 0.712 | 0.711 | 0.711 | 0.700 | 0.696 | 0.702 | 0.660 | 0.657 | 0.660
Access Vector | 0.914 | 0.540 | 0.901 | 0.904 | 0.533 | 0.894 | 0.910 | 0.538 | 0.899
Access Complexity | 0.703 | 0.468 | 0.673 | 0.718 | 0.476 | 0.691 | 0.700 | 0.457 | 0.668
Authentication | 0.875 | 0.442 | 0.844 | 0.864 | 0.425 | 0.832 | 0.866 | 0.441 | 0.840
Severity | 0.668 | 0.575 | 0.663 | 0.686 | 0.569 | 0.675 | 0.661 | 0.549 | 0.652

It should be noted that WoM is the model in which _concept drift_ is not
handled. Unfortunately, a direct comparison with the existing WoM [22] was not
possible since they used an older NVD dataset and more importantly, they did
not release their source code for reproduction. However, we tried to set up
the experiments based on the guidelines and results presented in the previous
paper [22].

To be more specific, we used BoW predictors and random forest (the best of
their three models used) with the following hyperparameters: the number of
trees was 100 and the number of features for splitting was 40. For CoM, we
used the same optimal classifier of each VC. The comparison results are given
in Table 8. CWM performed slightly better than the WoM for four out of seven
VCs regarding all evaluation metrics. Also, 4.98% features of CWM were non-
zero, which was nearly five-time denser than 1.03% of WoM. Also, CoM was the
worst model among the three, which had been expected since it contained the
least information (smallest number of features). Although CWM did not
significantly outperform WoM, its main advantage is to effectively handle the
OoV terms (_concept drift_), except new terms without any matching parts. We
hope that our solution to _concept drift_ will be integrated into
practitioner’s existing framework/workflow and future research work to perform
more robust report-level SV assessment.

The summary answer to RQ3: The WoM does not handle the new cases well,
especially those with all zero-value features. Without retraining, the tri-
gram character features can still handle the OoV words effectively with no
all-zero features for all testing data from 2000 to 2018. Our CWM performs
comparably well with the existing WoM and provides nearly five-time richer SV
information. Hence, our CWM is better for automated report-level SV assessment
with _concept drift_.

####  4 RQ4: To What Extent Can Low-Dimensional Model Retain the Original
Performance?

The n-gram NLP models usually have an issue with the high-dimensional and
sparse feature vectors [240]. The large feature sizes of our CWMs in Table 8
were 1,649 for Confidentiality, Availability and Access Complexity; 4,154 for
Integrity and Access Vector; 3,062 for Authentication; and 5,104 for Severity.
To address such challenge in RQ4, we investigated a dimensionality reduction
method (i.e., Latent Semantic Analysis (LSA) [245]) and recent sub-word
embeddings (e.g., fastText [196, 246]) for SV assessment. fastText is an
extension of Word2Vec [202] word embeddings, in which the character-level
features are also considered. fastText is different to traditional n-grams in
the sense that it determines the meaning of a word/subword based on the
surrounding context. Here, we computed the sentence representation as an
average fastText embedding of its constituent words and characters. We
implemented fastText using the _Gensim_ [256] library in Python.

Table 9: _Weighted F1-Scores_ of our original CWM (green-colored baseline), 300-dimension Latent Semantic Analysis (LSA-300), fastText trained on SV descriptions (fastText-300) and fastText trained on English Wikipedia pages (fastText-300W). SV characteristic |  Our CWM |  LSA- 300 |  fastText- 300 |  fastText- 300W
---|---|---|---|---
Confidentiality | 0.728 | 0.656 | 0.679 | 0.648
Integrity | 0.764 | 0.695 | 0.719 | 0.672
Availability | 0.711 | 0.656 | 0.687 | 0.669
Access Vector | 0.901 | 0.892 | 0.893 | 0.866
Access Complexity | 0.673 | 0.611 | 0.679 | 0.678
Authentication | 0.844 | 0.842 | 0.815 | 0.765
Severity | 0.663 | 0.656 | 0.654 | 0.635

For LSA, using the elbow method and total explained variances of the principal
components, we selected 300 for the dimensions and called it LSA-300. Table 9
shows that LSA-300 retained from 90% to 99% performance of the original model,
but used only 300 dimensions (6-18% of original model sizes). More remarkably,
with the same 300 dimensions, the fastText model trained on SV descriptions
was on average better than LSA-300 (97% vs. 94.5%). fastText model even
slightly outperformed our original CWM for Access Complexity. Moreover, for
all seven cases, the fastText model using SV knowledge (fastText-300) had
higher _Weighted F1-Scores_ than that trained on English Wikipedia pages
(fastText-300W) [257]. The result implied that SV descriptions contain
specific terms that do not frequently appear in general domains. The domain
relevance turns out to be not only applicable to word embeddings [21], but
also to character/sub-word embeddings for SV analysis and assessment. Overall,
our findings show that LSA and fastText are capable of building efficient
report-level SV assessment models without too much performance trade-off.

The summary answer to RQ4: The LSA model with 300 dimensions (6-18% of the
original size) retains from 90% up to 99% performance of the original model.
With the same feature dimensions, the model with fastText sub-word embeddings
provide even more promising results. The fastText model with the SV knowledge
outperforms that trained on a general context (e.g., Wikipedia). LSA and
fastText can help build efficient models for report-level SV assessment.

###  6 Threats to Validity

Internal validity. We used well-known tools such as the _scikit-learn_ [241]
and _nltk_ [242] libraries for ML and NLP. Our optimal models may not
guarantee the highest performance for every SV characteristic since there are
infinite values of hyperparameters to tune. However, even when the optimal
values change, a time-based cross-validation method should still be preferred
since we considered the general trend of all SVs. Our models may not provide
the state-of-the-art results, but at least they give the baseline performance
for handling the _concept drift_ of SVs.

External validity. Our work used NVD – one of the most comprehensive public
repositories of SVs. The size of our dataset is more than 100,000 with the
latest SVs in 2018. Our character-word model was demonstrated to consistently
handle the OoV words well even with very limited data for all years in the
dataset. It is recognized that the model may not work for extreme rare terms
in which no existing parts can be found. However, our model is totally re-
trainable to deal with such cases or incorporate more sources of SVs’
descriptions.

Conclusion validity. We mitigated the randomness of the results by taking the
average value of five-fold cross-validation. The performance comparison of
different types of classifiers and NLP representations was also confirmed
using statistical hypothesis tests with $p$-values that were much lower than
the significance level of 1%.

###  7 Related Work

####  1 Report-Level SV Assessment

It is important to patch critical-first SVs [258]. Besides CVSS, there have
been many other assessment schemes for SVs [259, 136, 260]. Recently, there
has been a detailed Bayesian analysis of various SV scoring systems [261],
which highlights the good overall performance of CVSS. Therefore, we used the
well-known CVSS as the ground truth for our approach. We assert that our
approach can be generalizable to other SV assessment systems following the
same scheme of multi-class classification.

As mentioned in Chapter 1, Bozorgi et al. [32] pioneered the use of ML models
for report-level SV assessment. Their paper used an SVM model and various
features (e.g., NVD description, CVSS, published and modified dates) to
estimate the likelihood of exploitation and _time-to-exploit_ of SVs. Another
piece of work analyzed the VCs and trends of SVs by incorporating different SV
information from multiple repositories [152, 49], security advisories [47,
262], darkweb/deepnet [49, 77] and social network (Twitter) [33]. These
efforts assumed that all VCs have been available at the time of analysis.
However, our work relaxes this assumption by using only SV descriptions – one
of the first pieces of information appearing in new SV reports. As a result,
our model can be used for both new and old SVs.

Many studies have built upon the work of Bozorgi et al. [32] and used NVD
descriptions for report-level SV assessment, as reviewed in Chapter 1. Here,
we focus on several studies directly related to our current study. Yamamoto et
al. [95] used Linear Discriminant Analysis, Naïve Bayes and Latent Semantic
Indexing combined with an annual effect estimation to determine the CVSS-based
VCs of more than 60,000 SVs in NVD. The annual effect focused on recent SVs,
but still could not explicitly handle OoV terms in SV descriptions. Spanos et
al. [22] worked on the same task as ours using a multi-target framework with
Decision Tree, Random Forest and Gradient Boosting Tree. Note that our
approach also contains the word-only model, but we select the optimal models
using our time-based cross-validation to better address the _concept drift_
issue. SV descriptions were also used to evaluate SV severity [20], associate
the frequent terms with each VC [97], determine the type of each SV using
topic modeling [156] and show SV trends [152]. Recently, Han et al. [21] have
applied deep learning to predict SV severity. The existing literature has
demonstrated the usefulness of description for SV analysis and assessment, but
has not mentioned how to overcome its _concept drift_ challenge. Our work is
the first of its kind to provide a robust treatment for SVs’ _concept drift_.

####  2 Temporal Modeling of SVs

Regarding the temporal relationship of SVs, Roumani et al. [263] proposed a
time-series approach using autoregressive integrated moving average and
exponential smoothing methods to predict the number of SVs in the future.
Another time-series work [264] was presented to model the trend in disclosing
SVs. A group of researchers published a series of studies [265, 266, 267] on
stochastic models such as Hidden Markov Models, Artificial Neural Network, and
Support Vector Machine to estimate the occurrence and exploitability of SVs.
The focus of the above studies was on the determination of the occurrence of
SVs over time. In contrast, our work aims to handle the temporal relationship
to build more robust predictive (multi-class classification) models for
report-level SV assessment.

###  8 Chapter Summary

We observe that the existing studies suffer from _concept drift_ in SV
descriptions that affect both the traditional model selection and prediction
steps of report-level SV assessment. We assert that _concept drift_ can
degrade the robustness of these existing predictive models. We showed that
time-based cross-validation should be used for SV analysis to better capture
the temporal relationship of SVs. Then, our main contribution is the
Character-Word Models (CWMs) to improve the robustness of automated report-
level SV assessment with _concept drift_. CWMs were demonstrated to handle
_concept drift_ of SVs effectively for all the testing data from 2000 to 2018
in NVD even in the case of data scarcity. Our approach also performed
comparably well with the existing word-only models. Our CWMs were also much
less sparse and thus less prone to overfitting. We also found that Latent
Semantic Analysis and sub-word embeddings like fastText help build compact and
efficient CWM models (up to 94% reduction in dimension) with the ability to
retain at least 90% of the predictive performance for all VCs. Besides the
strong performance, we also provide implications on the use of different
features and classifiers for building effective report-level SV assessment
models.

###  9 Appendix - SVs with All Out-of-Vocabulary Words

64 vulnerabilities along with their CVD-IDs that had all-zero features of
word-only model from 2000 to 2018, as mentioned in section 3: CVE-2013-6647,
CVE-2015-1000004, CVE-2016-1000113, CVE-2016-1000114, CVE-2016-1000117,
CVE-2016-1000118, CVE-2016-1000126, CVE-2016-1000127, CVE-2016-1000128,
CVE-2016-1000129, CVE-2016-1000130, CVE-2016-1000131, CVE-2016-1000132,
CVE-2016-1000133, CVE-2016-1000134, CVE-2016-1000135, CVE-2016-1000136,
CVE-2016-1000137, CVE-2016-1000138, CVE-2016-1000139, CVE-2016-1000140,
CVE-2016-1000141, CVE-2016-1000142, CVE-2016-1000143, CVE-2016-1000144,
CVE-2016-1000145, CVE-2016-1000146, CVE-2016-1000147, CVE-2016-1000148,
CVE-2016-1000149, CVE-2016-1000150, CVE-2016-1000151, CVE-2016-1000152,
CVE-2016-1000153, CVE-2016-1000154, CVE-2016-1000155, CVE-2016-1000217,
CVE-2017-10798, CVE-2017-10801, CVE-2017-14036, CVE-2017-14536,
CVE-2017-15808, CVE-2017-16760, CVE-2017-16785, CVE-2017-17499,
CVE-2017-17703, CVE-2017-17774, CVE-2017-6102, CVE-2017-7276, CVE-2017-8783,
CVE-2018-10030, CVE-2018-10031, CVE-2018-10382, CVE-2018-11120,
CVE-2018-11405, CVE-2018-12501, CVE-2018-13997, CVE-2018-14382, CVE-2018-5285,
CVE-2018-5361, CVE-2018-6467, CVE-2018-6834, CVE-2018-8817, CVE-2018-9130

##  Chapter 3 Automated Function-Level Software Vulnerability Assessment

Related publication: This chapter is based on our paper titled “On the Use of
Fine-grained Vulnerable Code Statements for Software Vulnerability Assessment
Models” published in the 19th International Conference on Mining Software
Repositories (MSR), 2022 (CORE A) [268].

The proposed approach in Chapter 2 has improved the robustness of report-level
Software Vulnerability (SV) assessment models against changing data of SVs in
the wild. Nevertheless, these report-level models still rely on SV
descriptions that mostly require significant expertise and manual effort to
create, which may cause delays for SV fixing. On the other hand, respective
vulnerable code is always available before SVs are fixed. Many studies have
developed Machine Learning (ML) approaches to detect SVs in functions and
fine-grained code statements that cause such SVs. However, as shown in Chapter
1, there is little work on leveraging such detection outputs for data-driven
SV assessment to give information about exploitability, impact, and severity
of SVs. The information is important to understand SVs and prioritize their
fixing. Using large-scale data from 1,782 functions of 429 SVs in 200 real-
world projects, in Chapter 3, we investigate ML models for automating
function-level SV assessment tasks, i.e., predicting seven Common
Vulnerability Scoring System (CVSS) metrics. We particularly study the value
and use of vulnerable statements as inputs for developing the assessment
models because SVs in functions are originated in these statements. We show
that vulnerable statements are 5.8 times smaller in size, yet exhibit
7.5-114.5% stronger assessment performance (Matthews Correlation Coefficient
(MCC)) than non-vulnerable statements. Incorporating context of vulnerable
statements further increases the performance by up to 8.9% (0.64 MCC and 0.75
F1-Score). Overall, we provide the initial yet promising ML-based baselines
for function-level SV assessment, paving the way for further research in this
direction.

###  1 Introduction

As shown in Chapter 1, previous studies (e.g., [95, 21, 22, 23, 11]) have
mostly used SV reports to develop data-driven models for assigning the Common
Vulnerability Scoring System (CVSS) [29] metrics to Software Vulnerabilities
(SVs). Among sources of SV reports, National Vulnerability Database (NVD) [16]
has been most commonly used for building SV assessment models [11]. The
popularity of NVD is mainly because it has SV-specific information (e.g., CVSS
metrics) and less noise in SV descriptions than other Issue Tracking Systems
(ITSs) like Bugzilla [269]. The discrepancy is because NVD reports are vetted
by security experts, while ITS reports may be contributed by users/developers
with limited security knowledge [270]. However, NVD reports are mostly
released long after SVs have been fixed. Our analysis revealed that less than
3% of the SV reports with the CVSS metrics on NVD had been published before
SVs were fixed; on average, these reports appeared 146 days later than the
fixes. Note that our findings accord with the previous studies [215, 216].
This delay renders the CVSS metrics required for SV assessment unavailable at
fixing time, limiting the adoption of report-level SV assessment for
understanding SVs and prioritizing their fixes.

Instead of using SV reports, an alternative and more straight-forward way is
to directly take (vulnerable) code as input to enable SV assessment prior to
fixing. Once a code function is confirmed vulnerable, SV assessment models can
assign it the CVSS metrics before the vulnerable code gets fixed, even when
its report is not (yet) available. Note that it is non-trivial to use static
application security testing tools to automatically create bug/SV reports from
vulnerable functions for current SV assessment techniques as these tools often
have too many false positives [271, 272]. To develop function-level assessment
models, it is important to obtain input information about SVs in functions
detected by manual debugging or automatic means like data-driven approaches
(e.g., [273, 274, 275]). Notably, recent studies (e.g., [276, 277]) have shown
that an SV in a function usually stems from a very small number of code
statements/lines, namely vulnerable statements. Intuitively, these vulnerable
statements potentially provide highly relevant information (e.g., causes) for
SV assessment models. Nevertheless, a large number of other (non-vulnerable)
lines in functions, though do not directly contribute to SVs, can still be
useful for SV assessment, e.g., indicating the impacts of an SV on nearby
code. It still remains largely unknown about function-level SV assessment
models as well as the extent to which vulnerable and non-vulnerable statements
are useful as inputs for these models.

We conduct a large-scale study to fill this research gap. We investigate the
usefulness of integrating fine-grained vulnerable statements and different
types of code context (relevant/surrounding code) into learning-based SV
assessment models. The assessment models employ various feature extraction
methods and Machine Learning (ML) classifiers to predict the seven CVSS
metrics (Access Vector, Access Complexity, Authentication, Confidentiality,
Integrity, Availability, and Severity) for SVs in code functions.

Using 1,782 functions from 429 SVs of 200 real-world projects, we evaluate the
use of vulnerable statements and other lines in functions for developing SV
assessment models. Despite being up to 5.8 times smaller in size (lines of
code), vulnerable statements are more effective for function-level SV
assessment, i.e., 7.4-114.5% higher Matthews Correlation Coefficient (MCC) and
5.5-43.6% stronger F1-Score, than non-vulnerable lines. Moreover, vulnerable
statements with context perform better than vulnerable lines alone.
Particularly, using vulnerable and all the other lines in each function
achieves the best performance of 0.64 MCC (8.9% better) and 0.75 F1-Score
(8.5% better) compared to using only vulnerable statements. We obtain such
improvements when combining vulnerable statements and context as a single
input based on their code order, as well as when treating them as two separate
inputs. Having two inputs explicitly provides models with the location of
vulnerable statements and context for the assessment tasks, while single input
does not. Surprisingly, we do not obtain any significant improvement of the
double-input models over the single-input counterparts. These results show
that function-level SV assessment models can still be effective even without
knowing exactly which statements are vulnerable. Overall, our findings can
inform the practice of building function-level SV assessment models.

Our key contributions are summarized as follows:

  1. 1.

To the best of our knowledge, we are the first to leverage data-driven models
for automating function-level SV assessment tasks that enable SV
prioritization/planning prior to fixing.

  2. 2.

We study the value of using fine-grained vulnerable statements in functions
for building SV assessment models.

  3. 3.

We empirically show the necessity and potential techniques of incorporating
context of vulnerable statements to improve the assessment performance.

  4. 4.

We release our datasets and models for future research at
https://github.com/lhmtriet/Function-level-Vulnerability-Assessment.

Chapter organization. Section 2 gives a background on function-level SV
assessment. Section 3 introduces and motivates the three RQs. Section 4
describes the methods used for answering these RQs. Section 5 presents our
empirical results. Section 6 discusses the findings and threats to validity.
Section 7 mentions the related work. Section 8 concludes the study and
suggests future directions.

###  2 Background and Motivation

⬇

1protected␣String␣getExecutionPreamble()

2{

3␣␣␣␣if␣(getWorkingDirectoryAsString()␣==␣null)

4␣␣␣␣{return␣null;}

5␣␣␣␣String dir = getWorkingDirectoryAsString();

6␣␣␣␣StringBuilder sb = new StringBuilder();

7␣␣␣␣sb.append("cd");

8-␣␣␣sb.append(unifyQuotes(dir));

9+␣␣␣sb.append(quoteOneItem(dir,␣false));

10␣␣␣␣sb.append("&&");

11␣␣␣␣return sb.toString();

12}

Figure 1: A vulnerable function extracted from the fixing commit b38a1b3 of an
SV (CVE-2017-1000487) in the Plexus-utils project. Notes: Line 8 is
vulnerable. Deleted and added lines are highlighted in red and green,
respectively. Blue-colored code lines affect or are affected by line 8
directly.

There have been a growing number of studies to detect vulnerable statements in
code functions (e.g., [278, 276, 277]). Fine-grained detection assumes that
not all statements in a function are vulnerable. We confirmed this assumption;
i.e., only 14.7% of the lines in our curated functions were vulnerable (see
section 1). However, it is non-trivial to manually annotate a sufficiently
large dataset of vulnerable functions and statements for training SV
prediction models. Instead, many studies (e.g., [276, 279, 280]) have
automatically obtained vulnerable statements from modified lines in
Vulnerability Fixing Commits (VFCs) as these lines are presumably removed to
fix SVs. The functions containing such identified statements are considered
vulnerable. Note that VFCs are used as they can be relatively easy to retrieve
from various sources like National Vulnerability Database (NVD) [16]. An
exemplary function and its vulnerable statement are in Fig. 1. Line 8
“sb.append(unifyQuotes(dir));” is the vulnerable statement; this line was
replaced with a non-vulnerable counterpart “sb.append(quoteOneItem(dir,
false));” in the VFC. The replacement was made to properly sanitize the input
(dir), preventing OS command injection.

Despite active research in SV detection, there is little work on utilizing the
output of such detection for SV assessment. Previous studies (e.g., [95, 20,
22, 23, 11]) have mostly leveraged SV reports, mainly on NVD, to develop SV
assessment models that alleviate the need for manually defining complex rules
for assessing ever-increasing SVs. However, these SV reports usually appear
long after SV fixing time. For example, the SV fix in Fig. 1 was done 1,533
days before the date it was reported on NVD. In fact, such a delay, i.e.,
disclosing SVs after they are fixed, is a recommended practice so that
attackers cannot exploit unpatched SVs to compromise systems [281]. One may
argue that internal bug/SV reports in Issue Tracking Systems (ITS) such as
JIRA [282] or Bugzilla [269] can be released before SV fixing and have
severity levels. However, ITS severity levels are often for all bug types, not
only SVs. These ITSs also do not readily provide exploitability and impact
metrics like CVSS [29] for SVs, limiting assessment information required for
fixing prioritization. Moreover, SVs are mostly rooted in source code; thus,
it is natural to perform code-based SV assessment. We propose predicting seven
base CVSS metrics (i.e., Access Vector, Access Complexity, Authentication,
Confidentiality, Integrity, Availability, and Severity)111These metrics are
from CVSS version 2 and were selected based on the same reasons presented in
the study in Chapter 2. More details can be found in section 2. after SVs are
detected in code functions to enable thorough and prior-fixing SV assessment.
We do not perform SV assessment for individual lines as for a given function,
like Li et al. [283], we observed that there can be more than one vulnerable
line and nearly all these lines are strongly related and contribute to the
same SV (having the same CVSS metrics).

Vulnerable statements represent the core parts of SVs, but we posit that other
(non-vulnerable) parts of a function may also be usable for SV assessment.
Specifically, non-vulnerable statements in a vulnerable function are either
directly or indirectly related to the current SV. We use program slicing [284]
to define directly SV-related statements as the lines affect or are affected
by the variables in vulnerable statements. For example, the blue lines in Fig.
1 are directly related to the SV as they define, change, or use the sb and dir
variables in vulnerable line 8. These SV-related statements can reveal the
context/usage of affected variables for analyzing SV exploitability, impact,
and severity. For instance, lines 5-6 denote that dir is a directory and sb is
a string (StringBuilder object), respectively; line 7 then indicates that a
directory change is performed, i.e., the cd command. This sequence of
statements suggests that sb contains a command changing directory. Line 11
returns the vulnerable command, probably affecting other components. Besides,
indirectly SV-related statements, e.g., the black lines in Fig. 1, are
remaining lines in a function excluding vulnerable and directly SV-related
statements. These indirectly SV-related lines may still provide information
about SVs. For example, lines 3-4 in Fig. 1 imply that there is only a null
checking for directory without imposing any privilege requirement to perform
the command, potentially reducing the complexity of exploiting the SV. It
remains unclear to what extent different types of statements are useful for SV
assessment tasks. Therefore, this study aims to unveil the contributions of
these statement types to function-level SV assessment models.

Figure 2: Methodology used to answer the research questions. Note: The
vulnerable function is the one described in Fig. 1.

###  3 Research Questions

To demystify the predictive performance of SV assessment models using
vulnerable and other statements in code functions, we set out to investigate
the following three Research Questions (RQs).

RQ1: Are vulnerable code statements more useful than non-vulnerable
counterparts for SV assessment models? Since vulnerable and non-vulnerable
statements are both potentially useful for SV assessment (see section 2), RQ1
compares them for building function-level SV assessment models. RQ1 tests the
hypothesis that vulnerable statements directly causing SVs would provide an
advantage in SV assessment performance. The findings of RQ1 would also inform
the practice of leveraging recent advances in fine-grained SV detection for
function-level SV assessment.

RQ2: To what extent do different types of context of vulnerable statements
contribute to SV assessment performance? RQ2 studies the impact of using
directly and indirectly SV-related statements as context for vulnerable
statements, as discussed in section 2, on the performance of SV assessment in
functions. We compare the performance of models using different types of
context lines (see section 2) that have been commonly used in the literature.
RQ2 findings would unveil what types of context (if any) would be beneficial
to use alongside vulnerable statements for developing function-level SV
assessment models.

RQ3: Does separating vulnerable statements and context to provide explicit
location of SVs improve assessment performance? For SV assessment, RQ2
combines vulnerable statements and their context as a single input following
their order in functions, while RQ3 treats these two types of statements as
two separate inputs. Separate inputs explicitly specify which statements are
vulnerable in each function for assessment models. RQ3 results would give
insights into the usefulness of the exact location of vulnerable statements
for function-level SV assessment models.

###  4 Research Methodology

This section presents the experimental setup we used to perform a large-scale
study on function-level SV assessment to support prioritization of SVs before
fixing. We used a computing cluster with 16 CPU cores and 16GB of RAM to
conduct all the experiments.

Workflow overview. Fig. 2 presents the workflow we followed to develop
function-level SV assessment models based on various types of code inputs. The
workflow has three main steps: (i) Collection of vulnerable and non-vulnerable
statements from Vulnerability-Fixing Commits (VFCs) (section 1), (ii) Context
extraction of vulnerable statements (section 2), and (iii) Model building for
SV assessment (sections 3, 4, and 5). We start with VFCs containing code
changes used to fix SVs. As discussed in section 2, we consider the deleted
(–) lines in each function of VFCs as vulnerable statements, while the
remaining lines are non-vulnerable statements. Details of the extracted VFCs
and statements are given in section 1. Both vulnerable and non-vulnerable
statements are used by the Context Extraction module (see section 2) to obtain
the three types of context with respect to vulnerable statements that
potentially provide additional information for SV assessment. The extracted
statements along with their context enter the Model Building module. The first
step in this module is to extract fixed-length feature vectors from code
inputs/statements (see section 3). Subsequently, such feature vectors are used
to train different data-driven models (see section 4) to support automated SV
assessment, i.e., predicting the seven CVSS metrics: Access Vector, Access
Complexity, Authentication, Confidentiality, Integrity, Availability, and
Severity. The model training and evaluation are repeated 10 times to increase
the stability of results (see section 5).

RQ-wise method. The methods to collect data, extract features as well as
develop and evaluate models in Fig. 2 were utilized for answering all the
Research Questions (RQs) in section 3. RQ1 developed and compared two types of
SV assessment models, namely models using only vulnerable statements and those
using only non-vulnerable statements. In RQ2, for each of the program slicing,
surrounding, and function context types, we created a single feature vector by
combining the current context and corresponding vulnerable statements, based
on their appearance order in the original functions, for model building and
performance comparison. In RQ3, for each context type in RQ2, we extracted two
separate feature vectors, one from vulnerable statements and another one from
the context, and then fed these vectors into SV assessment models. We compared
the two-input approach in RQ3 with the single-input counterpart in RQ2.

####  1 Data Collection

To develop SV assessment models, we need a large dataset of vulnerable
functions and statements curated from VFCs, as discussed in section 2. This
section describes the collection of such dataset.

VFC identification. We first scraped VFCs from three popular sources in the
literature: NVD [16], GitHub Advisory
Database,222https://github.com/advisories and VulasDB [285], a manually
curated VFC dataset. The VFCs had dates ranging from July 2000 to September
2021. We only selected VFCs that had the CVSS version 2 metrics as we needed
these metrics for SV assessment. Following the recommendation of [286], we
removed any VFCs that had more than 100 files and 10,000 lines of code as
these VFCs are likely tangled commits, i.e., not only fixing SVs. We also
discarded VFCs that were not written in the Java programming language as Java
has been commonly used in both practice333https://bit.ly/stack-overflow-
survey-2021 and the literature (e.g., [287, 288, 286, 289]). After the
filtering process, we obtained 900 VFCs to extract vulnerable
functions/statements for building SV assessment models.

Extraction of vulnerable functions and statements. For each VFC, we obtained
all the affected files (i.e., containing changed lines), excluding test files
because we focused on production code. We followed a common practice [276,
279, 280] to consider all the functions in each affected file as vulnerable
functions and the deleted lines in these functions as vulnerable statements.
We removed functions having only added changes and non-functional/cosmetic
changes such as removing/changing inline/multi-line comments, spaces, or empty
lines. For the former, added lines only exist in fixed code, making it hard to
pinpoint the exact vulnerable statements or root causes leading to such code
additions [290]. For the latter, cosmetic changes likely do not contribute to
SV fixes [286]. We also did not use a function if its entire body was deleted
because such a case did not have any non-vulnerable statements for building SV
assessment models in our RQs (see section 3). After the filtering steps, we
retrieved 1,782 vulnerable functions and 5,179 vulnerable statements of 429
SVs in 200 Java projects. We also obtained the seven CVSS metrics from NVD for
each vulnerable function (see Fig. 3).

Figure 3: Class distributions of the seven CVSS metrics.

Manual validation of vulnerable functions.

We randomly selected 317 functions, i.e., with 95% confidence level and 5%
error [291], from our dataset. The author of this thesis and a PhD student
with three-year experience in Software Engineering and Cybersecurity
independently validated the functions. The manual validation was considerably
labor-intensive, taking 120 man-hours. We achieved a substantial agreement
with a Cohen’s kappa score [292] of 0.72. Disagreements were resolved through
discussion. We found that 9% of the selected functions were not vulnerable,
mainly due to tangled fixes/VFCs. The functions in these VFCs fixed a non-SV
related issue, e.g., the nameContainsForbiddenSequence function in the commit
cefbb94 of the Eclipse Mojarra project. The modifier of this function in the
ResourceManager.java class was changed from private to package. This change
allowed the reuse of the function in other classes like
ClasspathResourceHelper.java for sanitizing inputs to prevent a path traversal
SV (CVE-2020-6950). We assert that it is challenging to detect all of these
cases without manual validation. However, such validation is extremely
expensive to scale up to thousands of functions like the dataset we curated in
this study.

####  2 Vulnerable Code Context Extraction

This section describes the Context Extraction module that takes vulnerable and
non-vulnerable statements as inputs and then outputs program slicing,
surrounding, or function context. These context types have been previously
used for bug/SV-related tasks [283, 293, 275]. However, there is little known
about their use and value for function-level SV assessment tasks, which are
studied in this work.

Program slicing context. Program slicing captures relevant statements to a
point in a program (line of code) to support software debugging [284]. This
concept has been utilized for SV identification [283, 294]. However, using
this context for SV assessment is fundamentally different. For SV detection,
the location of vulnerable statements is unknown, so program slicing context
is usually extracted for all statements including non-vulnerable ones in a
function of pre-defined types (e.g., array manipulations, arithmetic
operations, and function calls) [283]. In contrast, for SV assessment,
vulnerable statements are known; thus, program slicing context is only
obtained for these statements. With a focus on function-level SV assessment,
we considered intra-procedural program slicing, i.e., finding relevant lines
within the boundary of a function of interest.

Following the common practice in the literature [295, 283], we used Program
Dependence Graph (PDG) [296] extracted from source code to obtain program
slices for vulnerable statements in each function. A PDG contains nodes that
represent code statements and directed edges that capture data or control
dependencies among nodes. A data dependency exists between two statements when
one statement affects/changes the value of a variable used in another
statement. For example, “int b = a + 1;” is data-dependent on “int a = 1;” as
the variable a defined in the second statement is used in the first statement.
A control dependency occurs when a statement determines whether/how often
another statement is executed. For instance, in “if (b == 2) func(c);”,
“func(c)” only runs if “b == 2”, and thus is control-dependent on the former.

Based on data and control dependencies, backward and forward slices are
extracted. Backward slices directly change or control the execution of
statements affecting the values of variables in vulnerable statements;
whereas, forward slices are data/control-dependent on vulnerable statements
[297]. In a PDG, backward slices are nodes that can go to vulnerable nodes
through one or more directed edges. In Fig. 1, the dir variable is defined in
line 5 and then used in vulnerable line 8, so line 5 is a backward slice.
Forward slices are the nodes that can be reached from vulnerable nodes by
following one or more directed edges in a PDG. In Fig. 1, line 11 is data-
dependent on vulnerable line 8 as it uses the value of sb; thus, line 11 is a
forward slice. The program slicing context of vulnerable statements in a
function is a combination of all backward and forward slices.

Surrounding context. Another way to define context is to take a fixed number
of lines ($n$) before and after a vulnerable statement, which is referred to
as surrounding context. These surrounding lines may contain relevant
information, e.g., values/usage of variables in vulnerable statements. This
context is also based on an observation that developers usually first look at
nearby code of vulnerable statements to understand how to fix SVs [293]. We
discarded surrounding lines that were just code comments or blank lines as
these probably do not contribute to the functionality of a function [286]. We
also limited surrounding lines to be within-function.

Function context. Contrary to program slicing and surrounding context that may
not use all lines in a function, function context uses all function
statements, excluding vulnerable ones. This scope has been commonly used for
SV detection models [273, 275] because vulnerable statements are unavailable
at detection time. This scope contains all the lines of program
slicing/surrounding context and other presumably indirectly related lines to
vulnerable statements. Accordingly, the performance of using indirectly SV-
related lines together with directly SV-relevant lines for SV assessment can
be examined. Note that for a given function, combining function context with
vulnerable statements as a single code block (RQ2 in section 3) is equivalent
to using the whole function, which would result in the same input to SV
assessment models regardless of which statements are vulnerable. This input
combination allows us to evaluate the usefulness of the exact location of
vulnerable statements for function-level SV assessment models.

####  3 Code Feature Generation

Raw code from vulnerable statements and their context are converted into
fixed-length feature vectors to be consumable by learning-based SV assessment
models. This step describes five techniques we used to extract features from
code inputs.

Bag-of-Tokens. Bag-of-Tokens is based on Bag-of-Words, a popular feature
extraction technique in Natural Language Processing (NLP). This technique has
been commonly investigated for developing SV assessment models based on
textual SV descriptions/reports [96, 102, 129]. We extended this technique to
code-based SV assessment by counting the frequency of code tokens. We also
applied code-aware tokenization to preserve code syntax and semantics. For
instance, var++ was tokenized into var and ++, explicitly informing a model
about incrementing the variable var by one using the operator (++).

Bag-of-Subtokens. Bag-of-Subtokens extends Bag-of-Tokens by splitting
extracted code tokens into sequences of characters (sub-tokens). These
characters help a model learn less frequent tokens better. For instance, an
infrequent variable like ThisIsAVeryLongVar is decomposed into multiple sub-
tokens; one of which is Var, telling a model that this is a potential
variable. We extracted sub-tokens of lengths ranging from two to six. Such
values have been previously adopted for SV assessment [133, 23]. We did not
use one-letter characters as they were too noisy, while using more than six
characters would significantly increase feature size and computational cost.

Word2vec. Unlike Bag-of-Tokens and Bag-of-Subtokens that do not consider token
context, Word2vec [202] extracts features of a token based on its surrounding
counterparts. The contextual information from surrounding tokens helps produce
similar feature vectors in an embedding space for tokens with (nearly)
identical functionality/usage (e.g., average and mean variables). Word2vec
generates vectors for individual tokens, so we averaged the vectors of all
input tokens to represent a code snippet. This averaging method has been
demonstrated to be effective for various NLP tasks [298]. Table 1 lists
different values for the window and vector sizes of Word2vec used for tuning
the performance of learning-based SV assessment models.

fastText. fastText [196] enhances Word2vec by representing each token with an
aggregated feature vector of its constituent sub-tokens. Technically, fastText
combines the strengths of semantic representation of Word2vec and subtoken-
augmented features of Bag-of-Subtokens. fastText has been shown to build
competitive yet compact report-level SV assessment models [23]. Like Word2vec,
the feature vector of a code snippet was averaged from the vectors of all the
input tokens. The length of sub-tokens also ranged from two to six, resembling
that of Bag-of-Subtokens. Other hyperparameters of fastText for optimization
are listed in Table 1.

CodeBERT. CodeBERT [299] is an adaptation of BERT [80], the current state-of-
the-art feature representation technique in NLP, to source code modeling.
CodeBERT is a pre-trained model using both natural language and programming
language data to produce contextual embedding for code tokens. The same code
token can have different CodeBERT embedding vectors depending on other tokens
in an input; whereas, word2vec/fastText produces a single vector for every
token regardless of its context. In addition, the source code tokenizer of
CodeBERT is built upon Byte-Pair Encoding (BPE) [300]. This tokenizer smartly
retains sub-tokens that frequently appear in a training corpus rather than
keeping all of them as in Bag-of-Subtokens and fastText, balancing between
performance and cost. CodeBERT also preserves a special token, [CLS], to
represent an entire code input. We leveraged the vector of this [CLS] token to
extract the features for each code snippet.

We trained all the feature models from scratch, except CodeBERT as it is a
pre-trained model. We used CodeBERT’s pre-trained vocabulary and embeddings as
commonly done in the literature [301]. To build the vocabulary for the other
feature extraction methods, we considered tokens appearing at least in two
samples in a training dataset to avoid vocabulary explosion due to too rare
tokens. The exact vocabulary depended on the dataset used in each of the 10
training/evaluation rounds, as described in section 5. Note that some code
snippets, e.g., vulnerable lines extracted from (partial) code changes, were
not compilable (i.e., did not contain complete code syntax); thus, we did not
use Abstract Syntax Tree (AST) based code representation like Code2vec [288]
in this study as such representation may not be robust for these cases [287,
302]. It is worth noting that Bag-of-Tokens, Bag-of-Subtokens, Word2vec,
fastText, and CodeBERT can still work with these cases as these methods
operate directly on code tokens.

####  4 Data-Driven SV Assessment Models

Table 1: Hyperparameter tuning for SV assessment models. Step | Model | Hyperparameters
---|---|---
Feature extraction |  Word2vec [298] |  Vector size: 150, 300, 500
fastText [196] |  Window size: 3, 4, 5
CVSS metrics prediction |  Logistic Regression (LR) [249] |  Regularization coefficient: 0.01, 0.1, 1, 10, 100
Support Vector Machine (SVM) [206]
K-Nearest Neighbors (KNN) [303] |  No. of neighbors: 5, 11, 31, 51
Weight: uniform, distance
Distance norm: 1, 2
Random Forest (RF) [251] |  No. of estimators: 100, 200, 300, 400, 500 Max depth: 3, 5, 7, 9, unlimited Max. no. of leaf nodes: 100, 200, 300, unlimited (RF)
Extreme Gradient Boosting (XGB) [78]
Light Gradient Boosting Machine (LGBM) [79]

Features generated from code inputs enter ML models for predicting the CVSS
metrics. The predictions of the CVSS metrics are classification problems (see
Fig. 3). We used six well-known Machine Learning (ML) models for classifying
the classes of each CVSS metric: Logistic Regression (LR) [249], Support
Vector Machine (SVM) [206], K-Nearest Neighbors (KNN) [303], Random Forest
(RF) [251], eXtreme Gradient Boosting (XGB) [78], and Light Gradient Boosting
Machine (LGBM) [79]. LR, SVM, and KNN are single models, while RF, XGB, and
LGBM are ensemble models that leverage multiple single counterparts to reduce
overfitting. These classifiers have been used for SV assessment based on SV
reports [22, 23]. We also considered different hyperparameters for tuning the
performance of the classifiers, as given in Table 1. These hyperparameters
have been adapted from the prior studies using similar classifiers [22, 23,
304]. Here, we mainly focus on ML techniques, and thus using Deep Learning
models [203] for the tasks is out of the scope of this study.

####  5 Model Evaluation

Evaluation technique. To develop function-level SV assessment models and
evaluate their performance, we used 10 rounds of training, validation, and
testing. We randomly shuffled the dataset of vulnerable functions in section 1
and then split it into 10 partitions of roughly equal size.444With 1,782
samples in total, folds 1-9 had 178 samples and fold 10 had 180 samples. In
round $i$, for a model, we used fold $i+1$ for validation, fold $i+2$ for
testing, and all of the remaining folds for training. When $i+1$ or $i+2$ was
larger than 10, its value was wrapped around. For example, if $i=10$, then
$(i+1)\leavevmode\nobreak\ \text{mod}\leavevmode\nobreak\
10=11\leavevmode\nobreak\ \text{mod}\leavevmode\nobreak\ 10=1$ and
$(i+2)\leavevmode\nobreak\ \text{mod}\leavevmode\nobreak\
10=12\leavevmode\nobreak\ \text{mod}\leavevmode\nobreak\ 10=2$. A grid search
of the hyperparameters in Table 1 was performed using the validation sets to
select optimal models. The performance of such optimal models on the test sets
was reported. It is important to note that our evaluation strategy improves
upon 10-fold cross-validation and random splitting data into a single
training/validation/test set, the two most commonly used evaluation techniques
in (fine-grained) SV detection and report-level SV assessment studies [305,
306, 278, 276, 277, 11]. Our evaluation technique has separate test sets,
which cross-validation does not, to objectively measure the performance of
tuned/optimal models on unseen data. Using multiple (10) validation/test sets
also increases the stability of results compared to a single set [212].
Moreover, we aim to provide baseline performance for function-level SV
assessment in this study, so we did not apply any techniques like class
rebalancing or feature selection/reduction to augment the data/features. Such
augmentation can be explored in future work. We also did not compare SV
assessment using functions with that using reports as their use cases are
different; function-level SV assessment is needed when SV reports are
unavailable/unusable. It may be fruitful to compare/combine these two
artifacts for SV assessment in the future.

Evaluation measures. We used F1-Score555The macro version of F1-Score was used
for multi-class classification. and Matthews Correlation Coefficient (MCC)
measures to quantify how well developed models perform SV assessment tasks.
F1-Score values are from 0 to 1, and MCC has values from –1 to 1; 1 is the
best value for both measures. These measures have been commonly used for SV
assessment (e.g., [22, 124, 23]). We used MCC as the main measure for
selecting optimal models because MCC takes into account all classes, i.e., all
cells in a confusion matrix, during evaluation [307].

Statistical analysis. To confirm the significance of results, we employed the
one-sided Wilcoxon signed rank test [254] and its respective effect size
($r=Z/\sqrt{N}$, where $Z$ is the $Z$-score statistic of the test and $N$ is
the total count of samples) [308].666$r\leq 0.1$: negligible, $0.1<r\leq 0.3$:
small, $0.3<r\leq 0.5$: medium, $r>0.5$: large [309] We used the Wilcoxon
signed-rank test because it is a non-parametric test that can compare two-
paired groups of data, and we considered a test significant if its confidence
level was more than 99% ($p$-value $<$ 0.01). We did not use the popular
Cohen’s D [310] and Cliff’s $\delta$ [311] effect sizes as they are not
suitable for comparing paired data [279].

###  5 Results

####  1 RQ1: Are Vulnerable Code Statements More Useful Than Non-Vulnerable
Counterparts for SV Assessment Models?

Based on the extraction process in section 1, we collected 1,782 vulnerable
functions containing 5,179 vulnerable and 57,633 non-vulnerable statements.
The proportions of these two types of statements are given in the first and
second boxplots, respectively, in Fig. 4. On average, 14.7% of the lines in
the selected functions were vulnerable, 5.8 times smaller than that of non-
vulnerable lines. Interestingly, we also observed that 55% of the functions
contained only a single vulnerable statement. These values show that
vulnerable statements constitute a very small proportion of functions.

Despite the small size (no. of lines), vulnerable statements contributed more
to the predictive performance of the seven assessment tasks than non-
vulnerable statements (see Table 2). We considered two variants of non-
vulnerable statements for comparison. The first variant, Non-vuln (random),
randomly selected the same number of lines as vulnerable statements from non-
vulnerable statements in each function. The second variant, Non-vuln (all)
aka. Non-vuln (All - Vuln) in Fig. 4, considered all non-vulnerable
statements. Compared to same-sized non-vulnerable statements (Non-vuln
(random)), Vuln-only (using vulnerable statements solely) produced 116.9%,
126.6%, 98.7%, 90.7%, 147.9%, 111.2%, 116.7% higher MCC for Access Vector,
Access Complexity, Authentication, Confidentiality, Integrity, Availability,
and Severity tasks, respectively. On average, Vuln-only was 114.5% and 43.6%
better than Non-vuln (random) in MCC and F1-Score, respectively. We obtained
similar results of Non-vuln (random) when repeating the experiment with
differently randomized lines. When using all non-vulnerable statements (Non-
vuln (all)), the assessment performance increased significantly, yet was still
lower than that of vulnerable statements. Average MCC and F1-Score of Vuln-
only were 7.4% and 5.5% higher than Non-vuln (all), respectively. The
improvements of Vuln-only over the two variants of non-vulnerable statements
were statistically significant across features/classifiers with $p$-values $<$
0.01 ($p$-value${}_{Non-vuln(random)}=1.7\times 10^{-36}$ and
$p$-value${}_{Non-vuln(all)}=7.2\times 10^{-11}$) and non-negligible effect
sizes ($r_{Non-vuln(random)}=0.62$ and $r_{Non-vuln(all)}=0.32$). The low
performance of Non-vuln (random) implies that SV assessment models likely
perform worse if vulnerable statements are incorrectly identified. Moreover,
the decent performance of Non-vuln (all) shows that some non-vulnerable
statements are potentially helpful for SV assessment, which are studied in
detail in RQ2.

Figure 4: Proportions of different types of lines in a function. Notes: Min proportion of Vuln-only lines is non-zero (0.03%); thus, max of Non-vuln line proportion is $<$ 100%. Cosmetic lines were excluded from the computation of ratios. Table 2: Testing performance for SV assessment tasks of vulnerable vs. non-vulnerable statements. Note: Bold and grey-shaded values are the best row-wise performance. CVSS metric |  Evaluation metric | Input type
---|---|---
Vuln-only |  Non-vuln (random) |  Non-vuln (all)
Access Vector | F1-Score | 0.820 | 0.650 | 0.786
MCC | 0.681 |  0.314 |  0.605
Access Complexity | F1-Score | 0.622 | 0.458 | 0.592
MCC | 0.510 |  0.225 |  0.467
Authentication | F1-Score | 0.791 | 0.602 | 0.765
MCC | 0.630 |  0.317 |  0.614
Confidentiality | F1-Score | 0.645 | 0.411 | 0.625
MCC | 0.574 |  0.301 | 0.561
Integrity | F1-Score | 0.650 | 0.384 | 0.616
MCC | 0.585 |  0.236 |  0.534
Availability | F1-Score | 0.647 | 0.417 | 0.624
MCC | 0.583 |  0.276 |  0.551
Severity | F1-Score | 0.695 | 0.414 | 0.610
MCC | 0.583 |  0.269 |  0.523
Average | F1-Score | 0.695 | 0.484 | 0.659
MCC | 0.592 | 0.276 | 0.551

####  2 RQ2: To What Extent do Different Types of Context of Vulnerable
Statements Contribute to SV Assessment Performance?

In RQ2, we compared the performance of models using Program Slicing (PS),
surrounding and function context. Notably, we removed 365 cases for which we
could not extract PS context from the dataset in section 1. Apparently, these
cases were the same as using only vulnerable statements, making comparisons
biased, especially against Vuln-only itself. The vulnerable statements in
these cases mainly did not contain any variable, e.g., using an unsafe
function without parameter.777https://bit.ly/3pg36mp In this new dataset, PS
and surrounding context approximately constituted 46%, on average, of lines in
vulnerable functions (see Fig. 4). We used six lines before and after
vulnerable statements (n = 6) as surrounding context because this value
resulted in the closest average context size to that of PS context. It is
impossible to have the exactly same size because PS context is dynamically
derived from vulnerable statements, while surrounding context is predefined.
The roughly similar size helps test whether directly SV-related lines in PS
context would be better than pre-defined surrounding lines for SV assessment.
The training and evaluation processes on the dataset in RQ2 were the same as
in RQ1.888The RQ1 findings still hold when using the new dataset in RQ2, yet
with a slight ($\approx$2%) decrease in absolute model performance.

Adding context to vulnerable statements led to better SV assessment
performance than using vulnerable statements only (see Fig. 5). Among the
three, function context was the best, followed by PS and then surrounding
context. In terms of MCC, function context working together with vulnerable
statements beat Vuln-only by 6.4%, 6.5%, 9%, 8.2%, 11%, 11.4%, 9.7% for Access
Vector, Access Complexity, Authentication, Confidentiality, Integrity,
Availability, and Severity tasks, respectively. The higher F1-Score values
when incorporating function context to vulnerable statements are also evident
in Fig. 5. On average, combining function context and vulnerable statements