98

Studying Reuse of Out-dated Third-party Codein Open Source Projects
Pei Xia

Makoto Matsushita

Norihiro Yoshida

Katsuro Inoue

Using existing source code as third-party code to build new software systems becomes very popular in thesedays. However, many existing code is keeping on updating during their life circle. Diﬀerent versions ofcode, even out-dated, is reused by other software and spreading all over the world. This paper presents anempirical study on the reuse of out-dated third-party source code of several famous open source libraries.
Given target source code, using repository mining techniques and file clone detection techniques, we identified the diﬀerent versions of code in other user projects, and discovered the vulnerability information of
the out-dated versions. We also investigated how user projects manage their code. The result shows that alarge proportion of open source projects are reusing out-dated third-party code, and many of them are notwell managed.

1 Introduction
Nowadays, using existing software to build new
software systems becomes very popular. Moreand more high quality software are becoming open
source. Even software in the industry increasingly
reuse open source systems due to their reliability
and cost benefits. [2]Integrating third-party code is an important approach in code reuse. Third-party code is a set of
reusable software components developed to be either freely distributed or sold by an entity otherthan the original vendor of the development platform, and they are wildly reused by developers allover the world [10]. However, while enjoying thebenefits, developers also have to concern about therisks brought by reusing third-party code. If the
オープンソースプロジェクトを対象としたレガシーコードの保守漏れに関する調査.
夏 沛, 松 下 誠 , 井 上 克 郎 , 大 阪 大 学 大 学 院 情 報 科 学研究科コンピュータサイエンス専攻, Department ofComputer Science, Graduate School of Information
Science and Technology, Osaka University.
吉田 則裕, 奈良先端科学技術大学院大学情報科学研究
科, Graduate School of Information Science, Nara
Institute of Science and Technology.
コンピュータソフトウェア, Vol.30, No.4 (2013),pp.98–104.

[研究論文 (レター)] 2013 年 3 月 27 日受付.

reused code contain critical vulnerabilities, it willbring damage to the software system.
Out-dated third-party code in this paper represents that code of older versions containing
known vulnerabilities such as software vulnerabilities which should be fixed by upgrading them to anewer version. As far as we know, currently thereis few research focus on the out-dated third-party
code reuse and management behavior. Our work
is to do an empirical study in this area and collectquantitative and qualitative data to answer following research questions:
RQ1 What is the proportion of out-dated thirdparty code reused in the open source projects?
RQ2 What are the potential vulnerabilities
caused by such reuse?
RQ3 How do developers manage those outdated third-party code?
Answering these questions would be helpful inunderstanding the open source software, evaluating the quality of the software which reuses reused
third-party code, and predicting some of the potential vulnerabilities in open source software. Also it
would make developers aware of the importance ofthird-part code management.
Based on the code clone detection, repository
mining techniques, and open source code searchengines, here we propose an approach to detect-Vol. 30 No. 4 Nov. 2013

Fig. 199

Study Approach Overview

ing out-dated third-party code reuse for certain libraries in open source software.

2 Study Approach
Fig.1 shows the proposed approach of this study,
composed of Step 1 to 4.
2. 1 Step 1: Vulnerabilities Information
Collection
To explore the potential vulnerabilities of given
third-party project, we did not analyze the project
directly. Instead, the vulnerabilities information
is manually collected from those two sources: theN ational V ulnerability Database [5] (N V D) andproject homepage announcement.
N V D is the U.S. government repository for thevulnerability management data. It contains famous resources such as Common V ulnerabilities
and Exposures and CERT V ulnerability N otes
Database. Searching with keywords such as project
name or filename, N V D returns a list of vulnerabilities information including vulnerability id,
summary, published date, and CVSS Severity
score. For example, one result of using keyword“libpng”†1 :†1 National Vulnerability Database (CVE-20113464), http://web.nvd.nist.gov/view/vuln/detail?
vulnId=CVE-2011-3464

CVE-2011-3464 (07/22/2012): Oﬀ-by-one
error in the png formatted warning function inpngerror.c in libpng 1.5.4 through 1.5.7 mightallow remote attackers to cause a denial of service (application crash) and possibly execute
arbitrary code via unspecified.
From project homepage announcement, we canalso get some vulnerabilities information. Usually,
when some critical vulnerabilities are found in someversions of an open source project, there would bean announcement on the project’s homepage. Taking the zlib homepage as example†2 , we can findannouncement such as:
Version 1.2.3 (July 2005) eliminates potential security vulnerabilities in zlib 1.2.1 and1.2.2, so all users of those versions should upgrade immediately.
The vulnerabilities information from these twosources are considered to be reliable.
2. 2 Step 2: User Projects Searching
Nowadays, open source software hosting facilities are becoming popular. Millions of open source
projects are hosted on the Internet. Google Code†2 zlib Home Site, http://zlib.net/

100

コンピュータソフトウェア

and GitHub are some of the most popular open
source hosting sites. From such open source software hosting facilities, we find a list of projects thatreused the subject third-party code. In this step,
we use a code searching system OpenCCFinder(Open Code Clone Finder) helping us to do this [4][7]. OpenCCFinder is a system to explore code fragments from open source repositories. This systemtakes a query code fragment as input, and returns
the files containing code clones with the query code,
along with information including project repository
URL, code similarity and so on.
In this study, we select several source files fromthe subject third-party projects and give them to
OpenCCFinder , and merge the search results together. Then we get a list of open source projects
reusing the code of the subject third-party project.
There are a number of experimental personal
projects also hosted on the open source project
hosting facilities, which are not well managed or
abandoned, so we manually filter out the projects
considered not appropriate. The user projects
in this study are formally published and actively
maintained by stable organizations.
2. 3 Step 3: Version Identification
The idea of identify the version number is to compare the content of each file in the user projects returned by OpenCCFinder with those of third-party
projects. If each file of a certain version (e.g. v1.0)
of a third-party code exactly matches with the files
in a user project returned by OpenCCFinder, thisproject is probably reusing v1.0 of the third-party
code.
However, when a user project tries to reuse sourcecode from third-party project, it is possible to modify the original code. In this study, we ignore trivial
modifications between source code such as adding
or removing comments, blank lines, line breakers or
space characters. We also ignore the rename refactoring, since such modifications would not aﬀect thepotential vulnerabilities in source code. In order toignore the eﬀect of these trivial modifications, eachsource file is tokenized before the hash values calculation and matching. Fig.2 explains the processof the hash value calculation.
We check out all the source files of each versions
in history of third-party code from its repository
and calculate the tokenized hash value for each file.

Fig. 2File Hash Calculation

Also, we check out the latest version of user projects
and calculate the tokenized hash values. By comparing those hash values, we are able to identify theversion numbers of the third-party code which arereused in the user projects precisely. In addition, if
there are some user project files which do not match
any files in third-party code history, we would manually look into the files to confirm whether they aremodified by the user projects.
2. 4 Step 4: Management Information
Collection
At last, we manually investigate how the developers of the user projects have managed the thirdparty code.
Firstly, we check the repository commit message
history to see whether the developers have ever updated the third-party code. Secondly, we checkthe “readme.txt” and “changelog.txt” etc. under
the directory of the third-party code to find how
the developers have managed the version information of the third-party code. At last, we checkif there are any extra changes that might cause
diﬃculty of management. For example, some developers change the package or directory name of
the third-party libraries, or they change some of
the filenames, or they mix the third-party codewith their own code. Such behaviors are considered harmful for management.

Vol. 30 No. 4 Nov. 2013
Table 1
Project name
DomainProject homepage
Repository url
Earliest version foundRelease date of the earliest version foundLatest Version
Latest Release date
# of version tags
# of source files (.c or .h) in latest version
Totle size of source files (.c .h) in latest version

101

Subjects Third-party Codezlib
data compression
http://www.zlib.net/
https://github.com/
madler/zlib.git
v0.71
April 1995
v1.2.7
May 2012
65
26
482KB

libcurl (curl/lib)
file transfer
http://curl.haxx.se/libcurl/
https://github.com/bagder/curl
v6.5
December 1999
v7.28.1
November 2012
134
222
2.77MBlibpnggraphics
http://www.libpng.org/
git://libpng.git.sourceforge.
net/gitroot/libpng/libpng
v0.71
July 1995
v1.5.13
September 2012
150
24
1.06MB

3 Case Study
3. 1 Subject Third-party CodeCurrently we have chosen three subject thirdparty code in diﬀerent domain. These are zlib,
libcurl, and libpng.
They are all well-known
and widely reused open source libraries. Table 1
is information of these three subject third-party
projects.
3. 2 Case Study Statistics
Using OpenCCFinder, we have collected 45 user
projects for zlib, 28 user projects for libcurl, and
50 user projects for libpng. The detailed data canbe found in [6]. †3
3. 2. 1 Proportion of Out-dated Thirdparty CodeIn our study, a number of versions of third-party
libraries even including out-dated unsafe code arefound in the user projects. Only a few projects areusing the latest version libraries. Fig.3 shows thenumber of projects that reuse the third-party codeof the diﬀerent versions. Those libraries without
any known software vulnerabilities are in light graycolumns; the ones with warnings from the thirdparty project homepage are in dark gray columns;
and the ones containing software vulnerabilities arein black columns. We can observe that:• For zlib, 45 projects in this study reuse 9 different versions of zlib code. 14 projects (31.1%)
are using out-dated zlib code containing potential vulnerabilities, while 6 projects have upgraded to the latest version. V1.2.3 seems to
be a stable version, and it is the most reused†3 All these case studies have been performed between Nov. 2012 and Jan. 2013.

Fig. 3

Reused Third-party Code Versions

one.
• For libcurl, 28 projects in this study reuse 20
diﬀerent versions of libcurl code. 24 projects(85.7%) are reusing out-dated libcurl code.
Only 4 projects are using the newer versionsof code without vulnerabilities and only one
project is using the latest version.
• For libpng, 50 projects in this study reuse 37
diﬀerent versions of libpng code. 46 projects(92%) are reusing out-dated libpng code. Only
4 projects are using newer versions of code
without vulnerabilities and 2 projects are using
the latest version.

102

コンピュータソフトウェア

In all the 123 projects, 84 projects (68.3 %) arereusing the out-dated third-party code. This result indicates that a large number of open source
software are containing code with vulnerabilities.
3. 2. 2 Third-party Code Management
Information
For the third-party code management information:• In all the 123 projects we studied, 27 projects(22.0%) have modified the third-party code.
The left 96 projects (78.0%) have reused thethird-party code without any modification.
• In all 123 projects, only 18 projects have managed the third-party code well and updatethem frequently; while 83 projects did not update the third-party code at all, and in these83 projects, 23 projects (18.7%) have no version information of the third-party code. Those
projects have imported only the source code of
the third-party libraries but they have not included the readme or changelog files. The usersof these user projects cannot know which version of the third-party code is reused.
• In all 123 projects, 6 projects have changed the
directory names or mixed the third-party codewith other code, which could lead to diﬃcultyin third-party code management. In addition,
2 projects have reverted the third-party codefrom the new versions to older versions.
3. 3 Case Study Results
Based on the case study statistics, we answer theraised questions as follows:
RQ1 What is the proportion of out-dated thirdparty code reused in the open source projects?
In this study, 68.3% open source projects are
reusing out-dated third-party code.
RQ2 What are the potential vulnerabilities
caused by such reuse?
Software vulnerabilities of the third-party code
could cause potential vulnerabilities in open
source software. The detailed information
could be checked in NVD. In the case ofreusing zlib, libcurl and libpng, according to
the vulnerabilities descriptions, denial of service and execute arbitrator code are some examples of the potential vulnerabilities.
RQ3 How do developers manage those outdated third-party code?

Broadly speaking, more than a half of the open
source projects did not manage the third-party
very well. Many of them just “copied&pasted”
third-party code to their project without any
modification. A large number of developers only imported third-party code into theirprojects. After those code started working
properly, they left those code alone and did
not tough them anymore. Some projects lostthe version information of the third-party code
and were not able to manage them anymore.
Also, a few projects changed directory names
or mixed the third-party code with their own
code.

4 Discussion
4. 1 Reason for No Updating
We randomly selected 5 user projects that havereused out-dated third-party code, and sent emails
to the project owners to ask for reasons that outdated third-arty code is not updated. 4 of them
have replied to us.
Owner of “openjpeg” project†4 reusing libpng
said, they have notified users that these code arefrom third-party and they do not recommend user
to use these code.
Owner of “mtasa-blue” project†5 reusing libpng
said, they thanked our notification and agreed that
there might be potential vulnerabilities. But they
only update when any problem happens to avoid
introducing new bugs.
Owner of “Angel-engine” project†6 reusing
libpng said, they cannot update because of multiple dependencies and compatibility issues.
Owner of “PCSX2” project†7 reusing zlib said,
they did not have time to go over everything. They
updated the code immediately after reading ouremail and thanked to our contribution.
In our view, what the developers firstly careabout is the functional implements but not the security vulnerabilities. Thus, the priority of updat†4 openjpeg, http://www.openjpeg.org/†5 mtasa-blue,
https://code.google.com/p/mtasa-blue/†6 Angel-engine, https://code.google.com/p/angel-engine/†7 PCSX2, http://pcsx2.net/

Vol. 30 No. 4 Nov. 2013
ing their code would not be high, unless some security problems really happen. Moreover, there arerisks for the developers to update the code currently working, just as mentioned in the case of“mtasa-blue” project.
4. 2 Threat to Validity
Although many vulnerabilities of third-party libraries are reported, the reproducibility depends on
how people reuse code. Taking libpng for example,
many vulnerabilities are reproducible in a conditionof reading a crafted picture. If a user project onlyuses this library to read their own pictures, thesevulnerabilities would not be problems. However, if
the software, such as a web browser, using libpng
library to read pictures from external users, they
have to take these vulnerabilities seriously. Anyway, to use the newer version of the third-party
library would be a safer choice.
Totally 123 projects are studied in this study. Toa certain extent the results from these projects canreflect how open source projects reuse and manage
third-party code. However, as we know, there are
millions of open source projects in the world. The
candidate projects returned by OpenCCFinder are
only in a very small subset of them. These projects
are from Google Code, GitHub, and search[code].
Since we do not know the detailed searching andranking algorithms of those external search engines,
there might be selection bias in this study.
Moreover, currently only the third-party libraries
written in C were studied. It is possible that we will
get diﬀerent results if we study the libraries in otherlanguage or in the form of binary code.

5 Related Work
There are existing researches on third-party evolution impact analysis. Kotonya et al. [3] proposed
approach of assuming a black box view on integrated components. They also use an architecture
description language and process-based approachto manage evolving third-party components. Klatt
et al. [1] coped with the trend of integrating open
source components that provide access to sourcecode and software management information withfurther possibilities for the impact and development
reliability analysis. Clarksen [8] et al. and Bohner[9] used dependency analysis in source code based
impact analysis. However, they mainly focus on the103

third-party components themselves. None of themhad done study on how out-dated third-party codeare reused by the user open source projects.

6 Conclusion
In this paper, we have proposed an approach forstudying the reuse of out-dated third-party sourcecode in open source projects. We have conductedcase studies on zlib, libcurl and libpng libraries
and found that a large proportion of open source
projects are reusing out-dated third-party code,and many of the reused third-party code are notwell managed.
In the future, we would like to develop a support
tool for third-party code version detection, vulnerability prediction and update support.
Acknowledgments This work was supported
by KAKENHI (No.21240002, No.23650015).
References[ 1 ] Klatt, B., Durdik, Z., Koziolek, H., Krogmann,
K., Stammel, J. and Weiss, R.: Identify Impacts ofEvolving Third Party Components on Long-living
Software Systems, in 16th European Conference on
Software Maintenance and Reengineering (CSMR),
2012, pp. 461–464.
[ 2 ] Ebart, C.: Open Source Software in Industry,
IEEE Software, Vol. 25, No. 3(2008), pp. 52–53.
[ 3 ] Kotonya, G. and Hutchinson, J.: Analysing the
Impact of Change in Cots-based Systems, COTSBased Software Systems, 2005, pp. 212–222.
[ 4 ] Inoue, K., Sasaki, Y., Xia, P. and Manabe, Y.:
Where Does This Code Come from and Where Does
It Go?—Integrated Code History Tracker for Open
Source Systems, in Proc. 34th ICSE, 2012, pp. 331–
341.
[ 5 ] National Vulnerability Database. http://nvd.nist.
gov/.
[ 6 ] Xia, P.: An Empirical Study of Out-dated
Third-party Code in Open Source Software, Master’s thesis, Graduate School of Information Scienceand Technology of Osaka University, 2013.
[ 7 ] Xia, P., Manabe, Y., Yoshida, N. and Inoue,K.: Development of a Code Clone Search Tool forOpen Source Repositories, コンピュータソフトウェア,
Vol. 29, No. 3(2012), pp. 181–187.
[ 8 ] Clarkson, J., Simons, C. and Eckert, C.: Predicting Change Propagation in Complex Design,
Journal of Mechanical Design(Transactions of the
ASME ), Vol. 126, No. 5(2004), pp. 788–797.
[ 9 ] Bohner, S.: Extending Software Change Impact
Analysis into Cots Components, in Proceedings ofthe 27th Annual NASA Goddard Software Engi-

コンピュータソフトウェア

104neering Workshop, 2002, pp. 175–182.
[10] Haefliger, S., Krogh, G. and Spaeth, S.: Code
Reuse in Open Source Software, Management Science, Vol. 54, No. 1(2008), pp. 180–193.

吉田則裕

2004 年九州工業大学情報工学部
知能情報工学科卒業．2009 年大阪大学大学院情報科学研究科博士夏沛2010 年年上海交通大学ソフトウェ
ア工学部卒業．2013 年大阪大学
大学院情報科学研究科博士前期課
程修了．在学中、コードクローン
分析やコード再利用に関する研究に従事．現在

GREE に勤務．
松下

後期課程修了．2010 年奈良先端科学技術大学院大学情報科学研究科助教．博士（情報科学）．コードクローン分析手法やリファ
クタリング支援手法に関する研究に従事．ソフ
トウェア科学会，情報処理学会，電子情報通信
学会，人工知能学会，IEEE，ACM 各会員．
井上克郎

誠1993 年大阪大学基礎工学部情報工学科卒業．1998 年同大学大学
院博士後期課程修了．同年同大学
基礎工学部情報工学科助手．2002
年大阪大学大学院情報科学研究科コンピュータサ
イエンス専攻助手．2005 年同専攻助教授．2007
年同専攻准教授．博士（工学）．ソフトウェア
開発環境，リポジトリマイニングの研究に従事．
日本ソフトウェア科学会，ACM 各会員．

1984 年大阪大学大学院基礎工学研究科博士後期課程修了（工学博士）．同年、大阪大学基礎工学部
情報工学科助手．1984〜1986 年、ハワイ大学マノア校コンピュータサイエンス学科助教授．1991 年大阪大学基礎工学部助教授．

1995 年同学部教授．2002 年大阪大学大学院情報科学研究科教授．2011 年 8 月より大阪大学大学
院情報科学研究科研究科長．ソフトウェア工学、
特にコードクローンやコード検索などのプログ
ラム分析や再利用技術の研究に従事．