# Vulnerability Forecasting: In theory and practice.

Éireann Leverett<EMAIL_ADDRESS>0000-0001-6586-7359 ,  Matilda
Rhode<EMAIL_ADDRESS>and  Adam Wedgbury<EMAIL_ADDRESS>AirbusQuadrant House, Celtic Springs Business Park, Coedkernew,
DuffrynNewportU.K.NP10 8FZ

(2020)

###### Abstract.

Why wait for zero-days when you could predict them in advance? It is possible
to predict the volume of CVEs released in the NVD as much as a year in
advance. This can be done within 3 percent of the actual value, and different
predictive algorithms perform well at different lookahead values. It is also
possible to estimate the proportions of that total volumn belonging to
specific vendors, software, CVSS scores, or vulnerability types. Strategic
patch management should become much easier, with this uncertainty reduction.

cyberrisk, forecasting, prediction, CVE, vulnerabilities, vulnerability
management

††copyright: acmcopyright††journalyear: 2020††doi:
10.1145/1122445.1122456††journal: DTRAP††journalvolume: 0††journalnumber:
0††article: 0††publicationmonth: 0

##  1\. Motivation

Most computer security vulnerability management problems are plagued by
reactivity to the disclosure of a Common Vulnerability Enumeration (CVE) or
the release of a patch. The cadence of patch release is necessarily correlated
with the release of CVEs, while the patch installation is dictated by business
risk patterns. The release of CVEs is commonly viewed as stochastic,
unpredictable, and difficult to imagine before they emerge. Turning to
expectation of exploits as posterior probabilistically from CVE disclosure:
recent analysis has found that 80% of exploits are written before the CVE is
published, by 23 days on average (Chen, 2020). This resonates with the
authors’ experience that a basic exploit often has to be written to convince
the company of the need for a CVE in the first place. The only question is
whether such exploits are released more publicly in frameworks such as
metasploit, semi publicly on platforms such as exploitDB; or semi-privately in
exploitkits.

A vision of the future of vulnerability and weakness management needs a solid
foundation: the ability to forecast the volume of CVEs being produced within
discrete time spans (ideally user specified). If those forecasts are
reasonably accurate (plus or minus some confidence or prediction interval),
then prediction of finer grain details will be accomplished more easily. Many
other cyber risk management problems become significantly easier, because we
have more time to plan ahead and thus become less reactive; we shift decision
making to an earlier point in the timeline of vulnerability and risk
management.

The predicted volume of CVEs can be used both to inform patch strategies
(priotitisation) but also resource requirement estimatation. Advanced planning
of required resources for patching and vulnerability management would be
valuable even if maximum optimisation of resources to risk reduction is not
achievable. For example consider the severity, frequency, and types of
vulnerabilities disclosed with forecasting in mind. It would be valuable to
know if an exploit exists already, or the vulnerability was found in the wild
already being exploited, regardless of our ability to minimise the risk at
precisely the right moment and for the absolute minimum cost. Which is to say,
a competent risk manager can manage the uncertainty if it is stated carefully
in the forecasts.

A future application of CVE prediction will also be found in the conditional
probabilities; such as ‘If the next CVE in this software is a memory
corruption, what probability is there that an exploit is developed within 3
months?’ or ‘If this software becomes deployed on 25% of internet facing
servers, what chance is there that an exploitable vulnerability will be found
in it?’. To achieve any of that, forecasting and risk analysis of the CVE
data, public disclosures, exploits, and operating systems, is necessary.

##  2\. Contributions

The key contributions of this work are summarised below:

  1. (1)

A publicly available leading indicator that has not been used in previous work
but drastically improves machine learning model accuracy (See 5.1).

  2. (2)

Two statistical models are applied to this problem which have not been used in
previous work and are shown to outperform currently leading machine learning
and time-series forecasting approaches for long-term predictions (See 5).

  3. (3)

A set of models for predicting the number of vulnerabilities in both the
short- and long-term, forecasting within 3% of the true values for 1 year
lookahead predictions on average. Previous work has focused on short (1 to 3
months) or long term (1 or 2 years) time periods only, when patch managers are
likely to want to analyse both next month’s and next year’s predictions (See
6.1).

  4. (4)

A flexible framework to predict the number of total vulnerabilities or a
specific subset, using an appropriate model for the task. Previous work
typically looks at the number of vulnerabilities for specific products only.
They only cover well-represented products with a low CVE-instance variance.
These are easier to predict (See 6.2).

  5. (5)

This work acknowledges that we may want to predict CVEs in products that have
never had a CVE before. We uncover some challenges of predicting less commonly
seen sub-types of vulnerabilities accordingly (See 6.2).

There are various different types of forecasting for security vulnerabilities.
In this paper the focus is primarily on forecasting _publicly disclosed
vulnerabilities_ , that might impact a user of any software or firmware. The
aim is to translate that prediction and forecasting capability to optimise
minimum resources for maximum risk reduction in vulnerability management.
However, we take a broader view in the literature below to overview other
aspects of the research because it also offers insights. So what has been done
to date in this respect?

##  3\. Background and Related Work

As a lightweight taxonomy, there are three broad streams of vulnerability
forecasting research.

  1. (1)

Existing network vulnerabilities Given previous network or single host
vulnerability scans, forecast how many previously known CVEs will be next
found, and the density of vulnerabilities in different targets, or more
simply: the rate of change between host or network scans.

  2. (2)

Future software vulnerabilities Given source code or a compiled binary,
forecast how many vulnerabilities there might be, where they are, or how much
effort it might take to find them.

  3. (3)

Future vulnerabilities: all types Given data on historical Common
Vulnerability Enumerations (CVEs), use machine learning to estimate the volume
of published vulnerabilities in a given time frame, and/or resource
requirements to patch them. Given further information such as Common
Vulnerability Scoring System (CVSS) or knowing an exploit already exists,
estimate difficulty to patch and/or risk reduction from having done so.

In the literature review that follows the papers are grouped into these three
broad categories, skipping briefly beside the first two streams, before diving
into the rushing rapids of the third.

###  3.1. Stream One: Forecasting the Vulnerability of Specific Computers or
Networks

This branch of academic literature concerns itself with the prediction of the
vulnerability of a given machine or network. Sometimes it is even more
specific, such as the presence of a particular Common Vulnerability
Enumeration (CVE) on an Internet Protocol (IP) address or range of addresses
e.g. (Venter and Eloff, 2004). Or, closely related to the CVE forecasting work
in this paper, estimating the number of unpatched vulnerabilities in an
organization based on the products in use and Bayesian inference
(Chatzipoulidis et al., 2015) or fuzzy sets (Aleksić et al., 2014). This seems
more applicable to red teams than blue teams, though blue teams could use it
as a metric to optimise patching strategies. For example, if you wanted to
patch machines non-homogenously across a network, to make it hard to predict
which machines were vulnerable to different exploits. This may have stronger
application where scanning is likely to miss results due to computers joining
and leaving the network (University WiFi) or being down for maintenance (OT
Networks). In short, where the network’s graph of connections could be
considered a dynamic in temporal sense, this type of prediction may be very
useful.

###  3.2. Stream Two: Pre-disclosure Vulnerability Forecasting

There is plenty of literature on predicting the number of
undiscovered/undisclosed vulnerabilities in software. Some of that literature
focuses simply on the numbers (Vander Wiel and Votta, 1993; Petersson et al.,
2004; Scott and Wohlin, 2008), and other papers on how much effort it takes to
find them and what improvement may or may not be achieved (Brady et al., 1999;
Rescorla, 2005; Ozment and Schechter, 2006). Some even make forays and efforts
into the value of predictability and forecasting (Alhazmi and Malaiya, 2006).
The primary aim and application of this type of research is the prevention of
vulnerabilities during the software development lifecycle. In other words,
preventing the vulnerabilities from reaching a production system and getting a
CVE at all.

Another distinctive sub-field of this research advocates becoming active; one
can deliberately inject vulnerabilities to be able to figure out the rate at
which your security testers find them (Schuckert, 2016). Alternatively, one
could use a security code review team to find vulnerabilities, then not fix
them, and see if the QA team finds them again to produce an estimation of how
many have not been observed (Lincoln Index) (Geer, 2015). Such an index allows
you to estimate the vulnerabilities remaining in a static codebase, which may
or may not have value depending on the velocity of your development team; if
your development team is changing the code too quickly, your fixes may not
have much value as they inject more vulnerabilities at a higher speed.

###  3.3. Stream Three: Post-Disclosure Vulnerability and Exploit Forecasting

This is the stream of greatest relevance for our own work within this paper,
and explores the predictive power of estimating the number of vulnerabilities
that are publicly disclosed as CVEs.

The primary application of such research would be in managing patching teams,
tools, and networks, exploring patch strategies, and thinking about third
party software interactions.

Yasasin et al present an excellent systemization of knowledge paper, that also
demonstrates some promising and practical empirical results (Yasasin et al.,
2020). The paper surveys the literature much more broadly than we do here, and
provides many other points of departure for the interested reader. The authors
compare multiple time series forecasting models to predict the number of
vulnerabilities for specific vendors. In particular if the model under
construction is meant to be vendor or product specific one (I.E. all Microsoft
product disclosures, or Mozilla:Firefox disclosures), for which there may be
many time periods in which there are zero disclosed vulnerabilities. The
authors caution against the use of relative metrics such as percentages. The
authors detail how to test the predictive power of various time series models
and report that Croston’s and ARIMA forecasting models tend to perform best
but do not select an overarching methodology for predicting the number of
vulnerabilities attributed to any product. Further the work is limited to 1, 2
and 3 month forecasts ”Since forecasting research has shown that long-term
forecasts are generally limited in their predictive accuracy”, whereas here we
seek to predict up to one year in advance. Our work builds on this paper by
using a more robust testing methodology where strict date separation is
enforced between the training and test set to better-mimic real-world use
(more details in Subsection 4.4).

Another inspiring paper revisits predicting product specific disclosures for
Operating Systems (Pokhrel et al., 2017). This one details both ARIMA and an
approach using Artificial Neural Networks (ANNs). The authors predict numbers
of CVEs for 12 single months, sum them, and compare to the yearly total for
the test set, but this is not the same as predicting the next year’s total
CVEs since the model has information about what has happened so far in a year
(e.g in July) to predict the total number appearing between January and
December. These increasing forecast projections are decreasingly accurate, but
might still be accurate enough for resource planning. Here the authors observe
strict date splitting, only testing on data from 2016 and training on data up
to the end of 2015. The confidence intervals are defined for the predictions,
which also assist the astute risk manager. However, we note that prediction
intervals would have been a better choice to represent uncertainty boundaries,
than confidence intervals in this respect as the former capture both the
uncertainty around the mean prediction and around the variance (thus the
prediction interval is always wider than the confidence interval).

Last (Last, 2016) predicts broader categories: all vulnerabilities, Browser
CVEs, Operating System CVEs, and Video Codec CVEs. This approach uses root
mean squared percentage error (RMSPE) as a validation metric (which the deep
reader remembers was discouraged by (Yasasin et al., 2020) in the cases of
zero-inflated time series); and notes the occasional limited success of using
software release dates alongside other data to aid in the forecasting
accuracy. This work predicts 12, 18 and 24 month windows, using strict date
separation, with a testing window from 2012 to 2015, achieving a median 15%
RMSPE for global vulnerability predictions over 24 months, the work presented
herein is able to significantly improve this metric for long-term global
predictions. Last’s work reveals an increasing accuracy as the forecast window
increases from 12 to 24 months, this is a result we have found to extend to
short term predictions: the total number of vulnerabilities next year is
easier to predict than next month’s. However, this approach predicts the
cumulative total CVEs for all time, such that the percentage error metrics
cannot be considered consistent over time, furthermore the cumulative totals
i.e. how many CVEs there have been since 2001, are unlikely to be useful to
patch managers.

At the more mathematical end of the academic spectrum, we find a paper which
provides methods to optimise response to demand volumes (Wang et al., 2008).
This provides a solid foundation for optimising our response to the numbers of
vulnerabilities a potential model may predict but, more discussion is needed
about the variability of response to differing numbers of patches. Useful as
this paper is, it is not specific to our domain of publicly disclosed
vulnerabilities, though it does detail an interesting method for making
unsupervised hybrid models by scaling horizontally with more processing power.
In this research, we have not found processing power to be a limiting factor.

One paper notes that vulnerabilities follow market share (O’Donnell, 2008),
while another warns us to ‘mind the denominator’ (Jardine, 2018). For our
purposes that might mean using the full Common Platform Enumeration (CPE)
dictionary to look at probabilities for vulnerabilities, instead of only
vulnerability databases. Indeed we discuss later in the paper the challenge of
predicting CVEs for products that have never appeared in the CVE List before,
and that is where using the CPE might help in some cases.

It is important to scour amongst hacker literature as well as academic papers.
Many academics hide their light under a bushel and present very practical
results at hacker conferences such as BlackHat or Chaos Communication
Congress. Allodi, for example, has captured a very important piece of
information security risk reduction measurement in this presentation of the
perils of CVSS as a risk
quantification111https://media.blackhat.com/us-13/US-13-Allodi-HOW-CVSS-is-
DOSsing-Your-Patching-Policy-Slides.pdf. The gist of it is that most
vulnerabilities don’t have exploits, and don’t get exploited. Improving the
specificity (false positive for exploited vulnerabilities) of our work would
save us a lot of patching effort. Allodi has also published a related paper on
the distribution of exploitation per cve(Allodi, 2015).

An intellectual offspring of Allodi’s work was performed by Cyentia Institute
and Kenna Security222https://i.blackhat.com/USA-19/Thursday/us-19-Roytman-
Predictive-Vulnerability-Scoring-System-wp.pdf. Here they look at a wider
dataset of exploited machines in IDS traffic, trying to learn from what gets
exploited and extrapolating towards better patching. That work has now become
a special interest group at FIRST.org for Exploit Prediction and Scoring
Systems (EPSS).

Previous work into vulnerability forecasting has demonstrated that it is
possible to predict the numbers of all expected CVEs or subsets of CVE
categories for a few months or a couple of years but has failed to develop a
framework that is capable of spanning both. In this paper we present a model
to predict both short- and long-term numbers of vulnerabilities using publicly
available data from MITRE that has not previously been written about for this
purpose.

This stream also has applications to supply chain management and passive
vulnerability scanning as well. It may not be intuitive that forecasting is
useful to risk management even when you have no intention of patching as a
risk treatment. To illustrate that it is still useful, consider that CVE
forecasting could answer questions of the form: A submarine is launched with
vendor X’s product; knowing it can not be patched for a year due to
cost/battery/bandwidth reasons, how many vulnerabilities can be expected to
emerge in Vendor X’s product within that year of service? Another way of
looking at it might be: Estimate how often I need maintenance downtime to
patch Vendor X’s products above CVSS 7 this year. With this in mind, what data
can we use for prediction and forecasting, to move towards answering such
questions?

##  4\. Data Used

As with previous work in vulnerability forecasting (Last, 2016; Pokhrel et
al., 2017; Yasasin et al., 2020) this research uses the US-government’s
National Vulnerabilities Database (NVD) with a goal to predict the number of
vulnerabilities (matching certain criteria) that will be published to this
database within a given future time span (lookahead window). The NVD data
itself can be used as a signal for this prediction but is more effective when
augmented by additional data from MITRE; the organisation that maintains and
publishes the CVE-list, which feeds the NVD.

###  4.1. NVD

The NVD maintains detailed information about CVEs including but not limited
to:

  1. (1)

date published

  2. (2)

the organisation reporting the CVE (known as a CVE Numbering Authority or CNA)

  3. (3)

a text description

  4. (4)

Strings indicating specific entities impacted by the CVE (Known as Common
Platform Enumerations or CPE strings)

CVEs are identified by a CVE-ID string in the format: CVE-YEAR-XXXX. During
this research it became evident that the YEAR in the CVE-ID did not match the
publication year in all instances. This is because the CVE-ID reflects the
year in which the vulnerability was assigned rather than published. Figure 1
illustrates the disparity between publication year and CVE-ID year, some early
CVEs were added retrospectively even assigned a CVE year later than they are
published but this is an anomalous attribute of the early entries in the
database. Every CVE is assigned prior to being published, sometimes years in
advance, sometimes as little as an hour. The XXXX part of the ID corresponds
to a serial number thus allowing us to infer that on publication of
CVE-2020-0100 there are unpublished CVE IDs reserved for CVE-2020-0001 to
CVE-2020-0099 even if they have not been published333In practice these can be
more digits such as CVE-2020-XXXXX or CVE-2020-XXXXXX. Thus we are able to
find that $N$ CVEs are in the pipeline, which improves the accuracy of
predictive models. This latent data is the foundation of one of the models
presented in this paper in 5.2. In short, CVEs are ordered on arrival, but
released stochastically according to progress internal to MITRE. That ordering
allowed us an initial insight into how long they take to process, later
supplanted by the CVE list we discuss below.

Figure 1. Heatmap of CVE Year against Publication Year over the historical
record.

###  4.2. MITRE

mean | 162 days 11:50:28
---|---
standard deviation | 390 days 06:14:18
min | 0 days 01:02:00
1st quartile | 1 days 05:17:00
median | 51 days 15:57:00
3rd quartile | 160 days 20:29:00
max | 6263 days 15:15:00
Table 1. Summary of lags between database entry and publication of CVEs

Every CVE-ID is assigned by MITRE or one of their approved CNAs444144
organisations as of 5th November 2020: https://cve.mitre.org/cve/cna.html. The
specific assigned dates are published by MITRE 555Available to download:
https://cve.mitre.org/data/downloads/index.html, which gives much better
granularity of the assigned date than using the CVE-IDs. MITRE provides the
assigned date whilst the NVD catalogues the date published. Research from Chen
(PaoloAlto Networks) (Chen, 2020) asserts that 80% of CVEs have a publicly
available exploit on average 23 days before the CVE is published. Combining
NVD and MITRE data reveals that the median lag between assigned date and
publication date is 51 days (see Table 1). These statistics underscore the
possibility and usefulness of being able to predict the publication of CVEs at
least one month in advance.

###  4.3. Challenges

Examining the raw data highlights some of the challenges in predicting CVE
numbers. Four key challenges are briefly described below:

Figure 2. Number of CVEs published in weeks 42-46 of 2020 per week (left) and
per day (right)

Short-term variance Due to the idiosyncrasitic policies and practices of both
CNAs and MITRE, some of which are common to all non-automated processes,
sometimes an abormally large number of CVEs are published in a single day.
Figure 2) shows the number of CVEs published on a daily and weekly basis. Some
days there are not any CVEs published e.g. there are few Saturdays, (day 6s)
in the graph. One day there are 243 published. This high variance is less
evident in the aggregated week publications and there is less variance still
in monthly and yearly publication numbers, illustrated by Figure 11 . This
presents a challenge for predicting short-term numbers of all CVEs.

New products Some products may see a sudden, unprecedented increase in the
number of CVEs. This may be because the product is new, because it’s market
share has increased (O’Donnell, 2008) or due to some other factor that is
exogenous to NVD or MITRE data. It is challenging for the model to predict
something entirely new which has either not previously existed or has been at
zero for a long time. This is a challenge for long-term CVE predictions.

Figure 3. Annual total CVEs published 2002 to 2020

Structural changes in CVE publication patterns Though the variance is lower
for annual total CVE counts, there are clear step-changes in the numbers of
CVEs being published (see Figure 3) either side of 2005 and of 2017 and to a
lesser degree in 2014. This is a challenge for models using historic data to
predict new vulnerability totals, one which is explored using data filtering
in the experiments reported in this paper.

Assigned date is not a sufficient leading indicator for long term prediction.
Whilst the assigned date will indicate how many CVEs are in the pipeline, this
data is not sufficient to predict the number of vulnerabilities that will be
published within a given forecast window (lookahead). This is because (1) some
CVEs are rejected by MITRE (2) some CVE-IDs are reserved by CNAs speculatively
but never populated (3) even if we know how many are in the pipeline, we do
not know how many more will be assigned and published within the forecast
window.

###  4.4. Evaluation

This section presents the two evaluation methodologies used in this paper:
retrocasting and forecasting. Retrocasting is used for evaluating model
accuracy, forecasting is for resource management and planning, i.e. real-world
use.

Some previous work e.g (Yasasin et al., 2020) that has not separated training
and test sets by date may have inadvertently leaked data about yearly
structural changes or the existence of new products in the NVD database, in
reality a model would have no warning of these changes. For retrocasting, as
strictly future time window is used: September 2018 to September 2020. To
calculate the prediction interval we use a validation set from January 2018 to
September 2018. Training data precedes 2018. The prediction intervals were
used to provide $\pm$ bounds around the forecasted values.

Retrocasting iteratively pretends we are somewhere in the past trying to
predict the number of CVEs in the future, this approach allows us to
approximate the performance of our model when it is deployed. Retrocasting
predicts the number of CVEs seen in a fixed period of time (e.g. one month)
for multiple “end” dates (end of the lookahead window) in the test set, here
the end dates are staggered at 10 day intervals between Sept. 2018 and Sept.
2020. Retrocasting fixes the lookahead (the window of time we are trying to
predict) but changes the end date and use the average accuracy metrics as an
indicator of future performance. Empirically we verified that it is possible
to be more accurate on some longer time windows, than on some shorter ones.
Strange, but true.

Forecasting by contrast fixes the date from which we are trying to predict and
changes the lookahead to give estimates for different time periods into the
future. The purpose of forecasting is that for use in resource management,
patch maintenance teams may want a short-to-long-term view of the number of
vulnerabilities being seen.

Previous work has indicated that a range of machine learning and statistical
paradigms, some capable of time series analysis are superior to others in
their forecasting capabilities. For comparison with prior work and to ensure
that the most accurate model is being used for each forecast context
(lookahead and CVE sub-group) a number of evaluation metrics are collected to
determine the best model.

The metrics used in this paper are outlined in the following table for
$N={i=0,...N}$ prediction windows where $y_{i}$ is the true number of CVEs
published in a single window and $\hat{y_{i}}$ is the corresponding predicted
number:

  * •

Mean absolute error (MAE): $\frac{1}{N}\sum_{i=0}^{N}(|y_{i}-\hat{y}_{i}|)$
gives average absolute difference between true values and predicted values

  * •

Mean squared error (MSE): $\frac{1}{N}\sum_{i=0}^{N}(y_{i}-\hat{y}_{i})^{2}$
exponentially penalises large differences

  * •

Mean logarithmic squared error (MSLogE):
$\frac{1}{N}\sum_{i=0}^{N}(log(y_{i}+1)-log(\hat{y}_{i}+1))^{2}$ does not
penalise large differences disproportionately if the values themselves are
large (e.g. 1000 vs 1100 is not as bad as 0 vs 100) and penalises
underestimates more than overestimates.

  * •

Prediction interval: Let $\sigma$ be an unbiased estimate of of the standard
deviation calculated by $\sqrt{\frac{\sum{(Y-\hat{Y})^{2}}}{N-2}}$, and $z$ a
confidence interval z-score e.g. 1.96 for 95% confidence interval, then the
prediction interval is $\hat{Y}\pm z*\sigma$ for a validation set

  * Custom metrics

  * •

Percentage of predictions more than 10% from true values:
$\frac{1}{N}\sum_{i=0}^{N}(\frac{|y_{i}-\hat{y}_{i}|}{y_{i}}>0.1)$

  * •

Percentage of predictions more than 5% from true values:
$\frac{1}{N}\sum_{i=0}^{N}(\frac{|y_{i}-\hat{y}_{i}|}{y_{i}}>0.05)$

  * •

Percentage of predictions more than 5% below true value or 20% above true
value:
$\frac{1}{N}\sum_{i=0}^{N}((\frac{\hat{y}_{i}-y_{i}}{y_{i}}>0.2)*(\frac{y_{i}-\hat{y}_{i}}{y_{i}}>0.05)))$

The first three provide benchmarking against existing approaches, and even
some verification of their results. Of the mean metrics, this paper prefers
MSLogE as it scales the difference between true and predictive values
according to the magnitude of the true value e.g. observed 1000 vs predicted
1100 is less bad than observed 0 vs predicted 100, MSE and MAE give the same
error for both. MSlogE also penalises underpredictions more harshly that
overpredictions, in this use case, we would rather overestimate the resources
required for vulnerability management for next year than underestimate them.
The custom metrics appeal to the notion that in practice patch managers may
care more about how often the model is right rather than the numeric accuracy
over all time. After all, they’ve lived with uncertainty for nearly two
decades already.

##  5\. Predictive models

For comparison against previous work we use the following models. Non-time-
series statistical models: Single back-cast: take the previous year’s (month,
week, etc.) total to predict this year (month, week, etc.); rolling mean: Take
a mean over the last few years (months, weeks, etc.). Non-time-series machine
learning models: Logistic regression, Bayes Ridge, Random Forest, Multi-layer
perceptron (feed-forward neural network. Time-series statistical models:
ARIMA, Croston’s. Time-series machine learning models: Long-Short-Term Memory
(LSTM) recurrent neural network.

The line between a statistical and machine learning model is not sharply
defined. Here, we distinguish machine learning and non-machine learning models
as those models capable of learning from multiple input features and those
which only take the historical data of the target values as inputs.

We further present two models Minimum Variance Unbiased Estimator: predicts
the total number of CVEs based on the highest ID number seen and the number
published; Little’s Law with Lookback: Uses elements of Little’s law and
predicts the entry rate into the MITRE database, scaling this by the ratio of
CVEs published within a given window following entry. The next two sections
outline these models in full detail.

###  5.1. A Yearly MVUE

A well known Minimum Variance Unbiased Estimator exists for serial number
prediction problems. It is:

$N\approxeq(M/M*Obs)-1$

Where $N$ in our case would be the number of CVEs with a single year as string
name (CVE-2020-XXXX for example). $M$ is the maximum CVE published, and $Obs$
is the number of CVEs published (observed) that conform to the string
CVE-2020-XXXX. Obviously this gives us another challenge, which is to maintain
the numbers for all previous years, and see if they have all been published
yet. After all, it is evident that some vulnerabilities appear 17 years later
(NVD, 2019).

This indicator was in important stepping stone for our efforts, because it
enabled us to evaluate the proportion of CVEs that get published within the
same year and the length of time it takes to publish all CVEs assigned within
a year. Specifically, note that it represents all the CVEs assigned in that
year (actually we believe they start assigning them from Sep the previous
year), and that some of those will still be published years afterward. So in
this sense, it is not a good forecast model, but serves us better as an
indicator.

It gave crucial insights which led to the next approach, trying to manage the
state of predicted and observed CVE totals in a simpler way. We expect that
many vulnerability management organisations already knew this trick, but for
some reason we can’t find reference to it in academic literature, and so we
publish it here.

###  5.2. A Matrix Based Approach

The best way to explain this methodology is with some tables to represent a
large stored matrix. The goal is to capture a few important transitions of the
matrix based approach that updates probability vectors to reflect new
information, and makes uncertain events certain after they occur.

Imagine it is near the end of 2019, and a vulnerability comes out marked
CVE-2019-0002. This vulnerability came out in 2019, so we put a 1.0 in this
column to represent this certainty (Table 2). We can also infer the existence
of CVE-2019-0001 as described in the section above, and write it into a row as
well. However, we don’t know when this one will come out, but we can use the
historical record to say 94 per cent come out within the same year, and 5
percent come out the next year, adding in the probabilities created from the
historical record across as many years lookback as we think is relevant.

CVE Name | 2019 | 2020 | 2021 | 2022
---|---|---|---|---
CVE-2019-0001 | 0.94 | 0.054 | 0.0032 | 0.0028
CVE-2019-0002 | 1.0 | 0.0 | 0.0 | 0.0
Table 2. CVE-2019-0002 is published, and we can infer the existence of
CVE-2019-0001.

Now imagine that 2019 has come and gone. We know that CVE-2019-0001 has not
been published in 2019. So we need to update our probabilities to reflect this
new information. In this example, we have used a made up set of probabilities
= [0.94, 0.054, 0.003, 0.002], which for the sake of a simpler discussion
let’s assume come from a historical record of 1000 vulnerabilities over all
time666The real vectors can be seventeen years/items long and run to many more
decimal places.In practice only the first few years make up enough proportion
to be relevant to accuracy.. First we zero out the remainder of the row, of
the CVE probabilities (see Table 3).

CVE Name | 2019 | 2020 | 2021 | 2022
---|---|---|---|---
CVE-2019-0001 | 0.0 | 0.0 | 0.0 | 0.0
CVE-2019-0002 | 1.0 | 0.0 | 0.0 | 0.0
Table 3. CVE-2019-0001 is not published in 2019.

Then we must calculate the new probability by re-scaling the vector across the
remaining relevant probabilities. Let’s say 940 of our vulnerabilities are
published the same year as they are assigned, but now we must eliminate them
from our study. That leaves a historical record that is 54 published 1 year
later, 3 published 2 years later, and 2 published 3 years later [54, 3, 2]. We
sum the remaining list and get 59 vulnerabilities777The numerate amongst you
will realise 940+59 does not equal 1000, and that can reflect the number of
vulnerabilities that go unpublished, disputed, or rejected. Of course it is
also possible to use only the vulnerabilities that get published and provide a
another term to estimate the percentage that will get published, but in
practice it makes little difference how you approach that. As long as the
method is consistent, it will produce similar results.. So our updated
probability becomes [54/59,3/59,2/59] or [0.91,0.05,0.03] (see Table 4).

CVE Name | 2019 | 2020 | 2021 | 2022
---|---|---|---|---
CVE-2019-0001 | 0.0 | 0.91 | 0.05 | 0.03
CVE-2019-0002 | 1.0 | 0.0 | 0.0 | 0.0
Table 4. CVE-2019-0001 is not published in 2019.

This method of rescaling probabilities works well, and is rather efficient.
You just update the whole table once a year. Now let’s examine another
important scenario, new vulnerabilities being added for 2020. Let’s imagine
CVE-2020-0002 and CVE-2020-0004 are published, remember this means we can
infer the existence of CVE-2020-0001 and CVE-2020-0003, to which we assign a
probabilistic publication (see Table 5).

CVE Name | 2019 | 2020 | 2021 | 2022
---|---|---|---|---
CVE-2019-0001 | 0.0 | 0.91 | 0.05 | 0.03
CVE-2019-0002 | 1.0 | 0.0 | 0.0 | 0.0
CVE-2020-0001 | 0.0 | 0.94 | 0.05 | 0.03
CVE-2020-0002 | 0.0 | 1.0 | 0.0 | 0.0
CVE-2020-0003 | 0.0 | 0.94 | 0.05 | 0.03
CVE-2020-0004 | 0.0 | 1.0 | 0.0 | 0.0
Table 5. CVE-2020-0002 and CVE-2020-0004 are published in early 2020.

Now, let’s predict the number of Vulnerabilities that will be published. Sum
the column for 2020 (highlighted in cyan in Table 5), to predict for 2020.
That reflects accurately how many were published, but also how many are
expected. In this case the answer would be 4.76, rounded up to 5.

How do we calculate those probabilities from this matrix? Let’s publish one
more vulnerability before we do that, to illustrate.

Now suppose CVE-2019-0001 finally gets published, and we record this by
zeroing out the probabilities and recording the certainty with a 1.0 in the
2020 column, next to the CVE-2019-0001 row (see Table 6).

CVE Name | 2019 | 2020 | 2021 | 2022
---|---|---|---|---
CVE-2019-0001 | 0.0 | 1.0 | 0.00 | 0.0
CVE-2019-0002 | 1.0 | 0.0 | 0.0 | 0.0
CVE-2020-0001 | 0.0 | 0.94 | 0.05 | 0.03
CVE-2020-0002 | 0.0 | 1.0 | 0.0 | 0.0
CVE-2020-0003 | 0.0 | 0.94 | 0.05 | 0.03
CVE-2020-0004 | 0.0 | 1.0 | 0.0 | 0.0
Table 6. CVE-2019-0001 is published in mid 2020, and probabilities are
calculated.

To recalculate the probabilities now is relatively easy. We make a filter on
the table to only include rows that have 1.0 within them. This ensures we
don’t tabulate with vulnerabilities not yet published. For each column you
simply subtract the cve-string-year from the column name, which gives you the
year lag after publication. This is used as an index to build a vector of year
lags888Doing so for months is only slightly more complicated, involving many
more columns, but the method is the same.. So for this table alone that would
be: [3,1,0,0]999Once again the quantitative reader will already have figured
out we needed to include our assumed history and the vector is actually
[943,55,3,2,0]. Now simply sum the list and divide each element by the sum to
make a proportional list: [3/4,1/4,0/4,0/4]. This approximates Fig. 4 very
accurately with minimum effort and updates.

Figure 4. Kaplan-Meier Years.

Another way of viewing that same story is across the entire historic record,
see Fig 1. Such a view allows us to see very interesting historical context
such as the 2017 push to publish old vulnerabilities.

Figure 5. Kaplan-Meier Months.

It is important that when we view survival analysis over time in this way, we
check that the averages are consistent with the calendar years. In a
statistical sense we can formalise that with two sample Kolmogorov-Smirnoff
tests displayed in Fig 6. This diagram is made up of all the month lags from
each calendar year in our study. Note that the number of months to publication
can exceed that calendar year, but we are merely using the calendar year as a
filter on the assigned date, rather than on publication.

Figure 6. Kolmogorov-Smirnoff Distances in the histogram of month lags from
assignment to publication.

If we then view the years that have the furthest Kolmogorov-Smirnoff distances
from each other as Kaplan-Meier curves again (See Fig 7, we can clearly see
that a cumulative curve splits the difference of the years with the highest
distance from each other. This leads us to believe that using a cumulative
approach to publication time might serve us best, and keep our predictions
accurate.

Figure 7. Kaplan-Meier Months Variances.

This intuition is confirmed by viewing the Kolmogorv-Smirnoff distance graph
again using the cumulatively produced record and comparing it against calendar
years (See Fig 8.

Figure 8. Kolmogorov-Smirnoff Distances in the histogram of cumulative month
lags from assignment to publication..

This rather complex explanation verifies a simple result: by gathering the
cumulative publication duration, and we can use them as a probabilistic
estimate of publication date given assignment date. The cumulative record
gives us confidence we won’t be far from any individual year’s publication
delays, regardless of how many employees MITRE adds or how much more efficient
their process becomes. CNA specific analysis could of course be conducted, but
this result seems to suggest it wouldn’t make a more accurate forecast. Though
perhaps MITRE might like to use the same technique on each CNA to predict
their workload.

While this method is easy for managing the state transitions from assigned or
probable vulnerabilities to published vulnerabilities, it is quite slow when
applied to all vulnerabilities in the historical record (about 7 mins on a
standard laptop). Perhaps 7 minutes for a year’s prediction is not
unreasonable, but in practice it slowed down our retrocasting immensely.

Initially we assumed that it was important to examine all history, because
some vulnerabilities clearly come out 17 years later! However, a handful of
vulnerabilities is a very minor difference in MSLogE terms, which drove us to
discard larger and larger amounts of the history.

To calculate the number of vulnerabilities that are likely to be published
within a year we may take a matrix, $X$ of size $(N,M)$ where the number of
years $M=4$ since we have 3 years of history and the current year and N is the
number of inferred unpublished vulnerabilities, inferred from the highest CVE-
ID seen this year. $X$ is populated with the probability of being published in
year $m$ according to the probability vector described above such that the
total number of CVEs expected this year is $\sum{X(N,m)}$.

This MVUE indicator operates doesn’t respect calendar years, which is fine for
predicting how many CVEs have been assigned this year. We have seen how
knowing the number assigned can be scaled by probabilities of being published
within a given timeframe. Furthermore, at the very start of the year, it may
be that the few CVEs published have low ID numbers so that we underestimate
the initial prediction for the CVE-YEAR, which we verified in practice; the
worst MVUE predictions are in the first few weeks of January. To adapt this
estimator into a predictive model two modifications are used: (1) since yearly
predictions increase monotonically since the CVE-List began, we take the
maximum of the current CVE-projection and the previous years; thus mitigating
the issue of low scores at the start of the year. (2) in order to scale the
predictions relative to the time span in question (e.g. 6 months) the MVUE is
multiplied by the fraction of the year being used as the lookahead (Which is
produced by examining the historical record).

Yet once again, in practical experimentation; we found we could be even more
accurate and faster, which is detailed in the next model we constructed.

###  5.3. Little’s Law with LookBack

John Little’s theorem, known as Little’s Law, is used in queuing theory to
estimate the size of a servicing queue, $L$ from just two statistical metrics:
the arrival rate into the queue, $\lambda$, and the mean service time, $W$
such that $L=\lambda W$. Before a CVE is published, it is entered into the
MITRE database, this can be seen as the service time. Unlike the general use
of Little’s law, we are not interested in how many vulnerabilities are being
serviced but instead how many are going to be serviced in a given window. For
this we adopt a variation of Little’s Law to estimate the exit rate from the
queue $E$ using the probability that the service time is within the window of
interest $p(W\leq window)$. $\lambda$ gives the arrival rate to the queue
during the window but some items are already in the queue for the period we
are predicting and we can simply count these and use this constant, $q$ to
adjust the prediction such that $E=(q+\lambda)*p(W\leq window)$

$W$ is calculated from the time it takes to publish a CVE once entered into
the MITRE database.

The summary statistics for the entire NVD database (see Table 1) shows that at
the time of writing the median service time is 51 days and 16 hours but the
mean is 162 days implying that the data is skewed by some large outlier
values, as shown by the max of 6,632 days. Some CVEs created shortly after the
CVE programme was instigated in 2001 are still being published today and these
CVEs can skew both the estimation of service time and the $q$ constant, as
these CVEs are not necessarily being actively processed. For this reason we
set a ”lookback” limit on the Little’s Law adaptation model such that the
$p(W\leq window)$ is calculated within a pre-specificed window and $q$ only
represents items added to the queue within the previous lookahead window e.g.
if we are predicting how many CVEs will come out next year, we just look at
how many are still left in the queue from last year and do not include the
forgotten souls from the early 2000s.

##  6\. Accuracy and Comparison

This section outlines the results of our findings by applying these models.
For evaluation, predictive models are compared using retrocasting for the
period September 2018 to September 2020, making predictions every 10 days such
that there are 72 end dates (dates to predict total CVEs by) in the test set,
24 used for validation (January to September 2018) and between 36 and 547 for
training depending on the volume of historical data used.

###  6.1. Predicting total CVEs

To predict the total number of CVEs these experiments compare the models
detailed in the previous section and also experiment with using different
historical data: since 2005, since 2015 and since 2017 due to the large shifts
in in annual figures around these years (see Fig. 3).

for the machine learning models different input features are tested using
features produced by the statistical models. Two of the statistical models we
have developed use leading indicator data: CVE-IDs and entry/assigned dates
are used by MVUE and the Little’s Law with LookBack models respectively. We
fed the data used by these models into the machine learning models,
hypothesising that it will improve their predictions. Finally all data are
combined together with count data for four different intervals: 1 week, 1
month, 1 quarter and 1 year.

Retrocasting allows us to average models performance over time historically
and thus estimate how they might perform in the future. The lookahead windows
tested are 1 month, 1 quarter, 6 months, and 1 year.

Figure 9. 1 year predictions September 2018 - September 2020 using data since 2017 using Little LB features, with training data true values on the left Figure 10. Best model for retrocasting by feature set Model | MSlogE | Cutoffyear | featureset | lookahead
---|---|---|---|---
Bayes Ridge | 0.029326 | 2017 | littleLB | 1
rolling mean | 0.046733 | 2005 | count | 1
previous value | 0.051252 | 2005 | count | 1
Bayes Ridge | 0.010346 | 2017 | littleLB | 3
previous value | 0.025126 | 2017 | count | 3
rolling mean | 0.026234 | 2017 | count | 3
Random Forest (RF) | 0.007847 | 2017 | littleLB | 6
rolling mean | 0.017287 | 2017 | count | 6
previous value | 0.020160 | 2017 | count | 6
MVUE | 0.003493 | n/a | n/a | 12
previous value | 0.014736 | 2015 | count | 12
rolling mean | 0.016910 | 2015 | count | 12
Table 7. Models with lowest MSLogE predictions for lookaheads of 1, 3, 6 and
12 months compared with using the previous value or rolling mean for
prediction

Figure 9 shows a single retrocasting experiment to predict one year in advance
using training data since 2017 and Little’s Law Lookback features. To compare
all retrocasting experiments, the models with the lowest MSLogE scores have
been plotted by feature set (Figure 10) and by retrocasting cutoff year. These
are compared against the previous values and rolling mean predictions in Table
7. The MSlogE is significantly reduced using the models than by using the mean
or previous value.

Figure 11. Weekly, monthly, quarterly and annual total vulnerabilities January
2017 to October 2020 normalised between 0 and 1 shows greater variance as for
shorter time windows.

In each instance, the best model has decreasing MSlogE as the lookback window
increases. This is intuitive when we look at the variance in vulnerability
counts over time for one-month vs one year predictions, see Figure 11 shows
that by year we can see that there are exponential-looking reductions in error
over time using data since 2015 and 2017 for the best models. For 2001 and
2005 we see an increase in error for 6 month predictions.

Regarding features, Figure 10 shows that a cutoff year of 2017 for machine
learning training data gives the best predictions for all lookahead windows
and the Little LB output as a new data point gives the best models for 1, 3
and 6 month predictions using machine learning models despite having less
data; likely because the distribution of the training and test data is more
similar.

The lowest error is for a 12 month prediction uses the MVUE model. Taking the
mean for the testing period the predictions are within 3% of the true values.
For 6 months the best model is a Random Forest using Little LB features
(within 7% of true values), Naive Bayes with Little LB features is the best
model for 3 months (within 8%) and 1 month (within 12%) predictions. Please
note how fascinating and counter-intuitive it is in a forecasting sense, that
we are more accurate at longer lookahead windows. This is a bold and confusing
claim, and deserves more explanation.

Fig. 11 addresses this by showing the variance in different time units. It’s
clear visually that the volatility reduces when you look across years instead
of months or quarters. In short we are visualising the uncertainty of the $E$
term, the exit rate, of Little’s Law with Lookback. The deeper point we are
trying to make is that we were surprised, and that if you merely looked at a
partial auto correlation function of numbers across months, you might choose
only to try and predict a 3 month lookahead as correlation is insignificant
between months more than 3 months apart. That is a sort of false summit
because after you cross the uncertainty of 3-9 months, the yearly predictions
become useful and tractable. This is then compounded with our ability to use
the MVUE/CVE numbering as another anchor to reduce our uncertainty. A third
element increasing this accuracy is that Little’s Law uses a longer lookback
for a longer lookahead, and that too shows an increase of accuracy.

###  6.2. Predicting subgroups of CVEs

In practice, patch managers may want to know the forecasted total
vulnerabilities for a sense of the global trends but will also be interested
in the number of expected vulnerabilities for particular types of
vulnerabilities such as those relating to products used by their organisation
and supply chain; those vulnerabilities with a high CVSS score; those which
constitute network-based attacks etc. As mentioned earlier in the paper, the
vulnerabilities most likely to be exploited also represent a subcategory of
interest.

We adapted the above methodology for predicting all vulnerabilities to predict
sub-categories instead. The best ML algorithm is selected using a validation
set for which the selection criteria may be chosen by a patch manager. Here we
select the model with the lowest MSlogE on the validation set. Not all models
developed are appropriate for type forecasting - MVUE for example cannot use
the CVE-IDs to predict population subsets. In these experiments we use the
data-driven models with Little LB features since 2017 as these gave the best
performance across all lookahead prediction windows.

Figure 12. Forecast number of CVEs for top 5 vendors, products, vulnerability
types and for CVEs with a HIGH or CRITICAL CVSS retrocasting September 2018 -
September 2020 Figure 13. Mac OS X vulnerability forecasts one month ahead Sep
2018 to Sep 2020

Figure 12 gives the MSlogE for the forecasting number of CVEs for the most
common 5 products, vendors and vulnerability types seen in 2020 and for CVEs
with a HIGH or CRITICAL CVSS. We can see the mean squared error is decreasing
for most subtypes as the lookahead window increases. The one months prediction
for Mac OS X operating system vulnerabilities stands out as having a very high
MSlogE. Looking at the raw data reveals that per month the Mac OS X
vulnerability count is liable to jump between 0 and 150 regularly (see Figure
13).

Keeping this in mind, the patch manager may wish to keep a visualisation of
the variance of vulnerability numbers to hand as some products will fluctuate
wildly or begin to have CVEs for the first time.

##  7\. Will the future prove this forecast false?

One sensible validation of scientific endeavour is predictive power: if a
theory predicts with some accuracy things we did not know before, it validates
itself. In that spirit we provide a forecast on which you can judge this paper
over the next year; see Fig 14. To validate it, simply search the NVD
statistics 101010https://nvd.nist.gov/vuln/search with a date filter from the
year leading up to the Forecast date and time at the top of the image. The
number of CVEs published should be within one of the prediction interval bars,
and if they are not you can ask questions about how we failed to be as
predictive in that lookahead. We kindly ask that you remember that the
prediction accuracy we are most comfortable with is the yearly lookahead, and
we hope you won’t abandon us if our 3-6 month forecasts aren’t as useful. If
you are reading this after 2021, you will know how successful this single
forecast was, and can cite us when you make better forecasts, or improve our
methods.

If you’re a vulnerability hunter, maybe you can invalidate the graph by
finding more vulnerabilities than we expected, in which case we hope you’ll
cite us too. Regardless of the result, this is our effort be falsifiable and
transparent.

Figure 14. A forecast of the CVEs that will be published after this paper is
published.

##  8\. The Future of CVE Forecasting

In 2020 (when this paper was written) the Vulnerability Management Market is
estimated to be worth 12.5 Billion
dollars111111https://www.marketsandmarkets.com/Market-Reports/security-
vulnerability-management-market-204180861.html. It seems important that some
of that money and effort be spent to give network defenders more time to patch
and better specificity with respect to exploitation. To us, it seems that CVE
prediction and forecasting research increases that reaction window, and thus
better strategic cyber risk management decisions. Of course, one might argue
that companies could be more transparent about vulnerability disclosure in
general, and that would negate the research of vulnerability forecasting
entirely. That is a topic for a different paper, and different researchers.

As academic research in this field makes progress both on accuracy, and
extends the forecasts further into the future, it will become easier to
understand the frequency of CVEs. No doubt the art will move from
vulnerability forecasting to exploit forecasting. That challenge too has
already been met by many(Jacobs et al., 2019; Fang et al., 2020; Sabottke et
al., 2015; Chen et al., 2019), and others even showed how long we might
reasonably expect to wait to see an exploit written(Householder et al., 2020;
Chen, 2020). Allodi showed us insight into the distribution of exploitation by
CVE(Allodi, 2015) which could be used to weight estimated exploitation before
actual exploitation weights are recorded for risk purposes. Everywhere
uncertainty around vulnerabilities, exploits, and exploitation is reducing,
and cyber risk is maturing accordingly. We feel lucky to be a small part of
that story, by predicting the volumes of CVEs.

Research then will naturally turn towards discussion of severity with respect
to exploitation. When we say impact here, we do not mean in a CVSS machine
specific sense. We mean ’How much will it cost me if this vulnerability is
exploited in my organisation or one of my suppliers?’. This is a trickier
question to answer than it initially appears, and is often bound up in the
value of the assets and the business or organisation itself, more than
endogenous to the statistics of vulnerabilities. It is a story of market share
and computational value.

An exploit may be the mechanism of entry, but it is rarely used as a payload
to gain access and then do nothing at all. These leaves two difficult to
estimate problems, which essentially reduce to predictions or estimations in
their own right:

  1. (1)

”What does the hacker want or intend after using this CVE?” (Predict what the
payload will be).

  2. (2)

”How much value does any given computer or network of systems in our
organisation generate?” (Predict how much we will earn or lose with/without
this computer or network).

To illustrate: some hacks don’t drive a cost, and others do. If your credit
card details are stolen, then my gain is your loss in a zero sum sense.
However, some hacks produce non-zero sum economics. For example, if your
computer is compromised and used to send spam, you may not have been using
those process cycles or bandwidth. Let us be clear, this is not to excuse
computer crime, but rather to illustrate that estimating losses != gains for
many cyber criminal enterprises. Their utility function in an economic sense
is not always antithetical to ours, though it can be.

Solving those problems is more about economics of internet enabled business
models, than it is about the statistics of vulnerabilities. Even if we don’t
yet know what it will cost us, we are closer to understanding how many ways we
have to defend ourselves now that we can construct CVE forecasts in theory,
and in practice.

## References

  * (1)
  * Aleksić et al. (2014) Aleksandar Aleksić, Miladin Stefanović, Danijela Tadić, and Slavko Arsovski. 2014.  A fuzzy model for assessment of organization vulnerability.  _Measurement_ 51 (2014), 214 – 223.  https://doi.org/10.1016/j.measurement.2014.02.003
  * Alhazmi and Malaiya (2006) Omar H Alhazmi and Yashwant K Malaiya. 2006.  Prediction capabilities of vulnerability discovery models. In _RAMS’06. Annual Reliability and Maintainability Symposium, 2006._ IEEE, 86–91.
  * Allodi (2015) Luca Allodi. 2015\.  The heavy tails of vulnerability exploitation. In _International Symposium on Engineering Secure Software and Systems_. Springer, 133–148.
  * Brady et al. (1999) Robert M Brady, Ross J Anderson, and Robin C Ball. 1999\.  _Murphy’s law, the fitness of evolving species, and the limits of software reliability_.  Technical Report. University of Cambridge, Computer Laboratory.
  * Chatzipoulidis et al. (2015) Aristeidis Chatzipoulidis, Dimitrios Michalopoulos, and Ioannis Mavridis. 2015.  Information infrastructure risk prediction through platform vulnerability analysis.  _Journal of Systems and Software_ 106 (2015), 28–41.
  * Chen et al. (2019) Haipeng Chen, Rui Liu, Noseong Park, and VS Subrahmanian. 2019\.  Using twitter to predict when vulnerabilities will be exploited. In _Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining_. 3143–3152.
  * Chen (2020) Jay Chen. 2020.  The State of Exploit Development: 80% of Exploits Publish Faster than CVEs.  (August 2020).  Online [Accessed 13th Nov. 2020] https://unit42.paloaltonetworks.com/state-of-exploit-development/.
  * Fang et al. (2020) Yong Fang, Yongcheng Liu, Cheng Huang, and Liang Liu. 2020\.  FastEmbed: Predicting vulnerability exploitation possibility based on ensemble machine learning algorithm.  _Plos one_ 15, 2 (2020), e0228439.
  * Geer (2015) Dan Geer. 2015.  For good measure: The undiscovered.  _; login:: the magazine of USENIX & SAGE_ 40, 2 (2015), 50–52.
  * Householder et al. (2020) Allen D Householder, Jeff Chrabaszcz, Trent Novelly, David Warren, and Jonathan M Spring. 2020.  Historical Analysis of Exploit Availability Timelines. In _13th $\\{$USENIX$\\}$ Workshop on Cyber Security Experimentation and Test ($\\{$CSET$\\}$ 20)_.
  * Jacobs et al. (2019) Jay Jacobs, Sasha Romanosky, Benjamin Edwards, Michael Roytman, and Idris Adjerid. 2019\.  Exploit Prediction Scoring System (EPSS).  _arXiv preprint arXiv:1908.04856_ (2019).
  * Jardine (2018) Eric Jardine. 2018\.  Mind the denominator: towards a more effective measurement system for cybersecurity.  _Journal of Cyber Policy_ 3, 1 (2018), 116–139.  https://doi.org/10.1080/23738871.2018.1472288 arXiv:https://doi.org/10.1080/23738871.2018.1472288
  * Last (2016) David Last. 2016\.  Forecasting zero-day vulnerabilities. In _Proceedings of the 11th Annual Cyber and Information Security Research Conference_. 1–4.
  * NVD (2019) NVD. 2019.  CVE-2002-2444.  Online: https://nvd.nist.gov/vuln/detail/CVE-2002-2444 [Accessed 2020-10-21].
  * O’Donnell (2008) A. J. O’Donnell. 2008\.  When Malware Attacks (Anything but Windows).  _IEEE Security Privacy_ 6, 3 (2008), 68–70.
  * Ozment and Schechter (2006) Andy Ozment and Stuart E Schechter. 2006.  Milk or wine: does software security improve with age?. In _USENIX Security Symposium_ , Vol. 6.
  * Petersson et al. (2004) Håkan Petersson, Thomas Thelin, Per Runeson, and Claes Wohlin. 2004.  Capture–recapture in software inspections after 10 years research—-theory, evaluation and application.  _Journal of Systems and Software_ 72, 2 (2004), 249–264.
  * Pokhrel et al. (2017) Nawa Raj Pokhrel, Hansapani Rodrigo, Chris P Tsokos, et al. 2017\.  Cybersecurity: time series predictive modeling of vulnerabilities of desktop operating system using linear and non-linear approach.  _Journal of Information Security_ 8, 04 (2017), 362\.
  * Rescorla (2005) Eric Rescorla. 2005\.  Is finding security holes a good idea?  _IEEE Security & Privacy_ 3, 1 (2005), 14–19.
  * Sabottke et al. (2015) Carl Sabottke, Octavian Suciu, and Tudor Dumitras. 2015\.  Vulnerability Disclosure in the Age of Social Media: Exploiting Twitter for Predicting Real-World Exploits. In _24th USENIX Security Symposium (USENIX Security 15)_. USENIX Association, Washington, D.C., 1041–1056.  https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sabottke
  * Schuckert (2016) Felix Schuckert. 2016\.  PT: Generating security vulnerabilities in source code. In _Sicherheit 2016 - Sicherheit, Schutz und Zuverlässigkeit_ , Michael Meier, Delphine Reinhardt, and Steffen Wendzel (Eds.). Gesellschaft für Informatik e.V., Bonn, 177–182.
  * Scott and Wohlin (2008) Hanna Scott and Claes Wohlin. 2008.  Capture-recapture in software unit testing: a case study. In _Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement_. 32–40.
  * Vander Wiel and Votta (1993) Scott A Vander Wiel and Lawrence G. Votta. 1993.  Assessing software designs using capture-recapture methods.  _IEEE Transactions on Software Engineering_ 19, 11 (1993), 1045–1054.
  * Venter and Eloff (2004) HS Venter and Jan HP Eloff. 2004.  Vulnerability forecasting—a conceptual model.  _Computers & Security_ 23, 6 (2004), 489–497.
  * Wang et al. (2008) J. Wang, Z. He, J. Oh, and S. Park. 2008\.  Multi-Response Robust Optimization Using Desirability Function. In _2008 IEEE Symposium on Advanced Management of Information for Globalized Enterprises (AMIGE)_. 1–3.
  * Yasasin et al. (2020) Emrah Yasasin, Julian Prester, Gerit Wagner, and Guido Schryen. 2020.  Forecasting IT security vulnerabilities–An empirical analysis.  _Computers & Security_ 88 (2020), 101610.