Abstract
Stallman (2014) has introduced the idea of free-software in a sense of “freedom of choice, not a free
beer”. This essay tried to analyse the utopic idea of free-software through the prism of open-source
software. At this essay, author tried to give a general idea of the security challenges in open and
closed source systems. This study ignored the economic activities of the project (whether the
software developers do it for some sort of benefits or on voluntary basis). Moreover, the paper does
not distinguish between “bazaar-like” and “cathedral-like” style of coding. Furthermore, the study
was based on previous empirical research, and the findings have been summarised. The paper
combines the idea of comparison at the different stage of vulnerability life-cycle, on the contrary to
the classical approach of pros and cons of each software development style; more recent cases of
leakages has been provided.
Introduction
In recent years, open-source software development practices have become increasingly
popular. Users may choose open-source products due to its higher potential in terms of
creativity and flexibility (Fitzgerald, 2006). However, there are some questions whether
open-source systems provide better security practices in comparison to closed-source
systems. In order to address this issue, firstly, this essay will introduce the benchmark
against which the performance will be evaluated. In order to understand the security issues,
the vulnerability life-cycle model has been constructed. A vulnerability is a weakness in code
or other computational logic, found in software or hardware, which can be used by attackers
(U.S. MITRE Corporation). In this essay, the comparison between open-source and closedsource systems on the stages of vulnerability cycle will be provided. Firstly, the explanation
of vulnerability life-cycle will be provided. Then, the injection stage of the cycle in closed and
open-source systems will be examined. Thirdly, the stage of observing and patching will be
observed, mentioning the motivation and practices of both development style. Finally, the
conclusion whether the users should open-source software will be drawn.
Vulnerability life-cycle
Arbaugh, Fithen, and McHugh (2000) stated that during vulnerability the life-cycle new
vulnerabilities can appear at any stage, such as during patching. The life-cycle starts with
injection, at which point vulnerabilities appear in the software. Stallman (2014) claimed that
quite often closed-source companies tend to inject it in order to exploit them. Alternatively,
the issues might appear due to unintentional programming mistakes. Secondly, the
discovery and publication stage takes place. At this stage, vulnerabilities might be identified
accidentally or due to the actively searching. Then, the question whether the vulnerability is
going to be disclosed or not depends on the aims of the detector. If the issue has been
observed by the “good guys”, they may choose not to disclose the vulnerability, so potential
attackers will not have information about the issue. Rescorla (2004) supports the view of
non-disclosure since it was investigated that the probability of the vulnerability being
rediscovered is small. However, Ozment (2005) argued that vulnerabilities have to be
published and solved, since he got results controversial to Rescorla. Additionally, Arbaugh,
Fithen, and McHugh (2000) claim that professional hackers will not leave any trace of their
activities, so such research might be difficult to conduct. Alternatively, Schryen (2011) said
that “bad guys” might have an incentive to share the vulnerability with their peers in order to
increase their respect, or to exploit it for their own good. The next stage of the vulnerability
life-cycle is patching, where developers may want to avoid to publishing the patch, since it
may cause further attacks and damage to their reputation.
Injection stage: Open vs Closed-source
At the stage of injection, there are some advantages of using open-source over closedsource (Cowan, 2003). Open-source software gives its users the rights and possibilities,
which are not available in the proprietary software. For instance, companies may choose to
adopt open-source software in order to achieve better security levels. Hoepman and Jacobs
(2013) claimed that unnecessary parts of the software might be removed, so the lower
complexity of the project will improve security measures. In this regard, the large number of
modifications of the software make it unattractive for attackers (Farooq-i-Azam, 2005). It is
important to note that open-source can be an advantage only in the case when developers
have the right skills to modify the software, otherwise, serious vulnerabilities may occur. To
address these issues, solutions like Git are provided, where more experienced developers
will evaluate the suggested code, although this is time consuming (Lawton, 2002). Viega et
al (2001) suggested that automotive scanners (auditors) may help to speed-up the process.
For such tools, open-source is essential (Cowan, 1998). An example of intentional backdoor
was provided by Macaskill and Dance (2013), saying that Snowden’s leaked information
about the NSA suggested that proprietary software, such as Skype, had backdoors for
surveillance. Recently, it has been reported that Xiaomi has been spying on its customers for
Chinese Government (Nasibov, 2017). It is interesting that the features of Android as an
open-source system allowed users to observe this backdoor. Moreover, Farooq-i-Azam
(2005) stated that the issue of the intentional backdoor by companies may be removed in
case of open-source development since there is a small possibility of the users/participants
to harm themselves. However, there is still an opportunity and incentive in creating
backdoors for other reasons. For instance, Glass (2004) demonstrated the case of the Linux
backdoor attempt in 2003. In the case of “cathedral-style” programming, these issues might
be resolved. In this regard, closed-source might be more difficult to attack, since the
information about the code is hidden (Witten, Landwehr and Caloyannides, 2001). Another
argument in favour of open-source systems is that companies with closed-source
development will tend to follow customer-driven approach. Customers tend not to prioritise
the security issues as the main parameter of consumer decision, therefore consumer
software products lack the security aspect (Franke and von Hippel, 2002). In order to
address this issue, closed-software developers may hire a trustful third party to evaluate the
code, however, it might be expensive. Therefore, companies often avoid using such
services. Alternatively, programmers in the open-source environment will value their own
reputation and mistakes are easier to detect. Also, if the project has a goal to be shared
among the wider range of consumers, a high level of trust is required, so the code in opensource software tends to be more “attractive” (Schryen, 2011). However, careless coding
could occur in the case of closed-source systems as well, since there may be a lack of
motivation for participants. It is also important to identify the difference between open-source
design and open-source code since quite often the issues of the source code are difficult to
observe. Furthermore, it may not be sufficient to keep the system closed-source, since
Mercuri and Neumann (2003) claimed that it might be difficult to keep the system closed in
the long-term. Therefore, closed-sources lose the protectionist advantages of being closedsource without gaining advantages of being open-source.
As mentioned above, in order to comply with open-source ideology, the appropriate
knowledge of the software is required. For instance, the possibility of installation of
unprotected resources may increase the number of vulnerabilities in the Android system in
comparison to IOS (Norton, n.d). Also, different vendors will pay different levels of attention
to security on both the software and hardware side. For instance, the KNOX 2.0 platform
prevents apps running while the phone is off, whereas more budget providers may lack this
feature.
Observation and Patching Stage
It is accepted that security vulnerabilities in open-source software tend to get fixed faster
than similar problems in proprietary software. It could be explained by ”Linus’ Law”: ”Given
enough eyeballs, bugs are shallow” (Raymond, 2000). However, the research of Schryen
(2011) demonstrated that such a difference may not occur, even though there were more
factors to evaluate. There is also evidence supporting the statement that open-source
systems halve the number of vulnerabilities report in comparison to closed-source systems
(Landwehr and Caloyannides, 2001). It could be explained due to the higher level of
bureaucracy in a closed-software environment, which will tend to delay the development.
Also, the fact that only a developer can release the patch in the closed-source environment,
may delay the process time. In the case of open-source, companies are free to design the
patch themselves or to hire the professional of their choice (Stanger, Lane and Danielyan,
2001). Moreover, companies may choose to hide the issues, due to possible reputational
damage or patch schedule. On the other hand, people with monetary incentives may have
higher skills and expectations in bug-fixing activities. Open-source projects are less
concerned about marketability and more about quality controls. Morrison et al (2000)
claimed that some of the open-source users will tend to modify their systems, even though
the developers may try to adjust to market expectations. According to Raymond (2001),
every issue will be identified due to the fact that that problem will be “transparent” to anyone,
so a large number of beta-testers and developers will be able to identify and resolve the
vulnerabilities rapidly. Controversially, Shaikh and Vaast (2016) argued that even though the
open-source development gives an access to the whole source code, it may be difficult to
deeply investigate the code and thus, identify the vulnerabilities. Ranum (n.d) adds that the
percentage of active participants in software development is not sufficient, therefore, ease of
access does not guarantee the effectiveness of the bug-fixing procedures (cited in Lawton,
2002). Viega (2000) added that often users of the service assume that the source code has
been already reviewed by other peers. It is also important to note that even though there is
no possibility in observing the code in proprietary software, there is still a large incentive for
users to identify the issues and report them to the closed software developers. For instance,
Google has a vulnerability report program, in which they provide monetary incentives to
people, who discover the vulnerabilities (Google, n.d). In this regard, individuals have a more
monetary approach rather than a social attachment to the project. However, in this case, the
auditor misses the possibility of checking the exact pieces of work, whereas in open-source
the developer can identify the part of the code that is directly responsible. Also, in the case
of open-source, there is no guarantee that the patch being updated has been approved and
evaluated by the main developers, therefore the issue of trust takes place (Witten, Landwehr
and Caloyannides, 2001).
Schneier (2000) delivered a dilemma whether it is considered a vulnerability if it has not
been investigated. Farooq-i-Azam (2005) claimed that there in closed-source systems, “bad
guys” might investigate the vulnerability, while “good guys” will not have a chance to
investigate it. However, Hoepman and Jacobs (2013) argued that open-source may lead to
an “unfair fight” between the attacker and the defender since in order to attack the system,
only one vulnerability is required, while the defender has to patch all vulnerabilities to provide
maximum security levels. Thus, the ease of identifying vulnerabilities might be either an
argument in favour or against the implication of open-source development. Neumann (2003)
added in the open-source environment, due to its philosophy, any help from the developers
might be appreciated and the revision of the code is secondary. On the other hand, attackers
often deeply discover the source code. Also, the issue of patching not being user-friendly
may exist in open-source. For instance, Stanger (2001) claimed that some open-source
software changes radically, so there is a requirement to reinstall the software in order to
ensure that patch has been applied correctly.
Conclusion
In conclusion, this essay has evaluated the security performance of the open-source
software in comparison to closed-source software. Firstly, it describes the concept of the lifecycle. At this stage, different motivations and reasons can help to identify possible
differences. Then, a more detailed explanation of the key differences between open and
closed-sources has been given. Having evaluated different arguments and case studies, it is
clear that the main issue of the security vulnerabilities in an open-source system is a lack of
experience of the users. Therefore, it may be suggested that open-source products should
be the prerogative of more experienced users. Even though there is a threat of intentional
backdoors from big companies and the lack of freedom occurs in perpetuity software, the
question whether people will need such freedom and liberty arises. From the software
development perspective, it could be suggested that the choice of the development type will
depend on the level of privacy and the skills available. Moreover, the answer to the question
may lie in the ideology that the developer’s team has chosen. However, this essay ignored
the introduction of hybrid software, in which both open and closed-source practices are
applied. Also, more comprehensive research with the comparison of profit and non-profit
based software might be required.
Reference list:
Arbaugh, Fithen, and McHugh (2000) Windows of Vulnerability: A Case Study Analysis.
[online] Available at:
https://pdfs.semanticscholar.org/397a/c5eaf162a07451fc8266242833353774ffd3.pdf
(Accessed at: 20 March 2018)
Cowan, C. (2003) Software security for open-source systems [online]. Available at:
ieeexplore.ieee.org/iel5/8013/26429/01176994.pdf (Accessed at: 22 March 2018)
Farooq-i-Azam, M. (2005) Role of Free and Open-source Software in Computer and Internet
Security. [online] Available at: https://arxiv.org/ftp/arxiv/papers/1610/1610.00640.pdf
(Accessed at: 20 March 2018)
Fitzgerald B. (2006). THE TRANSFORMATION OF OPEN-SOURCE SOFTWARE. [online]
Available at: http://www.idi.ntnu.no/grupper/su/courses/tdt10/curricula2010/P21Fitzgerald06.pdf (Accessed: 22 March 2018)
Franke, N., von Hippel, E. (2002) “Satisfying Heterogeneous User Needs via Innovation
Toolkits: The Case of Apache Security Software” [online]. Available at:
https://evhippel.files.wordpress.com/2013/08/apache-nik-and-eric-hetero-res-pol-b3.pdf.
(Accessed at 22 March 2018)
Glass, R., L. (2004) A Look at the Economics of Open Source. [online]. Available at: http://0delivery.acm.org.pugwash.lib.warwick.ac.uk/10.1145/970000/966409/p25glass.pdf?ip=35.176.47.6&id=966409&acc=ACTIVE%20SERVICE&key=BF07A2EE685417
C5%2E487CE3B0BD082C1B%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35&__acm_
_=1522208857_3898f17624094e47b4222e7ba616671d (Accessed at: 19 March)
Hoepman, J.H., Jacobs, B. (2013) Increased security through open source. [online].
Available at: https://arxiv.org/pdf/0801.3924.pdf (Accessed at: 24 March 2018)
Lawton, G. (2002) Open Source Security: Opportunity or Oxymoron? [online] Available at:
http://0ieeexplore.ieee.org.pugwash.lib.warwick.ac.uk/stamp/stamp.jsp?tp=&arnumber=989921
(Accessed at: 22 March 2018)
Macaskill, E., Dance, G. (2013) NSA files: Decoded. The guardian. [online]. Available at:
https://www.theguardian.com/world/interactive/2013/nov/01/snowden-nsa-files-surveillancerevelations-decoded#section/1 (Accessed at: 23 March)
MITRE (2009). Common vulnerabilities and exposures [online]. Available at:
http://cve.mitre.org (Accessed at: 22 March 2018)
Nasibov, A. (2017) Xiaomi phones secretly sending users' sensitive data to Chinese servers
[online] Available at: https://www.linkedin.com/pulse/xiaomi-phohnes-secretly-sending-userssensitive-data-nasibov-mscm (Accessed at: 23 March)
Neumann, P.,G (2003) Inside Risks: Information system security redux. ACM, 46(10):136
[online]. Available at: http://0eds.b.ebscohost.com.pugwash.lib.warwick.ac.uk/eds/pdfviewer/pdfviewer?vid=1&sid=57f02
19e-b49c-424a-8650-e80ca02cec55%40sessionmgr102 (Accessed at: 23 March)
Ozment, A. (2005) The Likelihood of Vulnerability Rediscovery and the Social Utility of
Vulnerability Hunting. Available at:
https://pdfs.semanticscholar.org/1e83/3bab15a975dd71af5fcbbaed4a8df3a5be8a.pdf
(Accessed at: 21 March 2018)
Rescorla, E. (2004) Is finding security holes a good idea? Available at:
https://www.dtc.umn.edu/weis2004/rescorla.pdf (Accessed at: 23 March 2018)
Schryen, G. (2011) Is Open Source Security a Myth? [online]. Available at: http://0eds.b.ebscohost.com.pugwash.lib.warwick.ac.uk/eds/pdfviewer/pdfviewer?vid=1&sid=5f69e
673-f67c-4fec-ae4b-c182811324ba%40sessionmgr101 (Accessed at: 22 March 2018)
Shaikh, M., Vaast, E. (2016) Folding and Unfolding: Balancing Openness and Transparency
in Open Source Communities. Information Systems Research. v. 27. no. 4. [online]
Available at: https://0-pubsonline-informsorg.pugwash.lib.warwick.ac.uk/doi/pdf/10.1287/isre.2016.0646 (Accessed at: 23 March
2018)
Stallman, R (2014) Free software, free society: Richard Stallman at TEDxGeneva. [online]
Available at: https://www.youtube.com/watch?v=Ag1AKIl_2GM (Accessed at: 18 March
2018)
Stanger, J., Lane, P.T. and Danielyan, E. (2001) Hack Proofing Linux: A Guide to Opensource Security. Elsevier Science & Technology. [online] Available at:
https://ebookcentral.proquest.com/lib/warw/reader.action?docID=294152&query= (Accessed
at: 21 March 2018)
Viega J. (2001) A Static Vulnerability Scanner for C and C++ Code. [online]. Available at:
https://www.acsac.org/2000/papers/78.pdf (Accessed at: 21 March 2018)
Witten, B., Landwehr, C., Caloyannides, M. (2001) Does Open Source Improve System
Security? [online]. Available at: http://www.landwehr.org/2001-09-witten-caloyannides.pdf
(Accessed at: 18 March)
Norton (n.d) Android vs iOS: Which is more secure? [online]. Available at:
https://us.norton.com/internetsecurity-mobile-android-vs-ios-which-is-more-secure.html
(Accessed at: 25 March 2018)
Raymond E., S (2001) The Cathedral & the Bazaar: Musings on Linux and Open
Source by an Accidental Revolutionary. USA: O'Reilly Media, Inc. [online]. Available
at:
https://books.google.co.uk/books?id=F6qgFtLwpJgC&dq=Raymond,+E.S.+The+Cat
hedral+and+the+Bazaar:&hl=ru&source=gbs_navlinks_s (Accessed at: 17 March
2018