### The Vulnerability Management Component
#### 3.4.2 Constructing Clone-Incurred Vulnerability Landscape  
The preceding sub-component extracts each vulnerability as a piece of vulnerable code, which is treated as a vulnerable code fragment. Given a set of vulnerabilities (i.e., vulnerable code fragments) obtained by the preceding sub-component, this sub-componentconstructs clone-incurred vulnerability landscape by identifying and annotating the nodes (representing code fragments) in clone landscape with the pertinent vulnerabilities. Ideally, the vulnerability information should be as detailed as possible, including what the affected programs and their versions are, what the patches are, and how they can be exploited. In practice, vulnerability information is often incomplete. For example, the requester may only be given the affected program versions.  
Given a set of vulnerabilities, which are vulnerable code fragments extracted by the preceding sub-component, we need to determine whether a code fragment corresponding to a node in the clone landscape is vulnerable or not. For this purpose, there can be many algorithms. For example, one can require that two code fragments are similar enough (i.e., they can be seen as clones of each other); another method is to require that the code fragment contains all of the statements of the vulnerable code fragment; a conservative method is to treat a code fragment as vulnerable if it contains any statement of the vulnerable code fragment. This leads to:  
**Definition 5** (clone-incurred vulnerability landscape).: _Given a clone landscape derived from programs \(P_{1},\ldots,P_{n}\) and a set of vulnerabilities that can be treated as vulnerable code fragments, the clone-incurred vulnerability landscape is defined as the annotated clone landscape, such that each node in the clone landscape, if deemed as vulnerable according to the given vulnerabilities, is annotated with the information of the pertinent vulnerability._  
In order to characterize clone-incurred vulnerability landscapes and their evolution, we propose defining the following metrics to characterize the dynamic situation of clone-incurred vulnerabilities via the landscape. Let \(V_{L}^{(i)}\) be the set of nodes in the clone landscape, which correspond to the code fragments belonging to program \(P_{i}\). Let \(V_{L^{\prime}}^{(i)}\subseteq V_{L}^{(i)}\) be the subset of nodes in the clone landscape, which correspond to the _vulnerable_ code fragments belonging to program \(P_{i}\). Recall that \(|P_{i}|\) is the number of LoCs of program \(P_{i}\) and that for a code fragment \(v\), \(|v|\) denotes its number of LoCs.  
* **Clone-incurred vulnerability surface**: This metric measures the fraction of code in a program that is cloned and vulnerable. Specifically, for a program \(P_{i}\), this metric describes the percentage of cloned LoCs in \(P_{i}\) where the clone is also vulnerable, namely \(\frac{\sum_{v\in V_{L}^{(i)}}|v|}{|P_{i}|}\).
* **Clone-incurred vulnerability prevalence**: This metric measures how prevalent clones are in a set of programs. Specifically, for a given vulnerable code fragment \(C\), this metric is defined as the number of clones of \(C\) in the programs \(P_{1},\ldots,P_{n}\).
* **Clone-incurred vulnerability lifetime**: This metric measures the lifecycle from a cloned vulnerable code fragment. Suppose that a given vulnerable code fragment \(C\) appeared in the given set of programs \(P_{1},\ldots,P_{2}\) at time \(t_{1}\) at the earliest and at time \(t_{2}\) at the latest. Then, the lifetime of vulnerable clone code fragment \(C\) with respect to \(P_{1},\ldots,P_{n}\) is defined as \(t_{2}-t_{1}\).  
Note that the _clone-incurred vulnerability lifetime_ metric is only applicable to TCG-based clone landscapes.