The discovery of a vulnerability within software is akin to ‘panning for gold’, as the vulnerability is already in existence, it is the technique, detail and expertise that uncovers the vulnerability that is key. Studies have claimed that a software vulnerability goes through a number of distinct phases, characterised as a vulnerability lifecycle (Clark et al., 2010; Frei et al., 2010).
Figure 2 – the lifecycle of a vulnerability Source: (Frei et al., 2010)
Moreover, phases are argued to be distinct periods of time whereby differing events occur, and sub-processes are triggered. This claim is substantiated by Shahzad et al., (2012) who states that key phases within the lifecycle are characterised by differing behaviours of actors within the VDDS. There is consensus among authors that the lifecycle always starts with a vulnerability or bug being introduced into the software, which, in some cases may lie dormant for years. In the case of three well-known vulnerabilities, ‘shellshock’, ‘Heartbleed’ and ‘goto fail’ all lay dormant and undiscovered for over 24 months. (Banks, 2015; Delamore and Ko, 2015; Larsson and Sigholm, 2016). This is important when the issue of vulnerabilities is framed in the context of discovery, but not disclosure, as a separate set of actions occur.
The second phase within the lifecycle is typically the discovery phase, whereby software that contains an undiscovered vulnerability is subjected to robust probing and testing (Klein, 2011, p.3). This undiscovered vulnerability is detected via specialised discovery tools. These tools range from bespoke applications used for software security testing such as SPIKE and peachfuzz, to general programming tools such as debuggers (Klein, 2011, pp.6–8; Sutton et al., 2007, p.351). Vulnerability discovery tools are difficult to operate as they are generally designed to be utilised by highly skilled discoverers and software developers. However, the complexity of these tools has been shown to be reducing over time which may in part allows allowed potentially new entrants to the discovery system to influence the discovery of vulnerabilities. (Klein, 2011, p.181).
Once initial discovery phases have occurred, there is considerable disagreement as to which phase in the lifecycle follows, as can be shown in table 2 below. Frei (2013a) argues that the next step in the lifecycle of a vulnerability is that of exploitation, where measured time between discovery, exploit and patch is a factor. The assumption here is that that discovery of the vulnerability is via a malicious actor, driven to cause harm. Whilst this is appropriate, Frei (2013a) fails to consider the discovery of vulnerabilities by so called ‘white hat’ researchers, and internal discovery teams within the software vendor, which are deemed out of scope. In contrast to Frei, Ruohonen et al., (2016) hypothesises a seven step process which changes the sequence of events, placing disclosure directly after discovery. According to Ruohonen et al., (2016) this modification makes the assumption that the vulnerability is disclosed to a vendor, prior to any malicious exploit development. The main difference between suggested models is the sequence of events between patch, exploit creation and disclosure, however not consider the different modes of disclosure (Arbaugh et al., 2000; Cavusoglu et al., 2007; Li and Rao, 2007; Marconato et al., 2012; Ozment, 2007; Radianti et al., 2007a, 2009; Sood, 2009). In the study presented by Ozment (2007) there is the notable exception to this as a stated model includes the ‘injection’ of the vulnerability into the software prior to release. This injection phase is assumed to be within the software development
lifecycle, however this is not made clear. Within all these studies is the tacit assumption that the vulnerabilities that are discovered and result in a disclosure, and that the process is a smooth progression. However, no consideration is given to the time taken to navigate all the stages within the VDDS, and no studies have made efforts to measure the time that is taken between a vulnerability entering and ultimate exit of the VDDS.
Study Vulnerability Lifecycle Sequence Number of Phases
Type of Model
(Frei, 2013a; Frei et al., 2010)
Creation, Discovery, Exploit, Disclosure, Vendor Patch, Patch Installation.
6 Linear
(Ruohonen et al., 2016)
Birth, Discovery, Disclosure, Patching, Publication, Exploit Dev, Death
7 Linear
(Arbaugh et al., 2000) Birth, Discovery, Disclosure, Correction, Publicity, Scripting, Death. 7 Linear (Cavusoglu et al.,
2007)
Introduction, Identification, Vendor Patch, {3rd
Party Coordination, Vendor Patch}
4 (optional 2)
Linear
(Li et al., 2007) Release, Discovery, Exploit, Vendor Patch, End 5 Linear (Marconato et al.,
2012)
Discovery, Disclosure, Patch, Exploit 4 Linear
(Sood, 2009) Discovered, Made Public, Known to vendor, Vendor Notification, Security tool updates, Vendor Patch, Patch Known, Patch Install
8 Linear
(Ozment, 2007) Injection, Release, Discovery, Disclosure, Public, Patch, Scripting 7 Linear (Radianti et al.,
2007b, 2009)
Creation, Discovery, Disclosure, Black Market Trade, Exploit, Patch 6 Network
(Takanen et al., 2004) Discovery/Reaction, Correction, Disclosure, Nullification 4 Network (Okhravi and Nicol,
2008)
Introduction, Discovery, Exploitation, Disclosure, Public Exploit, Patch, Patch Test, Patch Deploy
8 Linear
(Okamura et al., 2009) Birth, Discovery, Disclosure, Correction, Publicity, Scripting, Death 7 Network
A further area of disagreement within the literature is centred around the disclosure phases within the lifecycle. All studies consider the disclosure phases as important, yet all identified different paths the vulnerability may follow the VDDS (Arbaugh et al., 2000; Concas et al., 2007; Frei, 2013a; Radianti et al., 2007a; Sood, 2009). The final phases of the lifecycle are centred around the installation of vendor patch, effectively removing the vulnerability from the software (Cavusoglu et al., 2007; Frei, 2013a; Radianti et al., 2007a; Sood, 2009). A detailed analysis of the disclosure phase is discussed below. All suggested vulnerability lifecycle models are subjective as they describe the journey which an individual vulnerability undergoes from a narrow point of view. The assertions from studies lends itself to a network of potential bifurcation of paths through the VDDS, each with hypothesised incentives, ethical choices, influences and timescales attached.
There is general agreement that the process a vulnerability follows is linear, progressing from creation and discovery to the eventual remediation of the issue. However, both Radianti et al. (2009) and Takanen et al. (2004) describe the differing entities and roles that are played within the VDDS and argue that the process is not linear in nature, that the lifecycle a vulnerability may contain loops, complex information flows (hidden of otherwise), and time delays.
Whilst the nature of the vulnerability discovery and disclosure system appears to differ considerably between authors, this could be due to the narrow research question that is being tackled. All studies, again with the notable exception of Ozment (2007) deal with ‘zero-day’ vulnerabilities as they are the highest impact, however other classes of vulnerabilities exist. So, called ‘one-day’ vulnerabilities which are vulnerabilities that are known about publicly, yet not patched are still critically important due to the impact of them (Ozment, 2007, p.87).