• No results found

Security Guidelines for the Usage of Open Source Software

N/A
N/A
Protected

Academic year: 2022

Share "Security Guidelines for the Usage of Open Source Software"

Copied!
138
0
0

Loading.... (view fulltext now)

Full text

(1)

INOM

EXAMENSARBETE TEKNIK, GRUNDNIVÅ, 15 HP

,

STOCKHOLM SVERIGE 2020

Security Guidelines for the Usage of Open Source

Software

SEBASTIAN DOMAR BOLMSTAM

SIAVASH HANIFI

(2)
(3)

Abstract

Open-source software is in average used in more than 65% of the applications within the domains of enterprise software, retail and e-commerce, cyberse- curity and internet of things (Synopsys, 2019). With the frequent use of open-source software, security issues arise which need to be handled. These include among other issues; non-patched vulnerabilities and malicious code (Schryen, 2011). Security guidelines for open-source software usage have been defined by numerous security organizations as an effort to increase effective security handling of open source software within organizations. These guide- lines often cover directives on many layers of an organization and are often lacking information necessary for them to be understandable, reliable, and useful to the person using them.

The purpose of this study is to contribute to increased software security re- lated to open-source software usage, by exploring and providing information on the topic, and by defining a set of improved security guidelines that cover both what measures to take to minimize security risks, and how to imple- ment it, based on the published state-of-the-art security guidelines for using open-source software.

The subject was investigated through a research process focused on answering whether the current state-of-the-art security guidelines could be improved, using a qualitative research type based on a document analysis data collec- tion method. The research was exploratory in its design and the main focus was to explore the subject by trying to answer the posed research question.

By investigating the state of contemporary security guidelines found in lit-

erature, and evaluating them against a set of desirable attributes for high

quality guidelines, it became evident that the contemporary guidelines could

(4)

be improved. An effort was therefore made to build on the found guidelines and improve them by trying to resolve the issues found through the evalua- tion.

The effort of trying to improve existing guidelines resulted in a new set of guidelines including added information and reformulations, however, the changes made could not be said to be conclusive or objective improvements.

Instead they present suggestions for how and in what aspects the contempo- rary guidelines could be improved.

Keywords:

Open Source (OS), Open Source Software (OSS), Security Guideline (SG),

Open Source Software Security

(5)

Sammanfattning

Mjukvara med ¨ oppen k¨ allkod (open-source software) anv¨ ands i genomsnitt i mer ¨ an 65% av applikationerna f¨ or mjukvara till f¨ oretag, detalj- och e- handel, cybers¨ akerhet och sakernas internet (Synopsys, 2019). Den frekventa anv¨ andningen av ¨ oppen k¨ allkod ger upphov till s¨ akerhetsrisker som beh¨ over motverkas. Dessa risker inkluderar bland annat; skadlig kod och s¨ akerhets- brister som inte ˚ atg¨ ardas (Schryen, 2011). S¨ akerhetsriktlinjer har blivit definierade av ett flertal organisationer med m˚ alet att effektivisera s¨ aker- hetshanteringen av ¨ oppen k¨ allkod och p˚ a s˚ a s¨ att minska risken f¨ or attacker.

Dessa riktlinjer t¨ acker ofta m˚ anga olika delar av en organisations hierarki och saknar ofta information som ¨ ar n¨ odv¨ andig f¨ or att g¨ ora dem begripliga, p˚ alitliga och anv¨ andbara f¨ or de personer som anv¨ ander dem.

Syftet med denna studie ¨ ar att bidra till en ¨ okad s¨ akerhet vid anv¨ andan- det av ¨ oppen k¨ allkod genom att dels ¨ oka kunskapen om ¨ amnet, och genom att definiera en samling f¨ orb¨ attrade s¨ akerhetsriktlinjer som b˚ ade beskriver vad som ska g¨ oras f¨ or att minska s¨ akerhetsrisker och hur det ska g¨ oras.

De f¨ orb¨ attrade riktlinjerna ska baseras p˚ a befintliga s¨ akerhetsriktlinjer f¨ or anv¨ andning av ¨ oppen k¨ allkod.

Amnet studerades genom en forskningsprocess med fokus p˚ ¨ a att besvara fr˚ agan om huruvida befintliga s¨ akerhetsriktlinjer kan f¨ orb¨ attras, d¨ ar infor- mation samlades in genom en kvalitativ forskningstyp baserad p˚ a dokumen- tanalys. Forskningsdesignen var av utforskande karakt¨ ar, d¨ ar huvudfokuset l˚ ag i att utforska ¨ amnet genom att f¨ ors¨ oka besvara forskningsfr˚ agan.

Genom att unders¨ oka kvalit´ en av befintliga s¨ akerhetsriktlinjer som hittats

i litteraturen och utv¨ ardera dessa med st¨ od av en stor samling ¨ onskv¨ arda

egenskaper hos riktlinjer av h¨ og kvalitet, blev det uppenbart att befintliga

(6)

riktlinjer kan f¨ orb¨ attras. D¨ af¨ or genomf¨ ordes ett f¨ ors¨ ok att vidareutveckla befintliga riktlinjer f¨ or att f¨ orb¨ attra dem genom att l¨ osa de problem som hittats genom utv¨ arderingen.

F¨ ors¨ oket att f¨ orb¨ attra existerande riktlinjer resulterade i en ny upps¨ attning riktlinjer med tillagd information och omformuleringar. Dessa f¨ or¨ andringar kan dock inte s¨ agas representera konklusiva eller objectiva f¨ orb¨ attringar.

Ist¨ allet representerar de f¨ orb¨ attrade riktlinjerna ett f¨ orslag p˚ a hur riktlin- jer skulle kunna f¨ orb¨ attras.

Keywords:

Oppen K¨ ¨ allkod, Mjukvara med ¨ Oppen K¨ allkod, S¨ akerhetsriktlinje, S¨ akerhet

f¨ or ¨ Oppen K¨ allkod

(7)

Contents

1 Introduction 1

1.1 Background . . . . 2

1.2 Problem . . . . 2

1.3 Purpose . . . . 3

1.4 Goal . . . . 3

1.5 Research Method . . . . 3

1.6 Commissioned Work . . . . 3

1.7 Target Audience . . . . 4

1.8 Scope and Limitations . . . . 4

1.9 Terminology . . . . 5

1.10 Benefits, Ethics and Sustainability . . . . 5

1.10.1 Social Benefits . . . . 6

1.10.2 Ethics . . . . 6

1.10.3 Sustainability . . . . 6

1.11 Thesis Outline . . . . 7

2 Extended Background 9 2.1 Software Security and Risks . . . . 9

2.2 Open Source Software . . . . 10

2.2.1 Definition of Open Source Software . . . . 10

2.2.2 Open Source Licenses . . . . 12

2.2.3 Platforms and Providers . . . . 13

2.2.4 By Who and How Is It Used? . . . . 14

2.2.5 Open Source Software and Security Risks . . . . 14

2.3 Closed Source Software . . . . 15

2.3.1 Where Is It Found and Who Provides It? . . . . 15

2.3.2 How Is It Used? . . . . 16

2.3.3 Closed Source Software and Security Risks . . . . 16

(8)

2.4 Benefits and Drawbacks of Open Source Software . . . . 16

2.5 Security Guidelines for OSS Usage . . . . 18

2.5.1 Providers and Authors . . . . 19

2.5.2 Covered Security Areas . . . . 19

2.6 Guideline Recommendations . . . . 20

2.6.1 Traits of a Good set of Guidelines . . . . 21

3 Research Methodology 23 3.1 Choice of Methodology . . . . 24

3.1.1 Research Question . . . . 25

3.1.2 Required Data . . . . 25

3.1.3 Choice of Research Type . . . . 25

3.1.4 Research Tools . . . . 27

3.1.5 Evaluation . . . . 27

3.2 Research Process and Phases . . . . 28

3.2.1 Information Gathering and Analysis Phase . . . . 29

3.2.2 Evaluation Criteria Definition Phase . . . . 30

3.2.3 Problem Identification Phase . . . . 31

3.2.4 Guideline Improvement Phase . . . . 31

3.2.5 Evaluation Phase . . . . 32

3.3 Suitability of Research Approach and Research Validity . . . . 33

3.3.1 Suitability of Research Approach . . . . 33

3.3.2 Research Validity . . . . 33

4 Results 35 4.1 Gathered Information . . . . 35

4.1.1 Security Guidelines for OSS Usage . . . . 35

4.1.2 Guideline Recommendations . . . . 37

4.2 Evaluation Criteria . . . . 39

4.3 Issues Identified in Existing Guidelines . . . . 42

4.3.1 Results of Synopsys Guideline Evaluation . . . . 43

4.3.2 Results of Iron Bastion Guideline Evaluation . . . . 44

4.3.3 Results of Michael Cobb’s Guideline Evaluation . . . . 46

4.3.4 Results of CSPS Guideline Evaluation . . . . 48

4.4 Guideline Improvements . . . . 50

4.5 Result of Final Evaluation . . . . 52

5 Analysis and Discussion 55

(9)

5.1 Result Analysis . . . . 55

5.1.1 Analysis of Information Gathering . . . . 55

5.1.2 Analysis of Evaluation Criteria . . . . 56

5.1.3 Problem Analysis . . . . 57

5.1.4 Analysis of Improvements . . . . 57

5.1.5 Analysis of Final Evaluation . . . . 57

5.2 Analysis of the Chosen Research Method and Research Out- comes . . . . 58

5.2.1 Management of Validity Threats . . . . 59

6 Conclusion and Future Work 61 6.1 Future Work . . . . 62

A Security Guidelines for OSS Usage 67 A.1 Synopsys Security Guidelines . . . . 67

A.2 Iron Bastion Security Guidelines . . . . 69

A.3 Michael Cobb Security Guidelines . . . . 70

A.4 CSPS Security Guidelines developed for the Ministry of Trans- portation and Communications Qatar . . . . 71

B Record of Evaluation Criterion Selection Process 75 C Detailed Evaluation Protocols 93 C.1 Protocol for Synopsys Guideline Evaluation . . . . 93

C.2 Protocol for Iron Bastion Guideline Evaluation . . . . 96

C.3 Protocol for Michael Cobb’s Guideline Evaluation . . . . 99

C.4 Protocol for Q-CERT Guideline Evaluation . . . 102

C.5 Protocol for Improved Guideline Evaluation . . . 105

D Improved Security Guidelines 109 D.1 Reason for Creating this Document . . . 109

D.2 Founding and Support . . . 109

D.3 Objectives . . . 109

D.4 Sources of Information . . . 110

D.5 Method used to formulate recommendations . . . 110

D.6 Limitation and Scope . . . 110

D.7 Pilot-Test . . . 110

D.8 The Security Guidelines for OSS usage - Overview . . . 111

(10)

D.8.1 Organizational Governance . . . 111

D.8.2 Licensing . . . 111

D.8.3 Software Security . . . 112

D.8.4 OSS Health . . . 117

E Pilot-test: Project X 119

(11)

Chapter 1 Introduction

In a society with freedom of speech, anyone can write a book and make statements on how to solve problems. If we follow these statements without questioning their credibility and ideas we are bound to be subjects of ma- nipulation or misinformation. Open source software (OSS) can be similar to a book in these aspects (Schryen, 2011). One affects computer software and the other affects people. A book might misinform a person, an open source library might infect a program with malicious code or expose it to attackers.

With the significant amount of OSS used in applications today, the need for guidelines for assessing the security of using them has increased (Synopsys, 2019). This is of the utmost importance in organizations and stately au- thorities that handle sensitive data. A single line of code in the midst of thousands of lines can be malicious and seek to manipulate or leak data.

Even if the authors of the OSS have no intentions of harming their users, if they do not patch technologies whose vulnerabilities become known, they indirectly expose the users for attacks.

There are published security guidelines for the usage of OSS provided by companies, organizations and experts within the field of software security.

However, many of the published security guidelines fail to provide necessary information to be fully understandable or to establish reliability and usabil- ity for the user, which could lead to inefficiency and many times confusion.

In extension, this could potentially result in dire consequences when entire

software systems within organizations could be compromised due to a mis-

understanding or an overseen security threat.

(12)

Furthermore, low quality security guidelines could potentially contribute to adding fuel to the flames regarding poor security within OSS, and thereby intimidate organizations from using OSS, thus missing the opportunity to utilize powerful, easily accessible, and oftentimes well supported software.

1.1 Background

The characteristics of the open source development process makes it prone to security risks. Since the development process is defined by granting permis- sion to any volunteer to modify and redistribute the software (opensource.org, 2007), there can be no guarantees that all contributors have good intentions (or that they are skilled enough to implement secure code).

The security risks that come with the usage of OSS could pose a great threat when used within organizations handling sensitive data. Devastating conse- quences have been the result for numerous organizations when sensitive data has been leaked. By identifying the potential risks and providing relevant actors within organizations with guidelines for how to handle them, the ben- efits of using open source software could be utilized more efficiently and the risks be reduced. The question is; could the contemporary security guidelines for open source software usage be improved?

1.2 Problem

The problem in focus on this study is that many contemporary security guide-

lines for open source software usage do not provide necessary and complete

information on how they were developed, what evidence certain recommen-

dations are based on, explicit descriptions of whom the intended users are,

what the users should do, and how to do it.

(13)

1.3 Purpose

The purpose of this study, based on the definition of effect goals (effektm˚ al) in Eklund (2011), is to contribute to increased software security related to the usage of open source software, by highlighting flaws in the current best practice recommendations for how to handle security risks and by providing a proposal of improved security guidelines.

1.4 Goal

The goal of this study, based on the definition of performance goals (resul- tatm˚ al) in Eklund (2011), is to identify strengths and weaknesses in contem- porary security guidelines and propose improvements based on the findings in the form of an improved set of guidelines for open source software usage.

1.5 Research Method

With consideration to the limitation of this work and the nature of the re- search question, the research method for this study was based on a qualitative methodology using an exploratory research design. This could be described as an approach where the understanding of the subject in focus is successively expanded throughout the study with the end-goal to explore the research topic. This is done through a process guided by the effort of trying to an- swer the research question; Could the contemporary security guidelines for open source software usage be improved?.

1.6 Commissioned Work

The Swedish Transport Administration (STA), is a public authority respon-

sible for long-term planning of infrastructure as well as building, operating

and maintaining public roads and railways. The IT-department at STA im-

plements a micro-service architecture that over time has grown more and

more complex through continuous development and added micro-services,

and a need of a visualization tool has been identified. Therefore, STA has

commissioned us to develop a visualization tool referred to as Project X (to

(14)

not disclose the actual name) that should provide an overview of their archi- tecture, show dependencies and usage in the system, and increase the general knowledge of the system amongst all employees. The visualization tool was dependent two third party open source libraries supplying an API for man- aging network graph, these are referred to as OSS X and OSS Y.

Since STA is a public authority that handles sensitive data and infrastructure operations, the libraries used need to guarantee a high level of security before getting introduced to their system. Because of this an interest for security guidelines for open source software usage has emerged within STA.

The commissioned work and the study described in this thesis are not very strongly connected, thus no technical details of Project X will be provided.

However, the improved guidelines produced from this study were pilot-tested on Project X so that it’s security-state could be evaluated. The results from this pilot-test are described in Appendix E with certain sensitive information censored as requested by our supervisor at STA.

1.7 Target Audience

The target audience for this study includes any person that might use open source software or seeks to learn more about the domain. Mainly this in- cludes students, researchers and actors within organizations that produce or maintain software.

1.8 Scope and Limitations

This study focuses on the textual contents of contemporary security guide-

lines, that is, the quality and coverage of information, which represents a

first barrier to using the guidelines. The thesis does not explore the impact

or effectiveness of guidelines, since this would require extensive research and

comparison over a longer period of time which is beyond the capabilities and

resources available. Instead, the claims of expertise authors of the contem-

porary guidelines is at this point regarded to be reliable in terms of impact.

(15)

It would be reasonable to assume that different companies and organisations might have their own in-house security guidelines for OSS usage, guidelines that are customized for their needs. However, extracting this information for a representative set of companies is deemed to be outside the scope of this research. Therefore, this research will focus on general security guidelines extracted from public sources, that still could represent a basis which could be further customized for specific contexts.

Although aspects of open source software other than security might be dis- cussed for context, the main focus of the research is the security aspects and the study will disregard other potential flaws in software.

1.9 Terminology

The keywords and what we mean when we use them throughout this thesis are listed below:

• Open Source Software - OSS - Applications, frameworks and libraries whose source code is publicly available.

• Closed Source Software - CSS - Applications, frameworks and libraries whose source code is publicly unavailable.

• Security Guideline - Information encouraging or discouraging certain action or behaviour with the purpose to increase security. In this thesis the focus is on security related to OSS usage, thus what we mean with security guidelines is really Security Guidelines for OSS usage.

• Guideline Recommendations - Information describing what attributes guidelines ought to have in order to be ”good”. The word recommen- dations might be used for short in some cases.

1.10 Benefits, Ethics and Sustainability

Social benefit is the total benefit to society from producing or consuming a

good/service. Social benefit includes all the private benefits plus any exter-

nal benefits of production/consumption. If a good has significant external

benefits, then the social benefit will be greater than the private benefit.

(16)

The beneficial, ethical and sustainability-related effects of this research are described in this section. Section 1.10.1 - Social Benefits covers potential positive and negative social effects of the research. Section 1.10.2 - Ethics, covers the ethical considerations related to the research and the content of this thesis, and Section 1.10.3 - Sustainability presents the potential sustain- ability effects this work might have.

1.10.1 Social Benefits

The potential social benefits of this work were identified to be related to com- munication and effectiveness. By relying on the set of guidelines collected and improved through this study, a developer could argue for and against the use of a certain OSS. This could imply utilization of powerful function- ality without having to ”reinvent the wheel” and prevent the introduction of vulnerabilities.

1.10.2 Ethics

Since this study is based on a qualitative research methodology which largely relies on previous studies and research work, it is important to credit the sources from which the information is gathered. This is done throughout the thesis by referencing the sources when used in text.

Regarding the commissioned work conducted in parallel to the research, there might be some ethical issues related to confidentiality. Therefore, the con- tents of this thesis have been revised by STA employees to ensure that no confidential material has been disclosed.

1.10.3 Sustainability

The results gathered in this study might contribute to a more sustainable

usage of technology and resources, reducing the need for reinventing the wheel

and increasing lifespan and quality of open source technologies.

(17)

1.11 Thesis Outline

The contents of this thesis in short are:

• Chapter 2 - Extended Background - This chapter provides an overview of existing work in the field. The information presented here is relied upon in the research process described in Chapter 3. The gathered results are also largely based on the information covered in this chapter.

• Chapter 3 - Research Methodology - This chapter presents the research methodology, methods used for collecting and analyzing data and tools used when we conducted our study.

• Chapter 4 - Results - This chapter presents the findings obtained from conducting our study.

• Chapter 5 - Analysis and Discussion - This chapter analyses and dis- cusses the findings presented in the result chapter.

• Chapter 6 - Conclusion and Future Work - This chapter summarizes

the study and describes how future work might be conducted to increase

our understanding of the domain.

(18)
(19)

Chapter 2

Extended Background

To understand the problem in focus for this study, it is necessary to under- stand the domain and the current state of research. This chapter aims to lay the ground on which this study stands. Section 2.1 - Software Security and Risks, describes what software security is and what it’s risks and their countermeasures are. Section 2.2 - Open Source Software, explains the back- ground of OSS and relates it to software security risks. Similarly Section 2.3 - Closed Source Software, explains the background of CSS and how it relates to software security risks. Section 2.4 - Benefits and Drawbacks of Open Source Software, explains the strengths and weaknesses of OSS in com- parison to CSS. Section 2.5 Security Guidelines for OSS Usage, provides an overview of the contemporary published security guidelines for OSS usage by describing what they look like, which areas they cover and who their authors are. Section 2.6 - Guideline Recommendations, explains the contemporary guideline recommendations.

2.1 Software Security and Risks

The topic of software security is broad, complex and ever evolving, to a point

where it might be overwhelming to account for all aspects of it. One general

definition of software security is that it is the idea of protecting software

from different types of malicious attacks aimed to compromise integrity, au-

thentication and availability, to ensure continuous, proper and intended func-

tionality (Oliinyk, 2019b). Gollmann (2011) stresses the difference between

software security and software reliability, where reliability could be degraded

(20)

by mistakes on a developer’s behalf, resulting in unwanted behaviour. Secu- rity, on the other hand, is an effort to prevent attackers from intentionally compromising the system in some way. The main difference in how reliability degradation are tackled compared to security threats, is that mistakes made by the developers could easily be tested with traditional testing methods, while testing for security threats needs to cover more atypical usage pat- terns, which makes it harder to accomplish.

While there are many ways of detecting a security vulnerability such as code review, analysis tools, and in the worst case scenario, by actually being at- tacked, it is imperative for developers to be aware of the risks and how to protect against them. It is, however, a daunting if not impossible objective to achieve this awareness of all security threats, their causes and consequences.

Examples of the most prevalent security threats, their causes, consequences and remedies are well described in a paper published by van der Stock, Glas, Smithline, and Gigler (2017). See references for a link to the paper.

2.2 Open Source Software

Throughout this section, the concept of OSS is presented through a definition of what it is in Section 2.2.1 - Definition of Open Source Software, an overview of OSS licenses in Section 2.2.2, information on who provides it and who uses it in Section 2.2.3 - Platforms and Providers and Section 2.2.4 - The security aspects of OSS is described in Section 2.2.5.

2.2.1 Definition of Open Source Software

OSS is a type of software that is distinguished by the way that it is developed, maintained and distributed, where all source code is kept publicly visible for anyone to inspect, modify and enhance (opensource.com, 2020).

The idea evolved in the 1970’s as a opposition towards companies selling

compiled programs that were designed and tailored for specific purposes,

which did not fully satisfy the different needs of all customers (Buxmann,

Diefenbach, & Hess, 2012). By opening up the source code for the public,

users of the software could actively contribute to the software evolution by

(21)

implementing the specific use cases they them self sought, and at the same time contributing to fixing bugs and enhancing the software in general (ibid).

In this way, different OSS projects attracted communities of developers that voluntarily and collaboratively produced flexible often high quality software.

The term ”Open Source” was coined in the 1990s, when the Open Source Ini- tiative (OSI) was founded. This non-profit corporation established a defining list of criteria that a project needs to fulfill to classified as open source:

1. Free Distribution: The license shall not restrict any party from sell- ing or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The li- cense shall not require a royalty or other fee for such sale.

2. Source Code: The program must include source code, and must al- low distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Inter- net without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfus- cated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

3. Derived Work: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

4. Integrity of The Author’s Source Code: The license may restrict source-code from being distributed in modified form only if the license allows the distribution of ”patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

5. No Discrimination Against Persons or Groups: The license must

not discriminate against any person or group of persons.

(22)

6. No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of License: The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

8. License Must Not Be Specific to a Product: The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. License Must Not Restrict Other Software: The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

10. License Must Be Technology-Neutral: No provision of the license may be predicated on any individual technology or style of interface (opensource.org, 2007).

2.2.2 Open Source Licenses

All software that claim to be open source should have a license attached to them, proclaiming permission for anyone to use, modify and share the software. For a license to be valid under the OSI regulations, the OSI needs to review and approve the license (opensource.org, 2007). There are many licenses that could be used that include different conditions and restrictions.

The users of OSS need to be aware of and abide to these restriction to lawfully

make use of the software. The most popular used licenses that are recurring

in many project are:

(23)

• Apache License 2.0

• BSD 3-clause ”new” or ”revised” License

• BSD 2-clause ”simplified” or ”freeBSD” License

• GNU General Public License (GPL)

• GNU Library or ”Lesser” General Public License (LGPL)

• MIT License (x11 License)

• Mozilla Public License 2.0

• Common Development and Distribution License

• Eclipse Public License version 2.0 (ibid)

2.2.3 Platforms and Providers

OSS are typically provided through public repositories (Hasan, 2017). These repositories usually hold the source code of the software and relevant files that describe the project and provides licensing information. The repositories can be hosted by any repository provider for example GitHub or SourceForge (ibid).

Since OSS are often developed and evolved through a collaboration of in- dividual developers that share an interest in the project, it might be hard to pinpoint the provider to one single organization, group or person. How- ever, there are cases where organizations or groups of developers initiate a project and restrict external developers from contributing to the code (Ray- mond, 2001). This form of approach within an open source project is called Cathedral style, whereas the alternative of Bazaar style allows anyone to also contribute to the code (ibid).

In the same way that cathedral style projects have distinct providers, many

bazaar style projects could be seen to have distinct providers. Even though

bazaar style allows for anyone to contribute, many projects keeps a structure

with project leaders, core members and peripheral members (Crowston et

al., 2016), where the project leaders and core members could be viewed as

the providers.

(24)

2.2.4 By Who and How Is It Used?

OSS is used by a broad spectrum of developers (Synopsys, 2019). Ranging from enterprise employees to hobby programmers, OSS is used to interlace technologies so that reinvention of the wheel can be avoided (Dikbas, Ergen,

& Giritli, 2009).

OSS-based applications pervade our whole society. In an audit made by Black Duck Audit Service and reported by Synopsys (2019), where over 1200 commercial code-bases from different fields of business were scanned for open source software, over 96% of the code-bases were found to include some open source software.

The interlacing of technologies is usually made by either importing OSS in the form of libraries or adding finished applications to systems. Software developers that see the need of certain functionality for their projects can thus try to find OSS to provide them with this functionality.

2.2.5 Open Source Software and Security Risks

Since OSS differ from other types of software only in how it is developed, and how it is distributed, it is subject to the same technical security vulner- abilities as any other software. Regardless of this, software security within OSS has been a controversial topic (Schryen, 2011).

Since the openness and transparency of OSS do not discriminate against any person, actors that are looking for ways to exploit software vulnerabilities for malicious conduct does also have full access to the source code. This implies that if an attacker finds a vulnerability that has not been patched, the vulnerability could be exploited to launch attacks against all users of the software as long as the vulnerability remains unresolved (Levy, 2000).

Furthermore, even if a vulnerability would be found and reported by a per-

son with good intentions, the reporting effectively disclose the vulnerability

for any attacker to exploit which means that even reporting an issue could

increase the risks of an attack. With this in mind, the OSS community needs

to be quick to act when a vulnerability is reported, and make sure that the

security risk is terminated before causing harm (Schryen, 2011).

(25)

Even though OSS licenses are typically permissive to allow users the freedom to alter the software and redistribute it as a part of a commercial product, it does represents a legal risk when using OSS within an organization. If the licenses applied to an open source project is not thoroughly investigated by the user, the organization might be at risk of overstepping restrictions and thereby legal repercussions.

The perceived security threats related to OSS (both real and exaggerated), often tends to make organizations opt for more secure alternatives. How- ever, viewing OSS as more prone to security vulnerabilities in comparison to proprietary code might be a mistake. In a report posted by Synopsis Cyber- security Research Center (Synopsys, 2019), a claim is made that proprietary code is no more secure than OSS, and that the main cause of security risks is the lacking drive within organizations to apply patches to resolve vulner- abilities. Furthermore, the report claims that the main difference between OSS and commercial software is the distribution of responsibilities. While commercial software providers could detect vulnerabilities, patch them, and then push the patched code to a customer as an update, OSS users needs to manage the updates by actively pulling the patched software when an update is made.

2.3 Closed Source Software

The opposite of OSS is called closed source software, or proprietary software.

Whereas the OSS source code is published for anyone to use, modify and distribute, CSS source code is known only to the original authors and kept secret and protected. The actors developing the CSS are in full control of the source code, the software development and maintenance, and the software is only provided to paying customers as a compiled program (Oliinyk, 2019a).

2.3.1 Where Is It Found and Who Provides It?

CSS is provided by companies with commercial incentives to develop and

distribute software functionality to authorized and paying users. If a need

of certain functionality emerges, the user reaches out to a provider with

a suitable solutions and an agreement is made to use their product under

restrictive licensing rules (Saltis, 2020).

(26)

2.3.2 How Is It Used?

The user purchases the product as is, and does not have access to the source code. Therefore, the user can not implement changes to the product to better accommodate their needs. Instead, all requirements and issues of the software need to be reported to the provider support service for further processing.

2.3.3 Closed Source Software and Security Risks

While OSS security relies on the project community to find and fix security vulnerabilities, vulnerabilities within CSS could only be fixed by the vendor.

If a user of the program suspect that an attack has been launched on their system, using vulnerabilities in the CSS, the user needs to report this to the vendor and wait for the problem to be solved (Oliinyk, 2019b). The strengths related to CSS and security is that potential vulnerabilities within the software will be harder for an attacker to find and exploit, since the source code is kept secret. The case might also be made, that the personnel hired to develop and maintain the CSS has greater knowledge of the software than a random contributor to OSS might have, and that expertise might indicate a higher code quality.

2.4 Benefits and Drawbacks of Open Source Software

OSS oftentimes seems to have a dual nature, where many of the aspects that makes it a really powerful and flexible approach towards software develop- ment, also presents equal but opposite effects. There are several benefits to opting for OSS instead of proprietary software, however, there are also a number of disadvantages that needs to be considered. In this section, the benefits and drawbacks of OSS with regard to security, cost, quality and us- ability is presented under corresponding headline.

Security: Within OSS communities, volunteering developers continually re-

view the code to find improvements, bugs and vulnerabilities. If a vulnera-

bility is found it is typically reported along with proposals of improvements

or a completed patch to resolve the issue. In this way, numerous developers

could contribute to finding and resolving security vulnerabilities and thereby

(27)

improving the general security in the software. Proponents of OSS develop- ment claim that the larger the community and public access to source code is, the higher rate of vulnerability detection and patching will be. This phe- nomenon is called ”Linus’s law” by Raymond (2001) as he puts it: ”Given enough eyeballs, all bugs are shallow.”.

OSS does have a strength in numbers if the project community is big enough, where a potentially huge number of developers could contribute to code re- view and debugging. Compared to CSS having relatively limited resources in regard to manpower, OSS does have a better chance of finding and elimi- nating security risks at a faster rate. The transparency of OSS also provides a chance for a potential user to review the code and make decisions based on found and reported security issues before deciding to use the software, which might not be the case with CSS (Bromhead, 2017).

The major issue of OSS with regard to security is the fact that potential at- tackers have access to the source code, which enables them to both find and exploit existing vulnerabilities, and potentially introduce new vulnerabilities by building it into new functionality and hope that it is not detected in the review process(Schryen, 2011).

Cost: One great advantage of OSS is the low, or non-existing cost of using it.

This is first and foremost related to the initial acquirement of the software, where the software is usually completely free, whereas CSS software could cost thousands of dollars to acquire. The same functionality gained from the OSS could of course be implemented in-house, however, this would generate big time and personnel costs (Bromhead, 2017).

It would, however, be wrong to expect OSS to be completely free in the long run. Acquiring an OSS could come with some extra efforts, such as tailoring it to fit the specific context, continuously monitor changes and adapt there- after, and possibly hire expertise staff for managing certain parts of the OSS.

This also generates costs that needs to be considered (dcomisso, 2016).

Quality: The case could be made, that the crowd attracted to OSS com-

munities to a great extent is highly knowledgeable within their fields, which

would be an indication of high quality code being produced. Furthermore,

the rapid pace at which many OSS evolve through contributions of sometimes

(28)

thousands of developers is a good environment to quickly improve the code quality if proper and rigorous review is being applied (Bromhead, 2017).

The downside of OSS in regard to quality is the often lacking structure of the projects and the work being done. There are often no explicit processes or methods in place to guarantee high quality and proper documentation (blogs.worldbank.org, n.d.).

Usability: Perhaps the greatest benefit of using open source software is the flexibility it grants. A user with specific requirements could easily cus- tomize the open source software to better suit their needs, compared to closed source software, where a program that fits perfectly to the specific require- ments could prove hard to find. Urging a vendor to change the software to accommodate the specific needs could also be an expensive and time con- suming process (Regoli, 2015).

OSS communities and forums often provides information on how to use the software and how to contribute, which for an experienced user makes it very easy to get started. However, the information given is often aimed towards the experienced users, and it might not be enough for novices (ibid).

2.5 Security Guidelines for OSS Usage

By providing developers with security guidelines, the risks of OSS usage ei- ther getting totally ignored or some important aspects getting overlooked can be reduced (Broughton & Rathbone, 2001).

Even though security related to open source software use is a controversial topic, few empirical studies have been conducted on the subject (Schryen, 2011). The same seems to hold for security guidelines for OSS usage. The security guidelines that can be found throughout different internet forums, blogs and reports, do not seem to be based on scientific research, but instead on a set of commonly agreed upon best practices.

Security guidelines for OSS usage can be found in different reports and ar- ticles, these come in varying formats and cover security areas differently.

Security areas can be seen as divisions of security based on specific domains

(29)

or aspects, such as license risks or software vulnerabilities. Section 2.5.1 - Providers and Authors describes the backgrounds of the found security guidelines. Section 2.5.2 - Covered Security Areas explains which security areas the security guidelines cover.

2.5.1 Providers and Authors

Guidelines and best practices related to OSS security can be found in vari- ous reports provided by organizations specialized in software security and in articles written by experts.

Synopsys Cybersecurity Research Center (CyRC) provides six guidelines in their report on OSS security (Synopsys, 2019). They are a part of the Synop- sys enterprise and publish research supporting strong cybersecurity practices (Cybersecurity Research Center (CyRC) | Synopsys, n.d.).

The Qatar Computer Emergency Response Team (Q-CERT) is a national, government sponsored organization setup under the auspices of Qatar’s Min- istry of Transport and Communications (qcert.org, n.d.). They have devel- oped the security guidelines for OSS usage presented in CSPS (2018).

Another set of security guidelines for OSS usage is provided by Michael Cobb, a renowned security author with over 20 years of experience in the IT indus- try (Cobb, 2012). An Australian company, Iron Bastion, provides informa- tion on how to approach OSS usage securely (blog.ironbastion.com.au, 2019).

The company is specialized in cyber security and provides services protecting against different digital threats.

Links to the reports or articles are included in the references.

2.5.2 Covered Security Areas

The guidelines briefly presented in Section 2.5.1 - Providers and Authors all

contains directives that could be assigned a specific area of concern within

OSS security. The authors of this thesis have identified three distinct main

areas which are described below:

(30)

Software Security: Recommendations that are directly related to using different tools and techniques for finding and eliminating security vulnera- bilities. This security area also covers methods for monitoring the software evolution to detect vulnerabilities when they surface to maintain security from a long-term perspective.

Licensing risks: This is the least technical security area since it is related to legal risks rather than the risk of being attacked. It is concerned with the risks of legal repercussions when overstepping potential restrictive limits put on the software via its license.

OSS health: This security area is concerned with investigating the general status of an OSS project to get information on what to expect from it in terms of quality and support, and thereby assess how secure the software might be.

2.6 Guideline Recommendations

A broad definition of what a guideline entails is given by dictionary.cambridge.org (n.d.):

”Information intended to advise people on how something should be done or what something should be”

”a piece of information that suggests how something should be done”

The only requirement for something to be considered to be a guideline under this definition, is that it should provide information on how to do something.

There are, however, more precise suggestions on what constitutes ”good”

guidelines within specific practical and scientific fields, where the quality of guidelines could be controlled by identifying certain desired traits and at- tributes of guidelines.

Broughton and Rathbone (2001) proposes a checklist consisting of numerous requirements that guidelines should meet for them to be considered ”good”

within the field of healthcare. Another example is given by Aboulsoud,

Huckson, Wyer, and Lang (2012) where desired traits for making healthcare-

(31)

guidelines more useful is identified through a survey involving 206 respon- dents where the majority were physicians.

Effort has been made to find similar study’s within the field of software se- curity specifically, but to no avail. When inspecting the desired traits listed in the proposed checklist, and in the results of the survey, it is evident that many of them could be tailored to be used to evaluate any type of guideline to ensure its usefulness and validity.

2.6.1 Traits of a Good set of Guidelines

The traits of a good set of guideline according to Broughton and Rathbone (2001) are;

• Valid – leading to the results expected of them.

• Reproducible – if using the same evidence, other guideline groups would come to the same results

• Cost-effective – reducing the inappropriate use of resources.

• Representative/multidisciplinary – by involving key groups and their interests

• Clinically applicable – patient populations affected should be unam- biguously defined

• Flexible – by identifying the expectations relating to recommendations as well as patient preferences

• Clear – unambiguous language, which is readily understood by clini- cians and patients, should be used

• Reviewable – the date and process of review should be stated

• Amenable to clinical audit – the guidelines should be capable of

translation into explicit audit criteria

(32)
(33)

Chapter 3

Research Methodology

In this chapter, the research methodology for conducting this study is de- scribed together with the steps taken to produce results, the research pro- cess. Firstly the choice of methodology is described in Section 3.1 - Choice of Methodology. In this section the motivations behind the posed research question is presented along with tools and data required to answer the ques- tion. The chosen methodology a research design is presented, and a method for evaluating the findings of the study is presented. Section 3.2 - Research Process and Phases presents the general research process including detailed information on how the study was conducted to answer the research question.

The suitability of the chosen approach is discussed in Section 3.3 - Suitability of Research Approach and Research Validity, to further establish the motiva- tions behind decisions made, and to present identified validity threats related to the chosen approach.

An overview of the chosen methodologies, research instruments and processes

is depicted in Figure 3.1.

(34)

Figure 3.1: Research strategy overview

3.1 Choice of Methodology

The choice of methodical approach was based on the research question formu-

lated for directing this study. The research question is presented in Section

3.1.1 - Research Question along with a brief summary of why this question

was relevant, and a general outline of how to answer the question. With this

research question as a basis, required data to answer the question was iden-

tified and presented in Section 3.1.2 - Required Data. The type of research

methodology chosen for this study is presented in Section 3.1.3 - Choice of

Research Type, and tools used for the research and evaluation is presented in

section 3.1.4 - Research Tools and Section 3.1.5 - Evaluation.

(35)

3.1.1 Research Question

The question we asked ourselves before conducting this study was:

Could the contemporary security guidelines for open source software usage be improved?

Since the application developed in our commissioned work uses OSS and the work provider (STA) asked us to take considerations to the security risks it might imply, the topic became relevant for us. We first looked for security guidelines for OSS usage to follow up and found a few samples. These sam- ples although informative, came in different forms and were not very straight forward to follow up. Thus, we became interested in the idea of possibly improving them.

The next step was to see if there were any recommendations or conventions for how well defined,good or ideal security guidelines ought to be. Unfortunately there were not many recommendations for security guidelines within the do- main of OSS usage, however a number of recommendations were found for guidelines within the domain of healthcare. Although different domains, the content provided in these recommendations for healthcare guidelines seemed like they in great parts could be applied for security guidelines for OSS usage.

3.1.2 Required Data

To answer the research question certain data was required. In order to un- derstand if the contemporary security guideline for OSS usage could be im- proved, two groups of data were gathered; the contemporary security guide- lines for OSS usage and recommendations or standards for how guidelines should be formed.

3.1.3 Choice of Research Type

The chosen research type used for this research was a qualitative research

type combined with a document analysis data collection-method. The qual-

itative research types are characterized by a rigorous process where under-

standing and defining of the studied phenomena and the question at issue is

successively expanded throughout the study (Olsson, 2011). The document

(36)

analysis data collection method puts emphasis on the validity of the written word by not only taking what is written into account, but by whom and in what context.

A quantitative research type was deemed unsuitable because it builds on both establishing causality of the results and generalizing the results to dif- ferent contexts (Bryman, 2018). Furthermore, the quantitative methodology seeks to provide results that describe a static representation of reality, with emphasis on variable relations (ibid). This is an approach that would not be reasonable for this study. Since the research question posed in Section 3.1.1 is interpretative in its nature, and would be hard to quantify and measure due to the limited time frame, and various unknown factors such as indi- vidual preference and application context. The research conducted in this thesis does not have the structural organization or statistical basis to use a quantitative method.

When deciding upon which research design that was most suitable for this study, two different designs were considered; conclusive research design and exploratory research design.

The purpose of conclusive research is to provide a final answer or solution to a research question or problem (Dudovskiy, n.d.). This approach was deemed unsuitable due to the limitations of the study. The reasons for this is that the quality of the ”improved” guidelines would be a matter of interpretation and that the measurements of their effect would require rigorous testing and comparison against current guidelines.

Instead, the chosen research design was Exploratory where the research ques-

tion is put into focus to guide the exploration of the research topic. Even

though the main focus of an exploratory research design is to highlight the

topic and thereby form a foundation on which to build future research, and

not to present a conclusive solution to a problem(ibid), this study accom-

plishes both of objectives in part. In a pursuit to answer the research ques-

tion, the goal of producing an improved set of guidelines was also accom-

plished, however, not conclusively.

(37)

An exploratory research design is also strongly related to a qualitative re- search type which further suggests that the choice was suitable for the con- text.

3.1.4 Research Tools

The research tools used includes:

• Literature

• Example Software Project (Commissioned work)

Literature: The required data described in Section 3.1.2 - Required Data was acquired by searching for information using the keywords; Security Guide- lines, Open Source Software, Guideline Recommendations, Good Guidelines, Software Security and Open Source Software Security Guidelines. The por- tals used to find this information includes DiVA, Google Scholar, refseek and Microsoft’s Academic Research.

Example Software Project: One of our evaluation criteria demanded that the produced set of guidelines ought to be pilot-tested. Thus, we found that the software development-project Project X conducted in parallel with this study would be appropriate to test the guidelines against.

3.1.5 Evaluation

To evaluate the contemporary sets of security guidelines and the produced set of improved security guidelines, a checklist of guideline recommendations was used. This checklist was a subset of the guideline recommendations found in Broughton and Rathbone (2001) and Lemieux-Charles, Palda, Brouwers, Gagliardi, and Grimshaw (2011). For each guideline recommendation there were three assessment-checkboxes; Yes, No, Cannot tell,

In the process of evaluating the sets of security guidelines, they were analyzed

and assessed so that the appropriate assessment-checkboxes could be checked.

(38)

3.2 Research Process and Phases

The research process model followed to conduct this study were created with the main focus of answering the research question posed in Section 3.1.1 and in addition, reach the goal of producing a set of improved security guidelines for OSS usage. The research process consists of five research phases depicted in Figure 3.2, where each phase was designed to have a distinct part in an- swering the research question.

The Information Gathering and Analysis Phase, described in Section 3.2.1, was focused on gathering and analyzing the data needed to answer the re- search question through a literature study using the document analysis data collection method. Consideration to the credibility of the authors were taken in the process of gathering information by making sure that their background showed some form of expertise within the domain. This implied the exclusion of certain articles.

The gathered and analyzed data was then used to define evaluation crite- ria in the Evaluation Criteria Definition Phase, described in Section 3.2.2.

To be able to answer the research question, a well-defined baseline to check the guidelines for potential improvements needed to be established, which is what was done when we established the evaluation criteria. In the Prob- lem Identification Phase described in Section 3.2.3, guidelines found through the literature study were individually evaluated using the evaluation criteria defined in the previous phase. By conducting this evaluation, the research question could be partly answered depending on the results of the evaluation.

Based on the issues of the guidelines identified through the Problem Iden- tification Phase, a draft of improved guidelines was formulated through the Guideline Improvement Phase described in Section 3.2.4, building on the guidelines found through the literature study. The improvement phase was an effort to create a basis to be used to confirm that the found guidelines not only could be improved, but that it was actually possible to implement the improvement.

The results from the Guideline Improvement Phase were then evaluated

through the Evaluation Phase using the same evaluation criteria as in the

Problem Identification Phase. If the improved guidelines did not fulfill the

(39)

Figure 3.2: The Research Process

evaluation criteria, the Guideline Improvement Phase would be reiterated to further improve the guidelines. At the point when the guidelines were deemed satisfactory, that is, an improved version of the initial guidelines had been produced, the research question would be answered in full. Descriptions of the Evaluation Phase is found in Section 3.2.5.

3.2.1 Information Gathering and Analysis Phase

Guided by the research question, and the need for certain data to answer

the question as described in Section 3.1.1 and Section 3.1.2, the information

gathering and analysis phase was initiated by searching for existing security

guidelines for OSS usage using the keywords and portals presented in Section

3.1.4 - Research Tools. The process was initially focused on finding scientific

research papers and articles provided on well known portals. However, when

no relevant information could be found, the search was broadened to use

Google to find interesting entry points.

(40)

In parallel with gathering the information, analysis through reading was con- ducted to determine if it was relevant data for our study. Also, analysis on the credibility of the authors was conducted by making sure there was infor- mation proving their expertise within the domain.

The same process was used for finding information on what defines ”good”

security guidelines. This information would be used when defining evaluation criteria to be able to distinguish improvements in the guidelines throughout the process. Since no suitable information was found for the specific context of OSS usage, trusted resources from other fields of research were deemed ac- ceptable if the information could be adapted to be applicable to the context of interest, without loosing integrity and validity.

The result of the Information Gathering and Analysis Phase was collections of security guidelines and recommendations for how guidelines should formed.

These artifacts became the basis for the next phase described in Section 3.2.2 - Evaluation Criteria Definition Phase and in Section 3.2.3 - Problem Iden- tification Phase.

3.2.2 Evaluation Criteria Definition Phase

To be able to answer the research question of whether or not existing guide- lines could be improved, it was critical to establish a framework of evaluation criteria on which the quality of guidelines could be evaluated, to first establish a baseline quality measure of the existing guidelines which could be compared to the quality of the improved guidelines.

Through this research phase, the defined attributes of ”good” guidelines iden- tified in the information gathering and analysis phase were used to create the evaluation criteria to be used later in the research process. The gathered in- formation was first reviewed to find which attributes were applicable to the context of this study. The selection criteria applied in the review process to collect a suitable set of attributes were:

• The attribute should be relevant to the context of OSS usage

• The attribute should be reasonable with respect to the scope of this

thesis.

(41)

After having selected a collection of attributes, the attributes were divided into groups of which evaluation criteria they were a part of fulfilling such as clarity or maintainability. Also in the cases when certain criterion were redundant the ones that were deemed most suitable were picked and their al- ternatives dismissed. The result of this phase was a framework for evaluation, consisting of a list of distinct evaluation criteria.

3.2.3 Problem Identification Phase

The primary objective of the research process is to answer the research ques- tion on whether existing research questions could be improved. One step of this process was to investigated whether the guidelines would need improve- ments at all, and in the case that they would, to identify how they could be improved.

In the problem identification phase, guidelines found in literature were eval- uated using the evaluation criteria defined in the evaluation Criteria Phase.

Various issues found through the evaluation process were registered and con- sidered the output of this phase.

3.2.4 Guideline Improvement Phase

With a collection of identified issues from the previous phase, the next and final step of answering the research question could be executed. This phase could be said to answer the question; even if the guidelines need improve- ment, could they be improved?

In order to be able to improve the contemporary security guidelines, all the sets of guidelines were merged into one set. In the cases of redundant guide- lines the ones living up to the distinct evaluation criteria mostly, were chosen and their alternatives excluded.

Using the contemporary guidelines as a basis, an attempt to improve them against each recommendation was made. Since some issues of the contem- porary guidelines were outside the limitations of this study to be improved, they had to be left unresolved.

Throughout the improvement phase the guidelines were sought to be formu-

(42)

lated in accordance with the suggestions of writingcenter.ashford.edu (n.d.).

Since the issues of the contemporary security guidelines were identified late in the process, there was no way to know what this phase would entail in terms of subject, effort or time. However, it is typical for an exploratory research design for the researchers to be flexible and adapt to the findings throughout the process.

The existing guidelines were improved with complementary information and compiled into one single set of improved guidelines which is also the output of this phase.

3.2.5 Evaluation Phase

To investigate whether the new set of guidelines was in fact improved in comparison to the existing guidelines, and thereby answering the research question, an evaluation was conducted on the new set using the same evalu- ation criteria as in the Problem Identification Phase.

Through the evaluation process, remaining issues were identified and the result was compared to the results of the Problem Identification Phase to investigate whether improvements had been made or not.

A confirmatory answer at this point would have been sufficient to say that

the research question had been answered, however, to make sure that no re-

solvable issue was missed, the Guideline Improvement Phase was reiterated

to resolve any remaining issues that could be improved. The final result of

this phase was called the complete set of improved guidelines.

(43)

3.3 Suitability of Research Approach and Re- search Validity

Section 3.3.1 - Suitability of Research Approach, further explains the suit- ability of the chosen research approach in relation to this specific study, the research process, the type of data collected, and the nature of the goal this study strives to reach. Validity threats related to the study and its results are addressed in Section 3.3.2 - Research Validity.

3.3.1 Suitability of Research Approach

Before conducting the study, there were a number of uncertainties amongst the authors regarding the chosen topic of research, such as uncertainties about the current state of security guidelines, the need of improvements, and possibility to improve the guidelines. These uncertainties were all taken into account when formulating the research question Could the contemporary security guidelines for open source software usage be improved?. Therefore, the topic needed to be explored through research guided by the research question and the findings produced through the process. This type of research is typical for a Exploratory research design (Dudovskiy, n.d.). Furthermore, The requirements posed on the contrary Conclusive research design is that the research should produce a conclusive solution to a problem. Even if this study strives to produce guidelines of the highest quality possible, it could not be said that the improved guidelines is in any way conclusive or final.

The choice of a qualitative research type was in many ways an easy decision.

Firstly, the Exploratory research design is closely tied to qualitative research in that it is interpretive in its nature, and that it focuses on expanding the question throughout the process. Secondly, no set of data or numeric measurements were found to support a quantitative research type. Instead, the study builds on observations and analysis of written text which is typical for a qualitative research type.

3.3.2 Research Validity

The usage of validity and reliability criteria within research has a strong

connection to quantitative methods, whereas its application on qualitative

(44)

research has been criticized (Bryman, 2018). However, experts within the field has proposed a set of sub-criteria to use when evaluating the validity and reliability of qualitative research methods (ibid). The qualitative re- search validity criteria includes: credibility, transferability, dependability and confirmability.

The credibility-criterion focuses on whether the research and its results could be interpreted in another way than what is presented, or if the research could be accepted as a representation of reality. In qualitative research this validity criterion is often ensured by letting experts in the studied field partake in the results to evaluate if the result is valid or not, a method called respondent validation. It could also be validated through a method called triangulation, where several methods and sources of data is being used to ensure consis- tency (Bryman, 2018).

Transferability entails that results obtained through the study should also be valid even though the context is changed, or if a new study was to be conducted at another time.

Dependability is a method for ensuring the research reliability by allowing colleagues or peers audit the work and report while it is conducted, or when it is almost finished.

Confirmability entails an assurance that the researchers remain neutral and

unbiased and do not let personal values influence the research or results.

(45)

Chapter 4 Results

This chapter presents all results gathered through the research process. Sec- tion 4.1 - Gathered Information presents results from the information gather- ing and analysis phase, Section 4.2 - Evaluation Criteria presents the results of the Evaluation Criteria Definition Phase, Section 4.3 - Issues Identified in Existing Guidelines presents the results of the problem identification phase, Section 4.4 - Guideline Improvements presents improvements made to the guidelines, and how they were implemented, and Section 4.5 - Result of Fi- nal Evaluation presents results from the final evaluation of the improved guidelines.

4.1 Gathered Information

This section presents the sources of gathered information found through the Information Gathering Phase, which represents the basis of this study. Sec- tion 4.1.1 - Security Guidelines for OSS Usage presents the found sources of contemporary security guidelines and Section 4.1.2 - Guideline Recommen- dations presents the sources of information regarding recommendations for high quality guidelines.

4.1.1 Security Guidelines for OSS Usage

The information gathering of security guidelines resulted in four sets of guide-

lines from four different sources that were deemed to be reliable. The guide-

lines differed in both content and style of formulation, however, a great part

References

Related documents

46 Konkreta exempel skulle kunna vara främjandeinsatser för affärsänglar/affärsängelnätverk, skapa arenor där aktörer från utbuds- och efterfrågesidan kan mötas eller

The increasing availability of data and attention to services has increased the understanding of the contribution of services to innovation and productivity in

Närmare 90 procent av de statliga medlen (intäkter och utgifter) för näringslivets klimatomställning går till generella styrmedel, det vill säga styrmedel som påverkar

I dag uppgår denna del av befolkningen till knappt 4 200 personer och år 2030 beräknas det finnas drygt 4 800 personer i Gällivare kommun som är 65 år eller äldre i

Den förbättrade tillgängligheten berör framför allt boende i områden med en mycket hög eller hög tillgänglighet till tätorter, men även antalet personer med längre än

Det har inte varit möjligt att skapa en tydlig överblick över hur FoI-verksamheten på Energimyndigheten bidrar till målet, det vill säga hur målen påverkar resursprioriteringar

Detta projekt utvecklar policymixen för strategin Smart industri (Näringsdepartementet, 2016a). En av anledningarna till en stark avgränsning är att analysen bygger på djupa

DIN representerar Tyskland i ISO och CEN, och har en permanent plats i ISO:s råd. Det ger dem en bra position för att påverka strategiska frågor inom den internationella