## 6 Discussion  
**Limitations of the CVMan Framework**. The framework has two limitations. First, we focused on managing clone-incurred vulnerabilities in programs with source code. This is applicable to the setting where the defender of an enterprise network uses open-source software or proprietary software developed by the enterprise. This is also applicable to vendors of proprietary software, such as Microsoft, who can leverage CVMan to manage clone-incurred vulnerabilities in the lifecycle of their software.  
Nevertheless, it would be interesting to extend the investigation to the following setting: The defender only has the binary code (and not the source code) of proprietary software (e.g., Windows) but may still be interested in managing the clone-incurred vulnerabilities in the binary code without having access to the source code. This is relevant because: (i) there are binary-code-based clone detectors [52; 53; 54], and (ii) some vulnerabilities are only disclosed with binary code information (i.e., no information about the vulnerable source code is given), for which a concrete example is CVE-2020-4345.  
A defender can use binary code-based clone detectors to extract clone pairs and construct an SCG and TCG to describe the clone landscape. Then, the defender can use an appropriate source-code-to-binary-code mapping method (when source patches are known) or can compare the binary file before applying a patch and the binary file obtained after applying a patch to locate and annotate vulnerable code fragments.  
Second, the vulnerability management component could be improved. This is because, when constructing a clone landscape, vulnerabilities are not considered. As a consequence, a code fragment that has one line of code that is similar to one line of code in a piece of vulnerable code is treated as vulnerable. However, whether the code fragment is indeed vulnerable needs to be further investigated. An alternate solution is to treat the code fragment that contains the lines of code removed by the patch as the vulnerable code fragment. However, this solution is conservative and could miss some vulnerable code fragments because vulnerable code fragments in different versions do not necessarily contain exactly the same lines of code removed by the patch.  
**Limitations of the Case Study**. We only applied TCG to Linux in Ubuntu. Despite that Ubuntu is complex software (i.e., millions of lines of code for each version) and that we considered eight versions of it, the case study may not be sufficiently representative. As a consequence, the insights drawn from the case study may not hold for other programs.  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline
**CVE** & **Program** & **Vulnerable Procedure** & \
\begin{tabular}{c} **Clone-Incurred** \\ **Vulnerability** \\ **Prevalence** \\ \end{tabular} &
\begin{tabular}{c} **Clone-Incurred** \\ **Vulnerability Lifetime** \\ \end{tabular} \\ \hline CVE-2019-15214 & Linux, Alsa-driver & _std\_card\_disconnect_ & 10 & 5 \\ CVE-2019-10638 & Linux & _ipro6\_select\_ident_ & 3 & 3 \\ CVE-2019-11487 & Linux & _buffer\_pipe\_buf\_get_ & 3 & 3 \\ CVE-2020-8648 & Linux & _paste\_selection_ & 5 & 5 \\ CVE-2020-9383 & Linux & _set\_fdc_ & 5 & 5 \\ CVE-2020-7053 & Linux & _context\_idr\_cleanup_ & 3 & 3 \\ CVE-2018-15471 & Linux & _xentif\_set\_hash\_mapping_ & 2 & 2 \\ CVE-2018-14625 & Linux & _\_vhost\_sock\_get_ & 2 & 2 \\ \hline \hline \end{tabular}
\end{table}
Table 3: Examples of clone-incurred vulnerabilities.