V0Finder: Discovering the Correct Origin of Publicly Reported

Software Vulnerabilities

Seunghoon Woo† , Dongwook Lee† , Sunghan Park† , Heejo Lee†∗ , Sven Dietrich‡
† Korea University, {seunghoonwoo, dongwook2014, sunghan-park, heejo}@[Link]
‡ City University of New York, spock@[Link]

Abstract such as the National Vulnerability Database (NVD) [39] in

Common Vulnerabilities and Exposures (CVEs) are used to the form of Common Vulnerabilities and Exposures (CVE).
ensure confidence among developers, to share information Despite such collective efforts, mistakes can cause a trans-
about software vulnerabilities, and to provide a baseline for fer of a vulnerability from one software to another without any
security measures. Therefore, the correctness of CVE reports interruption, as the quality and correctness of these vulnera-
is crucial for detecting and patching software vulnerabilities. bility reports are not guaranteed. Therefore, quality control of
In this paper, we introduce the concept of “Vulnerability public vulnerability reports has become a major research in-
Zero” (VZ), the software where a vulnerability first originated. terest in software security [2, 5, 8, 34, 36]. Of the many pieces
We then present V0Finder, a precise mechanism for discov- of information in the public vulnerability report, we paid par-
ering the VZ of a vulnerability, including software name ticular attention to the origin of the vulnerable software where
and its version. V0Finder utilizes code-based analysis to the vulnerability is coming from. We coin this origin of vul-
identify reuse relations, which specify the direction of vulner- nerable software as Vulnerability Zero (VZ), a reference to
ability propagation, among vulnerable software. V0Finder the medical term patient zero (or primary case) [56].
constructs a graph from all the identified directions and traces One of the main problems with current vulnerability reports
backward to the root of that graph to find the VZ. is the lack of verifying the correctness of VZ information. A
We applied V0Finder to 5,671 CVE vulnerabilities col- third-party OSS vulnerability in a software program is occa-
lected from the National Vulnerability Database (NVD) and sionally reported as the entire program’s vulnerability. Such
popular Bugzilla-based projects. V0Finder discovered VZs reports with the incorrect VZ lead other developers, who
with high accuracy of 98% precision and 95% recall. Further- reuse the vulnerable third-party software, to unintentionally
more, V0Finder identified 96 CVEs with incorrect informa- overlook the propagated vulnerabilities within their software,
tion related to their respective VZs. We confirmed that the causing transfer of the vulnerability to other software, and de-
incorrect VZ causes prolonged patch updates of vulnerable laying patch deployment. Thus, without proper verification of
software; the patch update of CVEs with the incorrect VZ VZ correctness in CVEs, incorrect VZs may create confusion
information takes 2 years, while the patch update of CVEs and hinder the core objective of the CVE.
with the correct VZ takes less than a year on average. Such in- In other research fields, e.g., medical [57] and malicious
correctly identified VZ hinders the objective of the CVE and software [15, 19], the importance of discovering a primary
causes confusion rather than “ensuring confidence” among case has already been introduced. To the best of our knowl-
developers. Our analysis shows that V0Finder can enhance edge, however, no existing approaches have attempted to dis-
the credibility of information provided by the CVEs. cover the VZ of a software vulnerability and further to reveal
its importance. Recent studies can be classified into three
categories: (1) identifying missing information in the report
1 Introduction
to efficiently mitigate vulnerabilities [2,3,5,36], (2) analyzing
The growing number of software made it possible for develop- the reproducibility of vulnerabilities [14,34], and (3) ensuring
ers to share their code with one another in the form of a public consistency between the vulnerability description and the af-
library and open-source software (OSS). This code-sharing fected software information [8]. However, if those studies are
culture provides high productivity, yet causes the transfer of based on public vulnerability reports with an incorrect VZ,
vulnerable code [18, 26, 58]. To mitigate this issue, informa- the credibility of their results can be challenged.
tion about known vulnerabilities is shared through channels Although a VZ literally means the vulnerable software
*Heejo Lee is the corresponding author. with the earliest birth date, a method that solely relies on the
timestamp metadata can often fail to discover the VZ; this is with the Common Platform Enumeration (CPE) [40], which
because the reliability of the timestamp metadata is not always specifies the software affected by each CVE. As a result,
guaranteed. Since software code can be modified after its V0Finder discovered VZs with 98% precision and 95% re-
release, we cannot always determine that the earliest-released call for the collected CVEs (see Section 5.1).
software among the vulnerable software is the VZ. Moreover, Further analysis demonstrates the importance and need for
a code-generation time could be changed due to operations VZ discovery. From the experiment, we found that the public
such as copying and pasting of source files [51]. Thus, this reports of 96 CVEs (1.7%) provided the incorrect VZ infor-
approach yields considerable false alarms (see Section 5.2). mation. It is worth noting that they are rarely patched once
To overcome such shortcomings, we propose a novel mech- these vulnerabilities are propagated; 64% of the latest version
anism called V0Finder (Vulnerability Zero Finder), to pre- of software affected by the 96 CVEs still contain the propa-
cisely discover a VZ assisting in detecting and patching soft- gated CVE, whereas the ratio is much lower (15%) for CVEs
ware vulnerabilities. To discover a VZ precisely, we face with the correct VZ information. To make matters worse,
two main technical challenges: (1) addressing syntax-variety many popular software programs have been released with
of a vulnerable code and (2) selecting proper features that unpatched vulnerabilities due to the incorrect VZ information
can be utilized to discover a VZ in the large-scale software (see Section 6.1). Even if developers succeeded in detecting
pool. The syntax of a vulnerable code introduced in the VZ the CVE’s vulnerability in their programs, the elapsed time
could be modified when it propagates to other software or for patching doubled in the case of the CVE with the incorrect
when the VZ is updated to a newer version. Hence, we need VZ information, compared to the case with the correct VZ
a technique to discover the VZ while being aware of the va- information (see Section 6.2).
riety of vulnerable code. Furthermore, among the software
This paper makes the following three main contributions:
containing vulnerable codes with various syntax, we need to
select proper features that can pinpoint the correct VZ; as • We coin the term VZ, which represents the software and
mentioned earlier, timestamp metadata alone is insufficient. its version where the vulnerability originated, and show
the importance of VZ discovery for the first time.
Our approach. To discover a VZ, V0Finder (1) detects a
set of vulnerable software that contains a particular vulnerabil- • We present V0Finder, a precise mechanism to discover
ity, (2) identifies propagation directions of this vulnerability the VZ using a vulnerability propagation graph. It is
among the vulnerable software, and then (3) determines the shown that V0Finder provides high accuracy with 98%
VZ of the vulnerability by backtracing propagation directions. precision and 95% recall.
First, for detecting vulnerable software, V0Finder uses • From the 96 CVEs with the incorrect VZ information
function-level vulnerable-clone detection for best accuracy discovered by V0Finder, we show a significant impact
and speed [26,58]. To address the syntax-modified vulnerable of the incorrect VZ information on the affected software
clones, we utilize Locality Sensitive Hashing (LSH) [12, 41] programs including the delay of patch updates.
and the patch code of the vulnerability (see Section 3.1).
Next, V0Finder identifies propagation direction of the vul-
nerability among the detected vulnerable software. In partic- 2 Motivation
ular, we pay attention to the reuse relation between the two
In this section, we clarify the terminology used in this paper,
vulnerable software, because the reuse relation can be used
and then discuss the motivation for VZ discovery.
to indicate the vulnerability propagation directions: when S
is reused in S0 and they share the same vulnerable code, we
2.1 Basic terminology
can infer that the vulnerable code was propagated from S
to S0 (i.e., S → S0 ). Thus, V0Finder performs a code-based Software. We consider software as a source code-level project
analysis between the two vulnerable software to identify a (rather than binaries) that contains source files and functions
reuse relation, more specifically, factors used for code-based because our mechanism is based on the source code com-
analysis include (1) source code of the software, (2) location parison. Furthermore, we only focus on the software that is
of the source code, and (3) metadata files (see Section 3.2). publicly managed by hosting services (e.g., GitHub).
Accordingly, V0Finder constructs a vulnerability propaga-
Vulnerable code. We define vulnerable code to be source
tion graph, where nodes indicate the vulnerable software and
code causing a vulnerability that has not been fixed, i.e., un-
edges represent the propagation directions. Then V0Finder
patched. If a copy of vulnerable code exists in a particular
discovers the VZ by finding the root of the constructed graph.
software program, the software is defined as vulnerable irre-
Evaluation and observations. We collected 5,671 CVEs spective of the exploitability of the copied vulnerable code.
from the NVD and popular Bugzilla-based projects, including We then define vulnerability propagation to occur when vul-
all the C/C++ related CVEs that released patches via Git. For nerable code in a software program (S) propagates to another
each CVE, we compared the VZ discovered by V0Finder software (S0 ) via software forks or OSS reuse.
 * Software name (indegree, outdegree)
the VZ of a vulnerability was provided correctly (see Section
*Android (1, 0)
7). For instance, Dong et al. [8] identified the inconsistency
MixedRealityToolkit
(2, 0) LibGDX Minko (1, 0) between the CVE description and the CPE [40], which speci-
(1, 1) fies a set of software affected by the CVE, but did not consider
zxing (1, 2) JPEG-compressor (0, 11) the possibility of the CPE containing an incorrect VZ.
Moreover, a method to scan vulnerabilities using static or
node-dv Renderdoc (1, 0)
(2, 0) dynamic tools (e.g., fuzzing tools) cannot be a fundamental
Xenia
(2, 0) vogl (1, 0) solution to the presented problem. As such method focuses
crunch rbfx Godot
(1, 2) (2, 0) (1, 0) only on the internal vulnerabilities of a particular software,
to resolve the problem caused by incorrect VZ, it should be
Figure 1: Illustration of the vulnerability propagation graph applied repeatedly to all affected software programs. Instead
for CVE-2017-0700. of such an inefficient solution, we need a one-stop solution
that can detect the correct VZ for a vulnerability and notify
Vulnerability propagation graph. Since V0Finder discov- all the affected software programs of the vulnerability once.
ers a VZ using the vulnerability propagation direction, we Technical challenges. Discovering a VZ is not a simple task
need a data structure that is able to show direction. In addition, mainly due to the following two technical challenges: (1)
as the propagation direction is one-way, there should be no addressing syntax-variety of vulnerable code and (2) selecting
cycle. Therefore, we derive a vulnerability propagation graph proper features for discovering a VZ.
by leveraging a directed acyclic graph-based structure: First, the syntax of a vulnerable code frequently changes
• A vulnerability propagation graph (G) is a directed while the software that contains the code is updated or
acyclic graph, and is represented as G = (V , E), where when the code is reused in other software. When discov-
V denotes a set of nodes (i.e., vulnerable software) with ering a VZ, we should be aware that such a vulnerable
indegree and outdegree labels for each vertex. For v ∈ V , code with various syntax exists in various software. Sev-
the indegree of v is denoted as IN, and its outdegree is eral vulnerable-code clone detection approaches can cope
denoted as OUT. E denotes a set of edges (E ⊆ V × V ) with syntax-changes [26, 58], but we cannot say that their
and shows the vulnerability propagation directions. techniques are still effective for VZ discovery.
Second, we need proper features to determine a vulnerable
Vulnerability Zero (VZ). VZ refers to the software and its software as VZ. It is easy to assume that vulnerable software
version where a vulnerability originated. Note that a VZ is with the earliest birth date is the VZ. However, in practice, the
not the software that first detected or reported the vulnera- source code of software may change after its release, and fur-
bility. Specifically, the VZ is regarded as the beginning of ther, a code-generation time can also be changed easily owing
vulnerability propagation, and thus, the root of a vulnerability to operations such as copying and pasting [51]; this approach
propagation graph is the VZ. often fails to discover the correct VZ (see Section 5.2). We
need a method to discover VZ through a more appropriate
2.2 Problem statement feature than mere timestamp metadata.

In this paper, we focus on the problem that occurs when the

index case (i.e., the first case discovered, and possibly be-
2.3 A motivating example
lieved to be the source) and the primary case (i.e., the actual We introduce the CVE-2017-0700 case, a remote code execu-
source) of a vulnerability are different. Let S be a software tion vulnerability reported by Android (see Listing 1), where
program and L be a third-party library, which is embedded in the vulnerability originated in the JPEG-compressor1 source
S. If a vulnerability is detected in L, it should be considered code (i.e., “[Link]” file), and not in the actual Android code
the vulnerability in L (i.e., VZ). However, this vulnerability (see Listing 3). The vulnerability propagation graph for CVE-
is occasionally reported as that of in P. For such case, the vul- 2017-0700 is illustrated in Figure 1.
nerability that is fixed in P is usually not reported upstream L.
Consequently, L not only remains unpatched, but also over- Listing 1: The description of CVE-2017-0700.
looked by developers of software, which is embedding L, A remote code execution vulnerability in the Android
furthering vulnerability propagation and hindering prompt system ui. Product: Android. Versions: 7.1.1, 7.1.2.
detection and patches for the vulnerability. Android ID: A-35639138.
The correctness of the VZ is important to software devel- Listing 2: The CPE of CVE-2017-0700.
opers, as many parts of the vulnerability management process cpe:2.3:o:google:android:7.1.1:*:*:*:*:*:*:*
still rely on public vulnerability reports [1, 54]. However, the cpe:2.3:o:google:android:7.1.2:*:*:*:*:*:*:*
interests of existing approaches are far from this issue. In-
1 [Link]
stead, they attempt to solve other problems by assuming that
 a CVE
Listing 3: A patch snippet for CVE-2017-0700. CVE
pool V P1. Node Vulnerable
1 --- a/gdx/jni/gdx2d/[Link] software programs
Software Discovery
2 +++ b/gdx/jni/gdx2d/[Link] pool
3 @@ -2282,3 +2304,4 @@void jpeg_decoder::
make_huff_table(int index, huff_tables *pH){.. VZ of the CVE (V)
P3. Root Vulnerability P2. Edge
propagation graph
4 for (l = 1 << (8 - code_size); l > 0; l--){ Finding Connection
5 - JPGD_ASSERT(i < 256);
6 + JPGD_ASSERT(i < JPGD_HUFF_CODE_SIZE_MAX_LENGTH); Figure 2: High-level workflow of V0Finder.
7 + JPGD_ASSERT(code < JPGD_HUFF_CODE_SIZE_MAX_LENGTH);

The software programs affected by this vulnerability can vulnerable software programs. When Si‡ is reused in S‡j , the
be classified into the following two groups: relation between them is expressed as follows:
(1) Software reusing Android: Because the vulnerability Si‡ ≺ S‡j (Si‡ is reused in S‡j )
was reported by Android, software programs that reused the
The identified reuse relations that exist between vulnerable
specified Android 7.1.1 or 7.1.2, or distributions of those An-
software pairs are expressed as follows:
droid versions, can easily resolve the vulnerability, e.g., up-
dating Android to the later version. P2 ({S1‡ , S2‡ , ..., Sm
‡ }) = {(S‡ ≺ S‡ ), (S‡ ≺ S‡ ), ...}
1 2 1 3
(2) Software reusing only JPEG-compressor: Software Using this information, V0Finder constructs the vulnerabil-
programs belonging to this group are not only uninterested in ity propagation graph for V , which is the output of P2. Here,
this vulnerability reported by Android but also barely attempt the propagation paths are reverse directions of the reuse rela-
to determine whether their codebase is affected by the vulner- tions; this is because, if Si‡ is reused in S‡j (Si‡ ≺ S‡j ), then the
ability. Thus, most of these software programs fail to detect
vulnerability has propagated from Si‡ to S‡j (Si‡ → S‡j ).
and patch the vulnerability in a timely manner.
Finally, in P3, V0Finder discovers the VZ of V by finding
Surprisingly, all of the software shown in Figure 1, except the root of the constructed graph.
Android, contained the vulnerable code up to their latest ver-
sion. We succeeded in reproducing this vulnerability in the 3.1 Node discovery phase (P1)
latest versions of three popular software by using a crafted im-
age file as an input: JPEG-compressor, Godot2 and LibGDX3 . Given a vulnerability patch as input, V0Finder reconstructs
In other software, the failure to the reproduction was due to a the vulnerable functions, and further detects vulnerable soft-
compilation error and failure to call vulnerable functions. As ware using the vulnerable-clone detection technique. The
soon as we reported this vulnerability, Godot and LibGDX detected vulnerable software programs become nodes in the
patched it (July 2019); JPEG-compressor, which has not been vulnerability propagation graph.
developed any further in recent years, did not respond yet. Vulnerable-clone detection. For efficient VZ discovery, we
value the following three factors in vulnerable-clone detec-
3 Methodology of V0Finder tion: robustness to syntax-modified clones, accuracy, and scal-
ability. As the syntax of a vulnerable code introduced in a
In this section, we describe the methodology of V0Finder. VZ can be modified when it propagates to other software,
The high-level workflow of V0Finder is depicted in Figure 2. our vulnerable-clone detection scheme must be robust to the
V0Finder discovers the VZ by means of finding the root variable syntax. In fact, detecting vulnerable clones is not
of a vulnerability propagation graph (see Section 2.1). Sub- the core idea of this paper, and many relevant studies have
sequently, V0Finder comprises the following three phases: already been conducted [18, 26, 30, 31, 42, 58]. Each of them
node discovery phase (P1), edge connection phase (P2), and has distinct advantages and disadvantages, e.g., VUDDY [26]
root finding phase (P3). is scalable yet barely detects vulnerable clones with modified
Let V be a set of vulnerable functions for a given CVE. syntax, while MVP [58] detects syntax-modified clones well,
In P1, V0Finder detects vulnerable software that contains a but it is less scalable than other approaches.
clone of V by using a vulnerable-clone detection technique. Therefore, we decided to incorporate techniques special-
Let D represent the software dataset, Si indicate a software ized for VZ discovery while leveraging the advantages of
program in D, and “‡” denote the software is vulnerable. Then existing vulnerable-clone detection techniques as follows:
the output of P1 is represented as follows: • Referenced features from existing techniques:
P1 (V , D) = {S1‡ , S2‡ , ..., ‡}
Sm → Function-level granularity [26, 58];
→ Text-preprocessing [18, 26, 58];
In P2, for the given set of vulnerable software programs, → Function hashing [18, 26, 58].
V0Finder identifies reuse relations between every pair of • Features specific to V0Finder:
2 [Link] + Using Locality Sensitive Hashing (LSH) [12, 41];
3 [Link] + Detection mechanism for syntax-modified clones.
 Since we selected function-level granularity as the basis, 3) No clone: If Φ is greater than θ, it means that fs is not a
a software program and a CVE can be represented as a set clone of fv .
of functions. Note that a patch for a vulnerability usually
consists of several code block changes [29], meaning there To determine whether a modified clone is vulnerable, we
can be multiple vulnerable functions causing a vulnerability. utilize the vulnerability patch of V from the CVE. A patch
Using function-level granularity, the scale of comparison be- consists of a set of deleted codes (e.g., line 5 in Listing 3),
tween entire software and vulnerability can be reduced to the which might be seen as vulnerable code, and a set of newly
comparison between a pair of functions set, which improves inserted codes (e.g., line 6 and 7 in Listing 3). If fs is the mod-
comparison performance and scalability [26, 48, 58]. ified clone of fv , and if all the deleted codes of the patch are
contained in the preprocessed fs without any of the inserted
Software and CVE pools. A software pool comprises a set codes, we conclude that fs is a vulnerable clone of fv .
of software source code, which becomes a search area for
By applying these two steps to all the CVEs in the CVE
vulnerable-clone detection and contains the source code of all
pool, we can discover a set of vulnerable s j containing vul-
versions for each software program. The CVE pool contains
nerable clones of V . Consequently, a software (Si ) becomes
a set of vulnerable codes and pieces of patch information as
the node of the vulnerability propagation graph for V when at
the source code form (details are explained in Section 4.1).
least one version (s j ) contains the vulnerable clone of V .
Detecting vulnerable software programs. Let s j denote the
version j of Si . We define s j as vulnerable when it contains a
3.2 Edge connection phase
vulnerable clone from a set of vulnerable functions V , and this
is determined by performing preprocessing and comparison. In this phase, V0Finder identifies vulnerability propagation
directions among the detected vulnerable software.
Step 1. Preprocessing: Considering the syntax variety of
As we discussed in Section 2.2, the method of tracking
vulnerable clones, we apply the following two preprocessing
VZ by relying solely on the timestamp metadata is prone to
tasks to all the functions in the software and CVE pools: text-
false alarms. Therefore, rather than relying on such times-
preprocessing and LSH [12, 41]. During text-preprocessing,
tamp metadata, we focused on a relation between the two
the code part that maintains function semantics even upon
vulnerable software. More specifically, V0Finder identifies
introducing changes, such as spaces, newline characters, and
reuse relations between every vulnerable software pair. We
comments, was removed from each function, and all the char-
represent the relation in which Si is reused in S j as Si ≺ S j .
acters in the function were converted to lower cases [26, 58].
We particularly paid attention to the reuse relation as it can
We then apply LSH to all text-preprocessed functions, which
indicate the vulnerability propagation direction. If Si is reused
generates similar hashes for similar inputs and returns a low
in S j and they share the same vulnerable code, then we can
distance value when the two input hashes are similar [27, 41].
infer that the vulnerable code has propagated from Si to S j ,
Unlike previous approaches, which store only the hash values,
expressed as Si → S j . Hence, the oldest ancestor-software of
we store the preprocessed string value of each function, which
the vulnerability propagation, i.e., the starting point of the
will be utilized to detect syntax-modified vulnerable clones.
propagation, becomes the VZ of the vulnerability.
Step 2. Comparison: We then compare all the hashed func- If the dependency information is provided, e.g., node pack-
tions of s j and those of V by employing the comparison age manager in JavaScript [38], we can simply parse and
method provided by LSH [28]. As a result, we can obtain utilize the dependency information to identify reuse relations
the distance (Φ) of all function pairs between s j and V ; this (e.g., GitHub dependency graph [13]). However, some other
distance shows the syntactic difference between the source languages such as C, do not provide any dependency informa-
code of the two functions. Furthermore, LSH configures a tion. Therefore, we devise a method to identify reuse relations
cut-off value (θ) [28], and the two inputs are similar if the Φ without relying on the given dependency information.
is less than or equal to θ. Let fs be a function in s j and fv be Modified software reuse. V0Finder identifies reuse rela-
a function in V . tions between the two vulnerable software by employing
code-based analysis. However, in the case of Si ≺ S j , the code-
1) Exact clone: If Φ is zero (i.e., the syntax of both func-
base of S j may not be reused as it is. We thus define the two
tions is exactly the same), this indicates that fs is the
modification patterns that can arise from software reuse to ef-
unpatched vulnerable clone of fv .
ficiently identify reuse relations: (1) code modification refers
2) Modified clone: If Φ is obtained as a value between zero to that Si is reused in S j with source code changes or when
and θ (0 < Φ ≤ θ), this indicates that fs is the modified only part of the codebase is reused; (2) structure modification
clone of fv . However, since the modification could be a refers to that Si is reused in S j with structural changes, specifi-
patch for a vulnerability, an additional verification step cally, name (e.g., file and function name changes) and location
must be performed. changes (e.g., reused in a different directory) of reused code.
Key factors. Considering modified software reuse, we select IN: 0 IN: 0
IN: 0
OUT: 0
OUT: 2 OUT: 1
three key factors utilized in reuse relation identification: (1)
source code of the software, (2) location of the source code, IN: 0
OUT: 1

and (3) a set of metadata files. (a) A single root (b) Two or more roots (c) No root
The source code of the software is used to identify reuse
relations without code modification; specifically, V0Finder Figure 3: Depiction for the three root cases.
measures shared code (i.e., common functions) ratio between
identify the reuse relation. Specifically, README, LICENSE,
two software. To identify a case in which software is reused
and COPYING files defined as metadata files, and the software
with code modification, we use the location of the source code
reuse relation is identified based on whether these three meta-
(i.e., file paths) in the reused code. Finally, when the code
data files are cloned into other software (refer to [16, 24]).
and structure are simultaneously modified while being reused,
we utilize the metadata files to identify reuse relations, which 1. V0Finder first traverses the files in sv and s0v and extracts
should be reused without modifications, e.g., license files. all metadata files with their path information.
When V0Finder identifies the reuse relation, it compares 2. V0Finder then checks whether each software has a
all vulnerable version pairs between the two vulnerable soft- metadata file in the root-source directory, and if it does,
ware; if any reuse relation between the two versions is identi- checks that the other software has exactly the same files
fied, we conclude that the reuse relation exists between the in the other directory except for the root directory.
two software. Let sv and s0v denote the vulnerable versions of
Si and Si0 , respectively. We introduce how to identify the reuse When comparing two metadata files, the entire content of
relation between sv and s0v by using the three key features. each file is compared using string comparison. In addition,
we determine whether a metadata file in the root directory of
Shared code ratio-based identification. We define two no- a particular software is its own metadata file; therefore, if the
tations, α and β for measuring the ratio of the shared code own metadata file of s0v is cloned to sv , then we can infer that
from the perspectives of sv and s0v , respectively: sv reuses s0v (i.e., s0v ≺ sv and s0v → sv ).
|sv ∩ s0v | |sv ∩ s0v | Tiebreaking. In both shared code ratio-based and metadata
α= and β =
|sv | |s0v | file-based identifications, s0v ≺ sv and sv ≺ s0v relations cannot
Here, |sv ∩ s0v | denotes the number of common functions be- be satisfied at the same time; however, this case can appear in
tween sv and s0v . Because α and β are a feature in identify- source code location-based identification. Thus, we establish
ing reuse relations without code modification, the number of the tiebreaking rule: if the paths of a common function of sv
hashed functions that are exactly the same between sv and s0v and s0v are exactly the same, the reused relation is not estimated
is measured to obtain |sv ∩ s0v |. If sv reuses s0v without code and no edge is constructed between them.
modification, the entire codebase of s0v should be contained in We assume that the software reuse follows the general
the sv . Therefore, V0Finder determines that sv is reusing s0v code reuse convention. In particular, metadata files are data
when α < 1.0 and β = 1.0 (i.e., s0v ≺ sv and s0v → sv ). containing copyrights of the original software and must be
specified when reused the software. If this code reuse conven-
Source code location-based identification. The original tion is not followed, it is currently out of the V0Finder scope
code path of s0v is included in the path of the reused code (these cases hardly appeared in experimental observations);
in sv when sv is reusing s0v without any structural modification. covering even anomalous code reuse is left as a future work.
V0Finder compares both file paths of the common functions Upon connecting all the nodes where the reuse relation ex-
between the two software by string comparison to determine ists, a vulnerability propagation graph is constructed for each
which one belongs to the other. For example, the function vulnerability, and then we label the indegree and outdegree
containing the vulnerable code of JPEG-compressor is reused values of each node of the graph.
in Godot (CVE-2017-0700, see Section 2.3), and their paths
are as follows (see Listing 4):
3.3 Root finding phase
Listing 4: The path of the vulnerable code of CVE-2017-0700.
JPEG-compressor: "./[Link]" Lastly, V0Finder discovers VZ by finding the root of the
Godot : "./thirdparty/jpeg-compressor/[Link]" constructed vulnerability propagation graph. Based on the
indegree (deg– ) and outdegree (deg+ ) values specified for
If the file path of a function (that belongs to both sv and s0v ) in
each node, the condition that a node v is a root is as follows:
s0v is included in that of sv , we conclude that sv reuses s0v (i.e.,
s0v ≺ sv and s0v → sv ). deg– (v) = 0 ∧ deg+ (v) > 0

Metadata file-based identification. If both code and struc- However, the constructed graph does not always contain a
ture are modified while being reused, V0Finder utilizes meta- single root (see Figure 3); hence, we discover the VZ using
data files, which should be reused without modifications, to different approaches depending on the number of graph roots:
 1. Single root: This case indicates that V0Finder pin- Table 1: CVE pool overview.
points the VZ, i.e., the root of the graph. Specifically, Collection source #CVEs #Vul. functions
this graph is generated when the VZ is included in the NVD 3,246 12,587
software pool and V0Finder has successfully identified Issue trackers
reuse relations between vulnerable software. Android 1,340 9,581
Chromium 366 5,807
2. Two or more roots: This case refers to V0Finder failed
Mozilla 719 4,598
to pinpoint the VZ. If the VZ is not contained in the
Total 5,671 32,573
software pool or if V0Finder failed to identify some
reuse relations, more than one root may appear.
Table 2: Software pool overview.
3. No root: This implies one of the following cases: (1)
the VZ does not exist; (2) the vulnerability has not been Collection source #Software programs
propagated to other software; (3) V0Finder failed to Popular software programs 10,241
CVE-registered software* 460
identify reuse relations. First, in the cases of algorith-
Total software programs 10,701
mic vulnerabilities (e.g., a vulnerability in cryptographic
Total versions 229,326
code), VZ discovery is infeasible because an algorithmic Total lines of codes 80 billion
code has an ambiguous reuse relation; thus this case can
*: Software that has been reporting at least one CVE to NVD.
be ignored. Next, if the vulnerability has not been propa-
gated, there is only one node in the graph; we consider
diff format, we were able to collect the CVE patches using a
this node to be VZ. Last, V0Finder failed to identify
simple crawler developed using the BeautifulSoup library.
reuse relations and thus there is no root in the graph, i.e.,
We selected the initial vulnerability dataset for C/C++ vulner-
a false negative of V0Finder.
abilities, which do not provide any dependencies unlike other
To identify the VZ when a graph has two or more roots, languages (e.g., a Gemfile in Ruby); thus, it is suitable to show
we decided to take advantage of human intervention. Specifi- that V0Finder is efficient even without any dependencies.
cally, V0Finder examines the common functions of all roots, We then collected the additional CVE patches from
where each path of the common function contains strong hints Bugzilla for Android, Chromium, and Mozilla, where those
about the VZ. For example, in the case of CVE-2019-12900, three software are included in the top 10 software that reported
we found that the generated graph has three roots: GnuPG, the highest number of CVEs. To gather CVE patches from
PCSX2, and GR. V0Finder examined 58 common functions Android and Chromium, we adopted the method employed in
from the three software, of which, 56 were discovered under VUDDY [26], which considers commits containing the key-
the path named “Bzip2” (i.e., the VZ of CVE-2019-12900, word “CVE-20” in their log messages as CVE patches. In the
which was not included in the software pool). Thus, we aim case of Mozilla, a bug ID was assigned to each vulnerability
to solve the multi-root problem by providing common func- in their Bugzilla, and we could disclose the corresponding
tion information. This corner case currently requires human patch in the commit history of their Git repository4 .
intervention and its automation is left for future work. Vulnerable function reconstruction. Each collected patch
Lastly, if there is more than one vulnerable version in the contains the Git index and the line numbers including vul-
discovered VZ, we determine the version the vulnerability nerable code (e.g., “-2282, 3” in Listing 3). To reconstruct
first appeared to be the VZ of the vulnerability. vulnerable functions, we first accessed the index to obtain
the corresponding vulnerable files (i.e., using git show com-
4 Dataset and Implementation of V0Finder mand), and then extracted the vulnerable functions that con-
tain the vulnerable code lines using a function parser [26].
In this section, we introduce dataset construction, and then
CVE pool construction. Using the method introduced in
summarize the implementation of V0Finder.
CVE patch collection, we collected 5,671 CVE patches re-
ported by 460 software including all the C/C++ CVEs that
4.1 Dataset released their patches via Git. We extracted a total of 32,573
We introduce how to construct our dataset, i.e., the CVE and vulnerable functions from the collected CVE patches in a
software pools, for evaluation and further experiments. source code form (see Table 1). On average, one CVE patch
consists of six vulnerable functions; all the patches and vul-
CVE patch collection. To collect CVE patches, we lever- nerable functions were collected in September 2020.
aged the method used in Li et al. [29], where extracting a
Software pool construction. First of all, we collected the pre-
NVD referenced URL of a CVE that related to Git commits
viously mentioned 460 CVE-registered software which have
(i.e., URL containing the term github, gitlab, cgit, or
4 [Link]
gitweb). Because these URLs provide the CVE patches in
reported at least one CVE. In addition, we decided to collect the VZ discovery results of V0Finder using the correspond-
widely-reused popular software because the more frequently ing CPEs. We conclude that our result is correct when it is
the software is reused, the more likely it is to propagate vul- contained in the CPE. If the discovered VZ is not included
nerable code, i.e., it has a high probability of being a VZ. in the CPE, we analyze further to decide its correctness. It is
To collect the software, we chose GitHub, which is one of possible that V0Finder and NVD simultaneously provide the
the most popular version control systems [44], and collected incorrect VZ information for a CVE; however, the fact that the
C/C++ software with more than 100 stargazers [9], a popu- user’s reports (i.e., NVD information) and actual code-level
larity indicator available in GitHub. As a result, we collected VZ discovery (i.e., V0Finder result) are the same suggests
10,701 software (see Table 2), including OS (e.g., Linux), that these VZs are very likely to be correct.
databases (e.g., Redis), and AI (e.g., TensorFlow) related soft- By parsing the JSON feed obtained from the NVD, we
ware in April 2020, with a total of 230K versions, 2.2 billion extracted the (CVE, CPE) pairs. We then checked whether the
functions, and 80 billion lines of code (LoC). name of the software and version of the discovered VZ were
contained in the corresponding CPE. Notably, we were able to
4.2 Implementation perform exact string comparisons for 60% of the discovery re-
sults, because the software and version names registered in the
V0Finder comprises the following three modules: pool con- CPE were the same as those in GitHub. The remaining 40%
struction, graph construction, and VZ discovery modules. All exhibited differences from GitHub, e.g., OpenSSL_1_0_0a
the modules were written in Python, and the total length of on GitHub and 1.0.0a in CPE. Thus, we manually compared
the implementation is 1,500 lines of Python code. the discovery results of V0Finder and CPE of these CVEs
Parsing and the LSH algorithm. We used universal Ctags with the help of simple regular expressions, i.e., only numbers
[7] to extract functions in C/C++ source codes, which is a and the last alphanumeric characters were considered.
regular expression-based parser. Universal Ctags is managed Finally, we introduce the metrics that are used in the accu-
as open-sources, and, therefore, their accuracy and speed are racy measurement as follows:
continually enhanced. Subsequently, we selected the LSH • True Positive (TP): The discovered VZ is correct;
algorithm that was best suited for our mechanism. Among • False Positive (FP): The discovered VZ is incorrect;
the several LSH algorithms available [27, 41, 45], we selected • True Negative (TN): VZ was not discovered and it does
the TLSH algorithm5 , which is both accurate and scalable. not exist (e.g., algorithmic vulnerabilities);
Similarity detection using the TLSH algorithm resulted in • False Negative (FN): VZ was not discovered but it exists.
less false positives with reasonable hashing and comparison
Comparison results. We classified the VZ discovery results
speed; furthermore, compared to other algorithms, it was less
of V0Finder according to the number of roots in the graph.
influenced by the input size [28, 41]. Because TLSH was
selected, we referred to [41], and a cut-off value (θ) of 30 was (1) Single root cases: V0Finder generated a single root
selected, which is utilized in Section 3.1. vulnerability propagation graph for 2,903 (51%) out of 5,671
collected CVEs. Among them, the discovered VZs for 2,807
CVEs were included in the corresponding CPEs, indicating
5 Evaluation that the CVEs have the correct VZ (we discuss the reliability
In this section, we evaluate V0Finder. Section 5.1 investi- of the evaluation in Section 8).
gates how accurately V0Finder can discover VZs in prac- Next, there were 96 single root vulnerability propagation
tice by comparing the VZ discovery results of V0Finder graphs where their roots were not included in the CPE. To
with NVD CPEs, and Section 5.2 evaluates the efficiency verify the VZ from the discovery result of V0Finder and that
of V0Finder by comparing it with the timestamp metadata- of CPE, we used the following three validation methods:
based approach. Section 5.3 demonstrates the effectiveness 1. Reviewing the code: A code review was performed by
of the techniques utilized in V0Finder, and Section 5.4 mea- checking whether the vulnerable code causing the vul-
sures the performance of V0Finder. We evaluated V0Finder nerability was included in the discovered VZ.
on an Ubuntu server with a 2.40 GHz 8-core Intel Xeon Pro-
2. Referring to author sites: The discovered VZ were ver-
cessor, 6TB HDD, and 32GB RAM.
ified by consulting statements by the software vendor
and author sites regarding the origin of the vulnerability.
5.1 Comparison with NVD 3. Reproducing the vulnerability: If a proof of concept
Methodology. As CPE in NVD specifies the software pro- was publicly provided on a website such as Bugzilla
grams and their versions affected by a CVE, we compared or GitHub, it was utilized for reproducing the vulnera-
bility in the discovered VZ. Otherwise, an attempt to
5 [Link]
reproduce the vulnerability was performed on our own.
 Wrong version Wrong software Table 3: Results of accuracy measurement of V0Finder.
A B #CVEs #TP #FP #TN #FN Precision (%) Recall (%)
… … … …
Total results:
5,671 5,410 52 70 139 99 97
Excluding CVEs with a single node in the graph:
VZ ∈ CPE VZ ∉ CPE 3,164 2,903 52 70 139 98 95
Software program VZ (detected by V0FINDER) Version update
Software version The ancestor-software in CPE Code propagation
these cases, we treated all the roots as the VZs of the CVEs
Figure 4: Classification of VZ. and provided hints to predict correct but hidden VZs. As a re-
sult, we can identify the VZs for all CVEs by manual analysis
We verified 21 discovered VZs by reproducing the vulnera- with the hints. Nevertheless, these 52 CVEs are FPs.
bility. In other cases, the failure to reproduce the vulnerability (3) No root cases: We found that the generated graphs for
was due to compilation error, failure to call the vulnerable the remaining 2,716 CVEs have no root. Among them, the
function, or the proof of concept not being publicly available. graphs for 2,507 CVEs have only one node. Note that our
Among the remaining 75 cases, we verified 14 discovered software pool does not contain closed source software or com-
VZs by referring to the software author sites. Lastly, for all mercial software. Because operating systems such as Android
other cases, we confirmed that the vulnerable code causing and browsers such as Firefox are often reused in commercial
the vulnerability was contained in the discovered VZ. Con- software rather than in other OSS, numerous graphs have only
sequently, we confirmed that all the discovered VZs for 96 one root. Nonetheless, we confirmed that the only node in the
CVEs were more accurate than those of CPEs (Appendix A graph is always contained in the corresponding CPE.
shows the list of 96 CVEs, and the related information, e.g., The generated graphs for the remaining 209 CVEs have
severity and type, for these 96 CVEs is given in Appendix B). more than one node but no root. 70 of them are algorithmic
When we classified the 96 CVEs that have the incorrect vulnerabilities, i.e., TNs of V0Finder; for example, CVE-
VZ information into the wrong version and wrong software 2019-13456 vulnerability was caused by the EAP-pwd hand-
(see Figure 4), 50 CVEs have the wrong version, and the shake algorithm, and thus the VZ was not discovered. Finally,
remaining 46 CVEs have the wrong software. The wrong the graph for the remaining 139 CVEs contained multiple
version seems less dangerous than the wrong software, but it nodes but no edges, and they were not algorithmic vulnerabil-
influences the developers considerably when addressing vul- ities. These are cases where V0Finder fails to identify reuse
nerabilities. Thus, we decided not to make difference between relations, and are FNs of V0Finder.
the importance of the wrong version and the wrong software
(4) Graph statistics: There were 10 nodes and 24 edges in
as both pieces of information are needed for efficiently patch-
the generated graphs on average. The most complex graph
ing vulnerabilities.
consisted of 120 nodes and 1,942 edges (CVE-2015-4335),
We have responsibly reported all the CVEs with incorrect and 97% of the graphs with multiple nodes had less than 50
VZ information that we successfully reproduced. First, it was nodes. The average distance from the root node to a leaf node
reported to developers who could not detect the vulnerability was one depth, and the longest distance was four depths.
due to the incorrect VZ information, and it further reported
In fact, CVEs with a single node in the graph can be con-
to the CVE Numbering Authority (CNA) to request changing
sidered TPs since the node is contained in the corresponding
the CPE. Most of the software authors that had not known the
CPEs. However, we decided that these cases are not properly
existence of the vulnerability immediately patched it through
revealing the accuracy of V0Finder because the mechanism
our reports. There even was a case where a new CVE ID was
of V0Finder (i.e., P2 and P3) is not applied. Therefore, we
assigned to this issue (see Section 6.3). Lastly, some CNAs
measured the accuracy separately for (1) the entire CVEs and
are requesting further details about our reports, while a few
for (2) the CVEs with multiple nodes in their vulnerability
others are not currently responding to our requests, even after
propagation graph.
As a result, V0Finder showed 99% pre-
multiple reports and subsequent inquiries (quantitative figures #T P #T P


cision #T P+#FP and 97% recall #T P+#FN for the entire
about our reporting process are given in Appendix C).
CVEs, and showed 98% precision and 95% recall for the
(2) Multi-root cases: For the remaining 2,768 CVEs, ex- CVEs with multiple nodes in their graph. The summarized
cluding single root cases, the generated graphs for 52 CVEs results of the accuracy measurement are shown in Table 3.
have multiple roots. We confirmed that 20 cases occurred be-
cause the VZ was not included in the dataset (e.g., when the
5.2 Comparison with the timestamp metadata
VZ was not publicly available). The other 32 cases occurred
because we failed to identify the software reuse relations; To demonstrate that V0Finder is a more accurate approach
some software did not reuse metadata files while simultane- than the timestamp metadata-based approach, we compared
ously modifying codes and structures of reused software. In each VZ discovery result. After finding the vulnerable soft-
ware for a CVE in Section 3.1, the software with the earli- Table 4: Node discovery phase statistics.
est release date is determined as the VZ in the timestamp Detection target #Detection results
metadata-based approach. Since this approach can pinpoint (Unique) Vulnerable software programs 1,204
(Unique) Vulnerable versions 45,460
one VZ for all collected CVEs, no FNs occur. Hence, we Exact clones 249,702
determined to focus more on its FPs. Vulnerable clones
Modified clones 561,273
Upon comparing the results between V0Finder and the
timestamp metadata-based approach, the VZs for 264 CVEs Table 5: Edge connection phase statistics.
were different. By analyzing the vulnerable code and CVE Utilizing factor #Identification results
description, we confirmed that the 244 VZs obtained using Shared code ratio 5,004 (1.3%)
Path information (i.e., location) 272,410 (72.7%)
the timestamp metadata-based approach were incorrect; the Metadata files 97,392 (26.0%)
remaining 20 cases were the false alarms of V0Finder.
Result analysis. We affirmed that there are two main causes The node discovering technique. We detected vulnerable
of false alarms in the timestamp metadata-based approach: code clones based on the LSH and patch code for addressing
(1) when the timestamp metadata is unintentionally changed syntax-modified clones. From the results, we confirmed that
or removed, and (2) when a new code is added to the software the modified clones were detected almost twice as much as the
that has already been released (without updating its version). exact clones (see Table 4). Surprisingly, if we only considered
Developers might decide that old versions of the soft- exact clones, we failed to discover the VZ for 1,751 (31%) out
ware were no longer needed and therefore made them un- of 5,671 CVEs. If a vulnerable code exists with significantly
available. In addition, developers often attempted to transfer different syntax than that of originated in VZ, this cannot be
their software repository to another hosting service. Due to detected with an exact or a limited modified clone detection
such processes, the timestamp metadata was easily removed method such as used in VUDDY (e.g., robust to changes in
or changed; these unintended changes lead the timestamp only several parts such as variable names) [26]. This implies
metadata-based approach to yield false alarms. For exam- that our node discovering technique, capable of detecting
ple, in the case of CVE-2015-5221, V0Finder discovers that modified clones, is effective for VZ discovery.
Jasper v1.900.1 (the oldest version of Jasper that managed
by GitHub, released in 2016) is the VZ. The CVE description The edge connecting technique. We identified reuse rela-
clearly indicates that Jasper is the VZ. However, if the VZ tions between vulnerable software based on the shared code
is discovered based on the release date, ghostpdl v8.52 (re- ratio, source code path information, and metadata files: only
leased in 2005) was discovered as the VZ. We confirmed that 1.3% of total reuse relations were identified based on the
this situation happened because ghostpdl reused a much shared code ratio while 72.7% of them were identified by the
older version of Jasper that is currently not available. source code path information (see Table 5). This means that
In addition, there were cases that developers added a new most of the software was being reused explicitly (i.e., under
code to the previously released version without version up- the path with the name of the software) in other software with
dating. As an example, we introduce the CVE-2014-8962 code modifications. We further confirmed that the majority of
case. This vulnerability originated in Libflac v1.2.0 (released the graph was constructed with a single root (see Section 5.1),
in July 2007). However, the timestamp metadata-based ap- including a case where only one node appears. This shows
proach determined that the VZ is Praat v4.5.26 (released in that V0Finder can clearly determine one software program
May 2007). Praat developers have been continually modifying closest to the VZ based on the identified reuse relations.
the code of the previous versions; unfortunately, they added
the vulnerable version of Libflac to the previous version in 5.4 Performance of V0Finder
2014 for the purpose of reading FLAC audio files.
Comparing to the total number of collected CVEs (i.e., We focus more on accuracy than performance because the VZ
5,671), the number of false alarms of this approach may seem discovery needs to be performed only once for a vulnerability.
small (i.e., 244). However, since the timestamp metadata still Regardless, we show that V0Finder can discover a VZ in a
has the possibility that is changed or removed, its reliability large software pool within a reasonable time.
will not be guaranteed in the future. From this perspective, we Preparatory time. In our setup, it took 2 days to construct
assert that the approach of V0Finder that discovers VZ with the CVE pool and 10 days to construct the software pool. This
higher accuracy based on the reuse relation identification is includes the time to clone all versions of a repository with the
more efficient than the timestamp-based approach. Git command and the time to extract all functions and apply
the hashing after preprocessing the functions.
5.3 Effectiveness of the utilized techniques VZ discovery time. We measured the time required for each
Here we evaluate the effectiveness of the techniques utilized phase of V0Finder. It took 30 hours to identify vulnerable
in node discovery (P1) and edge connection (P2) phase. software programs that contain vulnerable clones of 5,671
 Table 6: Success rate for the vulnerability detection. #Software 12
10.4 Average
programs
8 6 Median
CVEs with the CVEs with the
Category 4 3.4
correct VZ incorrect VZ 2.2 1.6
1 1 1
CVEs 3,068 96 0
|XT| |YT| |XF| |YF|
Affected software∗ 10,523 1,000 |XT |: #Software affected by a CVE with the correct VZ detected by V0Finder;
Cases where the CVE |YT |: #Software affected by a CVE with the correct VZ provided by CPE;
8,994 (85%) 356 (36%) |XF |: #Software affected by a CVE with the incorrect VZ detected by V0Finder;
was detected
|YF |: #Software affected by a CVE with the incorrect VZ provided by CPE.
Cases where the CVE
1,529 (15%) 644 (64%)
was undetected
Figure 5: The number of software programs affected by the
∗: The cumulative number of all nodes in the vulnerability propagation graph for all
CVEs. Certain software can appear on multiple graphs. CVE according to the correctness of VZ.

CVEs over a base of 80 billion LoC. Thereafter, it took another • X : A set of software programs that contain a specific CVE
4 hours to construct the vulnerability propagation graphs and detected by V0Finder (i.e., all nodes of a graph);
discover the VZ. On average, V0Finder took approximately
22 seconds to discover the VZ of one CVE, which is sufficient • Y : A set of software programs that contain a specific CVE
to discover VZs using a large-scale dataset. provided by the NVD CPE.

We measured the respective sizes of X and Y for CVEs with

6 Impact of VZ discovery the correct VZ (i.e., |XT | and |YT |) and with the incorrect VZ
In this section, we analyze the impact of VZ discovery in (i.e., |XF | and |YF |). The results are as shown in Figure 5.
detail. Specifically, we examine how the correctness of VZ Notably, we confirmed that |XF | is much larger than |YF |
influences prompt detection and patching vulnerabilities by (|XF | = 6.5 × |YF |), which indicates many vulnerable software
answering the following two questions: programs have not been traced in public vulnerability reports
Q1. Are CVEs with the incorrect VZ more difficult to detect when a CVE with the incorrect VZ. Although a CPE is not in-
than CVEs with the correct VZ? (Section 6.1) tended to cover the entire vulnerable software, we discovered
that the gap between |XF | and |YF | is much larger than the
Q2. Do CVEs with the incorrect VZ cause longer patching
gap between |XT | and |YT | (|XT | ≈ 1.5 × |YT |). This implies
times for the affected software? (Section 6.2)
that CPEs are limited in providing affected software when the
CVE with the incorrect VZ compared to that with the correct
6.1 Success rate of vulnerability detection VZ. The experiment results, in turn, demonstrate the impor-
We analyze the correlation between the correctness of VZ tance of the VZ in the context of vulnerability propagation
and vulnerability detection. We suggest that vulnerability and patching vulnerable software.
detection has failed if there was a vulnerable clone in the
latest version of the affected software (at the time we collected 6.2 Elapsed time for vulnerability detection
it); we could measure this information from the output of P1.
Table 6 summarizes results of the success rate for vulnerability We analyze the correlation between the correctness of a VZ
detection. Note that we only considered CVEs with multiple and the elapsed time for vulnerability detection. We define
nodes in their vulnerability propagation graph (i.e., 3,164 three time-based metrics: vulnerability introduction time (ti ),
CVEs) as CVEs with a single node have no affected software. vulnerability detection time (td ), and CVE publication time
We confirmed that due to the incorrect VZ information, the (tr ); the example timeline is depicted in Figure 6.
developers were more likely to leave the vulnerability unat-
tended: 64% of reused vulnerable codes were not detected Vulnerability Vulnerability CVE report
introduction detection & patching publication
and survived up to the latest version of each affected software. VZ ti td tr Time
This ratio is much bigger than the cases of CVEs with the
Affected
correct VZ, where only 15% of vulnerable clones were not de- software t′i tr t′d Time
Vulnerability Propagated vulnerability
tected. Notably, there exists a number of popular software that propagation detection & patching
failed to detect the propagated CVE due to the incorrect VZ,
Figure 6: Illustration of vulnerability detection timeline. Note
such as Redis (45K GitHub stars, see Section 6.3) and Godot
that td and ti0 can be later than tr and td0 can be earlier than tr .
(33.8K stars). This leads to more serious threats: as popular
software is reused in many other programs, its vulnerability
has better chances of propagation to more programs. We consider the elapsed time for vulnerability detection
Current vulnerability databases cannot resolve this problem from the perspective of software and developers, respectively.
effectively, because they do not provide sufficient information From the software perspective, the elapsed time for vulnerabil-
about the software affected by the CVE. To demonstrate this, ity detection is defined as the delta between vulnerability in-
we examine the following information for every CVE. troduction and detection time (td - ti ). On the other hand, from
 Table 7: Elapsed time measurement for CVE detection. triggered only in the corner case because patching a vulnera-
Category Ave. (days) Med. (days) bility, e.g., updating a vulnerable third-party software, needs
(td - ti ) VZ 365 142 considerable costs and efforts.
(td0 - ti0 ) Affected software with the correct VZ 524 371 To investigate the overall distribution, we approximated the
(td0 - ti0 ) Affected software with the incorrect VZ 836 508
obtained result to a normal distribution. We selected the rank
(td - tr ) VZ 167 0
(td0 - tr ) Affected software with the correct VZ 308 180 as 100 (days) and measured the standard deviation (σ) for each
(td0 - tr ) Affected software with the incorrect VZ 521 305 of the six categories in Table 7, where all the average values
(µ) have already been measured. We assume that the elapsed
time for vulnerability detection follows a normal distribution
1.0x10-3 365 days 1.0x10-3 with µ and σ, and plot the normal distribution graphs. The
Probability density

Probability density
167 days (average)
(average)
8x10-4 8x10-4
308 days (average)
probability density function (i.e., f (x)) we used is as follows:
6x10-4 524 days (average) 6x10-4
.
4x10-4 4x10-4
836 days −(x−µ)2 2σ2
2x10-4 (average) 2x10-4
521 days f (x) = √1 e
(average) σ 2π
0 0
100 600 1100 1600 2100 2600 100 600 1100 1600 2100 2600
Elapsed time (days) Elapsed time (days) The plotted graphs are illustrated in Figure 7. From the
(a) Elapsed time for (td - ti) and (t'd – t' i) (b) Elapsed time for (td - tr) and (t'd - tr) graphs, we intuitively confirmed that a propagated CVE with
VZ the correct VZ, overall, is patched almost a year after CVE
Affected software with the correct VZ
Affected software with the incorrect VZ is published. In addition, we discovered that when a CVE
has the incorrect VZ information, the elapsed time for the
Figure 7: Normal distribution graphs illustrating the elapsed
affected software to detect the propagated CVE is longer than
time for vulnerability detection.
that of when a CVE with the correct VZ.
the developer perspective, the elapsed time for vulnerability We summarize the two key points from our experimental
detection is defined as the delta between CVE publication and results: (1) CVEs reported with the incorrect VZ took longer
detection time (td - tr ). We measure ti and td by confirming to detect the propagated vulnerabilities, and (2) the affected
the release date of the version in which the vulnerability first software programs are often unaware of the existence of CVEs
introduced and patched in a software program, respectively; due to the incorrect VZ. This demonstrates the importance
the tr for a CVE can easily be obtained from the NVD report. and necessity of VZ discovery to enable developers to detect
Furthermore, we classify a vulnerability detection behavior and patch propagated vulnerabilities in a timely manner.
into three types according to the subject of the detection:
detection in (1) VZ, (2) software affected by a CVE with 6.3 Case study: Vulnerability in Redis
the correct VZ, and (3) software affected by a CVE with the Redis is widely reused in-memory database. In 2015, a dan-
incorrect VZ. We measured the elapsed time for vulnerability gerous vulnerability (CVE-2015-8080) was discovered in Lua
detection from both software and developer perspectives for (VZ); however, it was reported as a vulnerability in Redis,
each of these three subjects. The results are shown in Table 7. which is reusing Lua, and only the Redis team patched the vul-
The main quantitative finding is that if a CVE with the nerability in 2015. This is because the Redis team determined
incorrect VZ is propagated to other software, those affected that vulnerability only affects their program as they incorpo-
software programs required 312 more days to detect the vul- rated Lua into their environment. Interestingly, in 2018, the
nerability than the case where a CVE with the correct VZ. Redis team updated Lua for security purposes, but kept the
CVEs with the incorrect VZ are difficult to detect unless version of Lua with the vulnerable code. Even more seriously,
software developers scan for vulnerabilities using static and by inserting a single line of proof of concept into Redis, an
dynamic tools, or receive reports from the security analysts. integer overflow vulnerability is reproduced, which can be ex-
Consequently, the incorrect VZ information can broaden the tended to a denial-of-service attack. We reported this case to
attack surface of the affected software for extended periods. Redis and they accepted our patch request in February 2020.
Next, when a vulnerability is reported with a CVE ID, This resulted in a new CVE ID (CVE-2020-14147).
it is easier for developers to patch the vulnerability. Thus,
the detection time td - tr (and, td0 - tr ) was shorter than the 7 Related work
detection time td - ti (and, td0 - ti0 ). In addition, even after CVE
was published at tr , we found that the VZ sometimes required In this section, we introduce a number of related studies.
additional time to patch the vulnerability, because some VZ Detecting code clones. There are many approaches attempt-
authors released a patched software after CVE was published. ing to detect source code clones [4, 11, 18, 20, 21, 26, 30–33,
Another interesting result was that even if a CVE has the 35, 37, 42, 43, 46–49, 53, 55]. However, these approaches do
correct VZ, the affected software required more than 300 days not consider discovering the VZ of software vulnerabilities,
to patch the propagated vulnerability. Presumably, developers but only focus on detecting clones in the specific snapshot of
seemed to be not urgent to patch a vulnerability when it is a software program via code scanning.
Tracing the code history. Some approaches attempted to whether those components are affected by the VZ determined
trace the history of the source code to improve software main- by V0Finder based on an existing or newly registered CVE.
tenance [10, 17, 19, 22, 23, 25, 50, 51]. However, tracing the Reliability of our evaluation. In our evaluation, we deter-
history of source code is fairly different from detecting the mined a VZ is correct if the VZ discovered by V0Finder for
history of a vulnerability; the way to clearly distinguish be- a certain vulnerability is included in the corresponding CPE.
tween vulnerable code and patched code is needed, but it is To validate this, we manually analyzed a subset of the VZ
not discussed in those approaches. discovery results. Among the 2,807 CVEs where the CPE
Verifying reliability of vulnerability reports. Existing ap- and the VZ discovered by V0Finder coincided, we randomly
proaches that aimed to verify the reliability of public vulnera- selected 20 CVEs per year from 2006 to 2020, i.e., 280 CVEs
bility reports can be divided into three categories: identifying (10%) out of 2,807 CVEs. We then analyzed whether the VZ
missing information in the report [2, 3, 5, 36], analyzing the discovered by V0Finder is correct, especially by referring
reproducibility of vulnerabilities [14, 34], and ensuring con- to the patch code and external links in the NVD reference.
sistency of the report [8]. Some of them showed that the As a result, we confirmed that for all cases but one, the VZ
additional information in the reports can help counter vulner- discovered by V0Finder that are contained in the CPE is the
abilities [2, 36] and bugs [3, 5]. Guo et al. [14] analyzed the correct VZ of each vulnerability. In one case, V0Finder and
characteristics of reports to efficiently fix bugs, and Mu et the CPE determined that MySQL was the VZ for CVE-2009-
al. [34] showed that there was not sufficient information in the 4484, but it was actually a vulnerability that originated in
reports to reproduce the vulnerability in order to analyze the YaSSL, which is not included in the dataset because it does
cause of the problem. Dong et al. [8] focused on the consis- not satisfy our dataset collection criteria (i.e., the number of
tency of the data provided by the vulnerability databases; they stars on GitHub is less than 100). Even if this error ratio (i.e.,
attempted to detect inconsistencies between the affected soft- less than 0.4%) extends to the entire CVE dataset, we can
ware mentioned in the description of vulnerability reports and verify the VZ discovered by V0Finder with more than 99%
the corresponding CPE. Although these approaches addressed confidence. Therefore, we concluded that our assumption is
the reliability and consistency of the information provided valid that considering the VZ discovered by V0Finder is
by the public vulnerability reports, they did not handle our correct when it is contained in the CPE.
targeted issue, discovering the correct VZ for a vulnerability. Use case: vulnerability reporting process. V0Finder can
be adopted in the vulnerability reporting process. First, secu-
8 Discussion rity analysts who find a new vulnerability can report it to a
Here we discuss several considerations related to V0Finder. CNA after discovering the VZ using V0Finder. Next, when
Inferring the main causes of an incorrect VZ. From our a CNA verifies the reported vulnerabilities, V0Finder can
experiment results, we confirmed that there were two main be applied to detect affected software as well as the VZ. In
causes for the occurrence of an incorrect VZ: (1) lack of a fact, we have contacted a CNA that is currently manually
proper tool to discover the VZ and (2) reuse of third-party discovering the VZ for a vulnerability. Based on an initial
software with modification. Currently, there is no automated discussion, V0Finder can be integrated into their workflow,
tool that is capable of discovering the VZ. Therefore, when such as discovering a VZ using V0Finder when verifying
software authors received a vulnerability report, they often the vulnerability before assigning the CVE ID.
registered the vulnerability as theirs without confirming the Future work. First, we will consider the vulnerability propa-
VZ. In particular, when receiving reports through Bugzilla, gation arising from copying and pasting small pieces of code,
the trend of having CVEs with the incorrect VZ is prominent. e.g., provided by Q&A fora. To address them, features other
In addition, a third-party software is often modified prior to than the reuse relation identification should be selected; we
reuse in other software. Thus, when a vulnerability is reported are investigating an extension technique to deal with such
to software program developers, they easily misinterpret that cases. Second, since the methodology of V0Finder can be
the vulnerability only manifests in their program, even though applied to other languages, we will discover VZs for other
the vulnerable code belongs to a third-party software. languages. This will be conducted by constructing the CVE
and software pool for the new languages.
Our suggestions. Based on our experiment results, we sug-
gest that the task of finding the VZ of vulnerabilities, pri-
marily a manual task, should be automated and accurately
9 Conclusion
performed with a system such as V0Finder. In addition, As public vulnerability reports are widely utilized to resolve
V0Finder can be integrated with other techniques, such as threats arising from software vulnerabilities, quality control
Software Bill of Materials (SBoM) [52], which declares the of reports is emerging. In response, we presented V0Finder,
components and pieces that the software was built with. We a precise mechanism to discover the VZ of software vulnera-
expect to enhance software security by (1) analyzing the com- bilities. We found that the current NVD provides the incorrect
ponents of a software through SBoM, and (2) identifying VZ for some CVEs, and by analyzing the adverse effects of
those CVEs in detail, we demonstrated the importance and ne- [6] Common Weakness Enumeration. 2020 CWE
cessity of VZ discovery. Equipped with VZ discovery results Top 25 Most Dangerous Software Weaknesses,
from V0Finder, developers can address software vulnerabili- 2020. [Link]
ties potentially included in their software due to vulnerable 2020/2020_cwe_top25.html.
code reuse (e.g., via third-party software), more specifically,
they can apply appropriate security patches. [7] Ctags. Universal Ctags, 2020. [Link]
universal-ctags/ctags.
Acknowledgment [8] Ying Dong, Wenbo Guo, Yueqi Chen, Xinyu Xing,
We appreciate the anonymous reviewers for their valuable Yuqing Zhang, and Gang Wang. Towards the detec-
comments to improve the quality of the paper. This work tion of inconsistencies in public security vulnerability
was supported by Institute of Information & Communications reports. In 28th USENIX Security Symposium (USENIX
Technology Planning & Evaluation (IITP) grant funded by Security), pages 869–885, 2019.
the Korea government (MSIT) (No.2019-0-01697 Develop-
[9] Ruian Duan, Ashish Bijlani, Meng Xu, Taesoo Kim, and
ment of Automated Vulnerability Discovery Technologies for
Wenke Lee. Identifying open-source license violation
Blockchain Platform Security and IITP-2021-2020-0-01819
and 1-day security risk at large scale. In Proceedings
ICT Creative Consilience program).
of the 2017 ACM SIGSAC Conference on Computer
and Communications Security (CCS), pages 2169–2185,
Availability 2017.
The source code of V0Finder is available at https://
[10] Mohammad Gharehyazie, Baishakhi Ray, and Vladimir
[Link]/wooseunghoon/V0Finder-public.
Filkov. Some from here, some from there: Cross-project
code reuse in github. In 2017 IEEE/ACM 14th Inter-
References national Conference on Mining Software Repositories,
pages 291–301, 2017.
[1] Jorge Aranda and Gina Venolia. The Secret Life of
Bugs: Going Past the Errors and Omissions in Software [11] Mohammad Gharehyazie, Baishakhi Ray, Mehdi Ke-
Repositories. In Proceedings of the 31st International shani, Masoumeh Soleimani Zavosht, Abbas Hey-
Conference on Software Engineering (ICSE), pages 298– darnoori, and Vladimir Filkov. Cross-project code
308, 2009. clones in GitHub. Empirical Software Engineering,
pages 1–36, 2018.
[2] Nicolas Bettenburg, Rahul Premraj, Thomas Zimmer-
mann, and Sunghun Kim. Duplicate bug reports con- [12] Aristides Gionis, Piotr Indyk, and Rajeev Motwani. Sim-
sidered harmful... really? In 2008 IEEE International ilarity search in high dimensions via hashing. 99(6):518–
Conference on Software Maintenance (ICSME), pages 529, 1999.
337–345, 2008.
[13] GitHub. Securing software, together, 2021. https:
[3] Silvia Breu, Rahul Premraj, Jonathan Sillito, and //[Link]/features/security.
Thomas Zimmermann. Information needs in bug re-
[14] Philip J Guo, Thomas Zimmermann, Nachiappan Na-
ports: improving cooperation between developers and
gappan, and Brendan Murphy. Characterizing and pre-
users. In Proceedings of the 2010 ACM Conference on
dicting which bugs get fixed: an empirical study of Mi-
Computer-Supported Cooperative Work, pages 301–310,
crosoft Windows. In Proceedings of the 32nd Inter-
2010.
national Conference on Software Engineering (ICSE),
[4] Lutz Büch and Artur Andrzejak. Learning-Based Re- pages 495–504, 2010.
cursive Aggregation of Abstract Syntax Trees for Code
[15] Irfan Ul Haq, Sergio Chica, Juan Caballero, and Somesh
Clone Detection. In 2019 IEEE 26th International Con-
Jha. Malware lineage in the wild. Computers & Security,
ference on Software Analysis, Evolution and Reengineer-
78:347–363, 2018.
ing (SANER), pages 95–104, 2019.
[16] Shohei Ikeda, Akinori Ihara, Raula Gaikovina Kula, and
[5] Oscar Chaparro, Jing Lu, Fiorella Zampetti, Laura
Kenichi Matsumoto. An Empirical Study of README
Moreno, Massimiliano Di Penta, Andrian Marcus,
contents for JavaScript Packages. IEICE TRANSAC-
Gabriele Bavota, and Vincent Ng. Detecting missing
TIONS on Information and Systems, 102(2):280–288,
information in bug descriptions. In Proceedings of the
2019.
2017 11th Joint Meeting on Foundations of Software
Engineering (ESEC/FSE), pages 396–407, 2017.
[17] Katsuro Inoue, Yusuke Sasaki, Pei Xia, and Yuki Man- [28] Amanda Lee and Travis Atkison. A comparison of fuzzy
abe. Where does this code come from and where does it hashes: evaluation, guidelines, and future suggestions.
go?-integrated code history tracker for open source sys- In Proceedings of the SouthEast Conference, pages 18–
tems. In Proceedings of the 34th International Confer- 25, 2017.
ence on Software Engineering (ICSE), pages 331–341,
2012. [29] Frank Li and Vern Paxson. A large-scale empirical study
of security patches. In Proceedings of the 2017 ACM
[18] Jiyong Jang, Abeer Agrawal, and David Brumley. Re- SIGSAC Conference on Computer and Communications
DeBug: Finding Unpatched Code Clones in Entire OS Security, pages 2201–2215, 2017.
Distributions. In 2012 IEEE Symposium on Security
and Privacy (SP), pages 48–62, 2012. [30] Zhen Li, Deqing Zou, Shouhuai Xu, Hai Jin, Hanchao
Qi, and Jie Hu. VulPecker: an automated vulnerability
[19] Jiyong Jang, Maverick Woo, and David Brumley. To- detection system based on code similarity analysis. In
wards automatic software lineage inference. In 22nd Proceedings of the 32nd Annual Conference on Com-
USENIX Security Symposium (USENIX Security), pages puter Security Applications (ACSAC), pages 201–213,
81–96, 2013. 2016.
[20] Lingxiao Jiang, Ghassan Misherghi, Zhendong Su, and [31] Zhen Li, Deqing Zou, Shouhuai Xu, Xinyu Ou, Hai Jin,
Stephane Glondu. Deckard: Scalable and accurate tree- Sujuan Wang, Zhijun Deng, and Yuyi Zhong. VulDeeP-
based detection of code clones. In Proceedings of the ecker: A deep learning-based system for vulnerability
29th International Conference on Software Engineering detection. In Proceedings of the Annual Network and
(ICSE), pages 96–105, 2007. Distributed System Security Symposium (NDSS), 2018.
[21] Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue.
[32] Zhenmin Li, Shan Lu, Suvda Myagmar, and Yuanyuan
CCFinder: a multilinguistic token-based code clone de-
Zhou. CP-Miner: A Tool for Finding Copy-paste and
tection system for large scale source code. IEEE Trans-
Related Bugs in Operating System Code. 4(19):289–
actions on Software Engineering, 28(7):654–670, 2002.
302, 2004.
[22] Tetsuya Kanda, Takashi Ishio, and Katsuro Inoue. Ex-
traction of product evolution tree from source code of [33] Dmitry Luciv, Dmitrij Koznov, George Chernishev,
product variants. In Proceedings of the 17th Interna- Hamid Abdul Basit, Konstantin Romanovsky, and An-
tional Software Product Line Conference (SPLC), pages drey Terekhov. Duplicate finder toolkit. In Proceedings
141–150, 2013. of the 40th International Conference on Software En-
gineering: Companion (ICSE-Companion), pages 171–
[23] Tetsuya Kanda, Takashi Ishio, and Katsuro Inoue. Ap- 172, 2018.
proximating the Evolution History of Software from
Source Code. IEICE Transactions on Information and [34] Dongliang Mu, Alejandro Cuevas, Limin Yang, Hang
Systems, 98(6):1185–1193, 2015. Hu, Xinyu Xing, Bing Mao, and Gang Wang. Under-
standing the reproducibility of crowd-reported security
[24] Georgia M Kapitsaki, Nikolaos D Tselikas, and Ioan- vulnerabilities. In 27th USENIX Security Symposium
nis E Foukarakis. An insight into license tools for open (USENIX Security), pages 919–936, 2018.
source software systems. Journal of Systems and Soft-
ware, 102:72–87, 2015. [35] Ginger Myles and Christian Collberg. Detecting soft-
ware theft via whole program path birthmarks. In In-
[25] Naohiro Kawamitsu, Takashi Ishio, Tetsuya Kanda, ternational Conference on Information Security, pages
Raula Gaikovina Kula, Coen De Roover, and Katsuro 404–415. Springer, 2004.
Inoue. Identifying source code reuse across repositories
using LCS-based source code similarity. In 2014 IEEE [36] Antonio Nappa, Richard Johnson, Leyla Bilge, Juan Ca-
14th International Working Conference on Source Code ballero, and Tudor Dumitras. The attack of the clones:
Analysis and Manipulation, pages 305–314, 2014. A study of the impact of shared code on vulnerability
patching. In 2015 IEEE Symposium on Security and
[26] Seulbae Kim, Seunghoon Woo, Heejo Lee, and Hakjoo
Privacy (SP), pages 692–708, 2015.
Oh. VUDDY: A Scalable Approach for Vulnerable Code
Clone Discovery. In 2017 IEEE Symposium on Security [37] Manziba Akanda Nishi and Kostadin Damevski. Scal-
and Privacy (SP), pages 595–614, 2017. able code clone detection and search based on adap-
[27] Jesse Kornblum. Identifying almost identical files using tive prefix filtering. Journal of Systems and Software,
context triggered piecewise hashing. Digital investiga- 137:130–142, 2018.
tion, 3:91–97, 2006.
[38] NPM. Node Package Manager, 2020. [Link] with Flexible Multilingual Tokenization. In 24th Asia-
[Link]/. Pacific Software Engineering Conference (APSEC),
pages 654–659, 2017.
[39] NVD. National Vulnerability Database, 2020. https:
//[Link]/. [50] Francisco Servant and James A Jones. Fuzzy fine-
grained code-history analysis. In Proceedings of the
[40] NVD. Common Platform and Enumeration (CPE), 2021. 39th International Conference on Software Engineering
[Link] (ICSE), pages 746–757, 2017.
[41] Jonathan Oliver, Chun Cheng, and Yanggui Chen. [51] Daniela Steidl, Benjamin Hummel, and Elmar Juergens.
TLSH–a locality sensitive hash. In Proceedings of the Incremental origin analysis of source code files. In
2013 Fourth Cybercrime and Trustworthy Computing Proceedings of the 11th Working Conference on Mining
Workshop, pages 7–13, 2013. Software Repositories, pages 42–51, 2014.
[42] Henning Perl, Sergej Dechand, Matthew Smith, Daniel [52] National Telecommunications and Information Admin-
Arp, Fabian Yamaguchi, Konrad Rieck, Sascha Fahl, and istration. NTIA Software Component Transparency
Yasemin Acar. VCCFinder: Finding Potential Vulnera- with SBOM (Software Bill of Materials), 2020. https:
bilities in Open-Source Projects to Assist Code Audits. //[Link]/SoftwareTransparency.
In Proceedings of the 2015 ACM SIGSAC Conference on
Computer and Communications Security (CCS), pages [53] Tijana Vislavski, Gordana Rakic, Nicolás Cardozo, and
426–437, 2015. Zoran Budimac. LICCA: A tool for cross-language
clone detection. In 2018 IEEE 25th International Con-
[43] Chaiyong Ragkhitwetsagul and Jens Krinke. Siamese: ference on Software Analysis, Evolution and Reengineer-
scalable and incremental code clone search via multiple ing (SANER), pages 512–516, 2018.
code representations. Empirical Software Engineering,
pages 2236–2284, 2019. [54] Daniel Votipka, Rock Stevens, Elissa Redmiles, Jeremy
Hu, and Michelle Mazurek. Hackers [Link]: A Com-
[44] RhodeCode. Version Control Systems Popular- parison of Software Vulnerability Discovery Processes.
ity, 2016. [Link] In 2018 IEEE Symposium on Security and Privacy (SP),
version-control-systems-2016. pages 374–391, 2018.
[45] Vassil Roussev. Hashing and data fingerprinting in dig- [55] Pengcheng Wang, Jeffrey Svajlenko, Yanzhao Wu, Yun
ital forensics. IEEE Security & Privacy, 7(2):49–55, Xu, and Chanchal K Roy. CCAligner: a token based
2009. large-gap clone detector. In Proceedings of the 40th In-
[46] Chanchal K Roy and James R Cordy. NICAD: Accurate ternational Conference on Software Engineering (ICSE),
detection of near-miss intentional clones using flexible pages 1066–1077, 2018.
pretty-printing and code normalization. In 2008 16th [56] Wikipedia. Index case (or patient zero), 2020. https:
IEEE International Conference on Program Compre- //[Link]/wiki/Index_case.
hension, pages 172–181, 2008.
[57] Michael Worobey, Thomas D Watts, Richard A McKay,
[47] Vaibhav Saini, Farima Farmahinifarahani, Yadong Lu, Marc A Suchard, Timothy Granade, Dirk E Teuwen,
Pierre Baldi, and Cristina Lopes. Oreo: Detection of Beryl A Koblin, Walid Heneine, Philippe Lemey, and
Clones in the Twilight Zone. In Proceedings of the 2018 Harold W Jaffe. 1970s and ‘Patient 0’ HIV-1 genomes
26th ACM Joint Meeting on European Software Engi- illuminate early HIV/AIDS history in North America.
neering Conference and Symposium on the Foundations Nature, 539(7627):98–101, 2016.
of Software Engineering (ESEC/FSE), pages 345–365,
2018. [58] Yang Xiao, Bihuan Chen, Chendong Yu, Zhengzi Xu,
Zimu Yuan, Feng Li, Binghong Liu, Yang Liu, Wei Huo,
[48] Hitesh Sajnani, Vaibhav Saini, Jeffrey Svajlenko, Chan- Wei Zou, and Wenchang Shi. MVP: Detecting Vulnera-
chal K Roy, and Cristina V Lopes. SourcererCC: Scaling bilities using Patch-Enhanced Vulnerability Signatures.
code clone detection to big-code. In Proceedings of the In 29th USENIX Security Symposium (USENIX Secu-
38th International Conference on Software Engineering rity), pages 1165–1182, 2020.
(ICSE), pages 1157–1168, 2016.
[49] Yuichi Semura, Norihiro Yoshida, Eunjong Choi, and
Katsuro Inoue. CCFinderSW: Clone Detection Tool
Appendix A Results of the incorrect VZs
We introduce a list of CVEs that provides the incorrect VZ, ∗ CPE: Show only one parent software among the CPE-
along with the correct VZ discovered by V0Finder for each registered software (determined by the result of V0Finder).
CVE. Note that there was no case where the reproduction ∗∗VZ: Discovered VZ using V0Finder.
was succeeded only in the incorrect VZ provided by CPE; the
† Verification: How to verify the VZ (see Section 5.1).
reproduction either was succeeded in both the VZ discovered
by V0Finder and that of CPE or was failed in both of them
due to the reasons specified in Section 5.1.

Table 8: 50 CVEs with wrong versions. Table 9: 46 CVEs with wrong software programs.
CPE∗ VZ∗∗ CPE∗ VZ∗∗
CVE ID Verification† CVE ID Verification†
Software Version Version Software Software Version
CVE-2007-1320 Qemu v0.8.2 v0.6.0 Code review CVE-2006-5748 Firefox JS engine N/A Code review
CVE-2008-4225 Libxml2 v2.7.2 v2.2.6 Code review CVE-2009-0774 Firefox JS engine N/A Code eview
CVE-2009-3720 Expat v2.0.1 v2.0.0 Code review CVE-2009-2466 Firefox JS engine N/A Code eview
CVE-2012-1013 Krb5 v1.8 v1.7.1 Code review CVE-2009-2663 Firefox Vorbis v1.0.1 Code eview
CVE-2014-0185 PHP v5.5.0 v5.3.4 Author sites CVE-2009-3379 Firefox Vorbis v1.0.0 Code review
CVE-2014-3985 Miniupnp v1.9 v1.8 Code review CVE-2010-3176 Firefox Vorbis v1.0.0 Code review
CVE-2014-4344 Krb5 v1.10 v1.5 Code review CVE-2011-3026 Chrome Libpng v1.2.44 Author sites
CVE-2014-8116 File v5.20 v5.19 Code review CVE-2011-3045 Chrome Libpng v1.2.44 Author sites
CVE-2015-3395 FFmpeg v2.0.6 n0.10.8 Author sites CVE-2011-3439 iOS Freetype v2.4.5 Author sites
CVE-2016-3705 Libxml2 v2.9.3 v2.9.0 Reproduction CVE-2011-3893 Chrome FFmpeg n0.5.8 Author sites
CVE-2016-8687 Libarchive v3.2.1 v3.1.0 Code review CVE-2013-0760 Firefox Uchardet v0.0.2 Code review
CVE-2016-8688 Libarchive v3.2.1 v3.1.0 Reproduction CVE-2013-0894 Chrome FFmpeg n0.10.6 Author sites
CVE-2016-9118 OpenJPEG v2.1.2 v2.1.1 Code review CVE-2013-6629 Chrome Libjpeg 6b Code review
CVE-2016-9388 Jasper v1.900.14 v1.900.1 Reproduction CVE-2013-7226 PHP Libgd v2.1.0 Author sites
CVE-2016-9535 Libtiff v4.0.6 v4.0.5 Code review CVE-2014-0237 PHP File 5_06 Author sites
CVE-2016-9573 OpenJPEG v2.1.2 v2.1.1 Reproduction CVE-2014-3710 PHP File 5_16 Author sites
CVE-2016-10269 Libtiff v4.0.7 v4.0.0 Reproduction CVE-2014-6262 Zenoss_core RRDtool v1.5.0 Author sites
CVE-2016-10270 Libtiff v4.0.7 v4.0.0 Reproduction CVE-2015-2756 Debian Linux Qemu v2.3.0 Code review
CVE-2017-5225 Libtiff v4.0.7 v4.0.0 Reproduction CVE-2015-4335 Redis Lua v5.1 Reproduction
CVE-2017-5601 Libarchive v3.2.2 v3.0.4 Reproduction CVE-2015-5165 Xen Qemu v2.3.0 Code review
CVE-2017-6420 ClamAV v0.99.2 v0.99.1 Code review CVE-2015-8080 Redis Lua v5.3 Reproduction
CVE-2017-7407 Curl v7.53.1 v6.5.0 Author sites CVE-2015-8865 PHP File 4_26 Author sites
CVE-2017-7746 Wireshark v2.0.0 v1.99.9 Code review CVE-2016-1624 Chrome Brotli v0.1.0 Code review
CVE-2017-9047 Libxml2 v2.9.4 v2.6.20 Code review CVE-2016-1626 Chrome OpenJPEG v2.0 Code review
CVE-2017-9226 Oniguruma v6.2.0 v5.9.6 Code review CVE-2016-1968 Firefox Brotli v0.1.0 Code review
CVE-2017-9227 Oniguruma v6.2.0 v5.9.6 Code review CVE-2016-2464 Android Libwebm v1.0.0.26 Code review
CVE-2017-9229 Oniguruma v6.2.0 v5.9.6 Code review CVE-2016-2808 Firefox Spidermonkey v25 Author sites
CVE-2017-11462 Krb5 v1.8 v1.14 Reproduction CVE-2016-4477 Android Wpa_supplicant v0.4.0 Code review
CVE-2017-14054 FFmpeg v3.3.3 v3.1 Code review CVE-2016-5152 Chrome OpenJPEG v2.0.1 Reproduction
CVE-2017-14152 OpenJPEG v2.2.0 v2.1.1 Code review CVE-2016-5257 Firefox FFmpeg n3.1 Code review
CVE-2017-14164 OpenJPEG v2.2.0 v2.1.1 Code review CVE-2017-0381 Android Libopus draft-09 Code review
CVE-2017-14169 FFmpeg v3.3.3 n2.5 Reproduction CVE-2017-0386 Android Libnl v2.0 Code review
CVE-2017-14170 FFmpeg v3.3.3 n2.6 Code review CVE-2017-0393 Android Libvpx v1.3.0 Code review
CVE-2017-14222 FFmpeg v3.3.3 n2.5.3 Code review CVE-2017-0408 Android JPEG-compressor v0.1 Code review
CVE-2017-14223 FFmpeg v3.3.3 n2.6 Code review CVE-2017-0553 Android Libnl v2.0 Code review
CVE-2017-14502 Libarchive v3.3.2 v3.1.900a Code review CVE-2017-0663 Android Libxml2 v2.7.0 Code review
CVE-2017-17081 FFmpeg v3.4 n2.3 Code review CVE-2017-0700 Android JPEG-compressor v0.1 Reproduction
CVE-2017-17480 OpenJPEG v2.3.0 v1.1 Code review CVE-2017-5056 Chrome Libxml2 v2.2.6 Code review
CVE-2017-1000249 File 5_29 5_22 Code review CVE-2017-6983 iOS Sqlite v3.7.11 Code review
CVE-2018-5727 OpenJPEG v2.3.0 v2.1.2 Code review CVE-2017-13693 Linux Kernel Acpica 20170629 Code review
CVE-2018-5785 OpenJPEG v2.3.0 v2.1.1 Reproduction CVE-2017-13695 Linux Kernel Acpica 20170629 Code review
CVE-2018-16790 Libbson v1.12.0 v1.9.0 Code review CVE-2018-5146 Firefox Vorbis v1.2.0 Reproduction
CVE-2018-18088 OpenJPEG v2.3.0 v2.2.0 Code review CVE-2018-5711 PHP Libgd v2.1.0 Reproduction
CVE-2019-9718 FFmpeg v4.1 n3.5 Code review CVE-2018-6064 Chrome V8 v5.1.219 Reproduction
CVE-2019-12973 OpenJPEG v2.3.1 v2.3.0 Reproduction CVE-2019-9278 Android Libexif v6.21 Code review
CVE-2019-13224 Oniguruma v6.9.2 v6.4.0 Code review CVE-2019-17371 Libpng Gif2png v2.5.13 Reproduction
CVE-2019-15681 Libvncserver v0.9.12 v0.9.8 Code review
CVE-2019-19317 Sqlite v3.30.1 v3.26.0 Code review
CVE-2019-1010239 cJSON v1.7.8 v1.7.4 Reproduction
CVE-2020-7595 Libxml2 v2.9.10 v2.9.6 Code review
3 (3%) 1 (6%)
5
6 2 (13%)
21
34 (35%) 6
10 (38%) 9 (56%)
11
16 (62%) 4 (25%)
59 (62%)

(a) CVSS distribution (b) Top 5 CWE distribution (a) Overall results of the reports (b) Results for the "response" cases

Figure 8: CVSS and CWE distributions for the CVEs with Figure 9: Depiction of the vendors’ responses.
the incorrect VZ.

Appendix B Analysis for the mislabeled CVEs Appendix C Results of the vendors’ responses
V0Finder identified that 96 CVEs that have wrong informa-
We classify our reporting process into two categories: re-
tion related to their respective VZs. We analyzed the severity
sponse and no response (see Figure 9). Among the total of 26
(i.e., Common Vulnerability Scoring System, shortly CVSS)
reports, we have received responses from 16 vendors:
and type for these CVEs (i.e., Common Weakness Enumera-
tion, shortly CWE); the analysis results are shown in Figure 8. CVE updated (1 case). This is a case where the CPE was
In terms of the severity, approximately a third of the changed to the discovered VZ by V0Finder.
total was a high-risk vulnerability (see Figure 8 (a)). Of CVE issued (2 cases). This is a case where a new CVE ID
course, when we successfully reproduce and report high- has been assigned. Of course, the vulnerability was patched
risk vulnerabilities, most of them were immediately patched before it was issued.
(e.g., CVE-2017-0700) or managed with a CVE ID assigned
Vulnerability patched (4 cases). This is a case where the
(e.g., CVE-2020-14147).
vulnerability that existed in the latest version of the affected
In the perspective of the vulnerability type, as shown in
software due to the incorrect VZ was patched.
the Figure 8 (b), the most frequently appeared type is the
vulnerability related to the boundary of the buffer (CWE-119, Vulnerability confirmed (9 cases). This is a case where the
e.g., buffer-overflow vulnerability). In particular, CWE-119, vendors confirmed the vulnerability but decided that the vul-
CWE-125, and CWE-190 belong to the top 25 most dangerous nerability was not critical (e.g., a corner case); thus, they
vulnerability types in 2020 [6]. would not patch immediately but considered patching the
later versions if applicable.

Lastly, for the no response cases, we are still trying to

communicate with the corresponding vendors.