WIXLIB

List of Tables2.12.22.32.4Likelihood table in a risk assessment. . . . . .Severity table in a risk assessment. . . . . . .Remediation Cost table in a risk assessment.Possible levels in a risk assessment. . . . . . .77784.1Rules tested in tools analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265.15.25.35.45.55.6Rules tested in C analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .True positive and False negative for C analysis. . . . . . . . . . . . . . . . . .Rules tested in C analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . .True positive and False negative for C analysis. . . . . . . . . . . . . . . .Found violations per tool for each Size range during Rule specific analysis.True positive and False negative for Rule specific analysis. . . . . . . . . . .293232373840C.1 CVE:s tested in C CVE analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56D.1 CVE:s tested in C CVE analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . .58E.1 CVE:s tested in Rule Specific CVE analysis. . . . . . . . . . . . . . . . . . . . . . . .60ix.

Off-by-One error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Fixed Off-by-One error. . . . . . . . . . . . . . . . . . . . . . . . . . .Accessing freed memory. . . . . . . . . . . . . . . . . . . . . . . . . .No longer accessing freed memory. . . . . . . . . . . . . . . . . . . .Format string bug. . . . . . . . . . . . . . . . . . . . . . . . . . . . .No longer contains a Format string bug. . . . . . . . . . . . . . . . .Integer overflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Fixed Integer Overflow. . . . . . . . . . . . . . . . . . . . . . . . . .Abstract syntax tree example code. . . . . . . . . . . . . . . . . . . .Python script for extracting C vulnerabilities. . . . . . . . . . . . . .Commands for PVS-Studio analysis. . . . . . . . . . . . . . . . . . .Python script for adding PVS-Studio student license comment. . . .Command for getting the docker container. . . . . . . . . . . . . . .Example command for running Rosecheckers analysis on the rtp.cJanus-gateway project. . . . . . . . . . . . . . . . . . . . . . . . . . .4.6 Command for setting up and running CodeChecker . . . . . . . . .4.7 Git diff for CVE-2020-14033. . . . . . . . . . . . . . . . . . . . . . . .4.8 Git diff for CVE-2018-9304. . . . . . . . . . . . . . . . . . . . . . . . .4.9 Line with problematic code for CVE-2019-9113. . . . . . . . . . . . .A.1 Python script for extracting EXP34-C CVE vulnerabilities. . . . . . .B.1 Python script for extracting C vulnerabilities. . . . . . . . . . . .x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .file in. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .the. . . . . . . . . . . . . . .88999101010132122232323242727275455

1IntroductionIn a society that is constantly moving forward and where the amount of connected devicesis increasing each day, the danger of cyber attacks is rising and the need for a defense ismore important than ever [15]. This potential danger is a significant issue, in both privateand public sectors, where involved parties need to consider different security aspects such aswhich systems to defend, the expected frequency of cyber attacks and what type of securityto invest in. As Ijaz Ahmad et al. explain in their article "Security for 5G and Beyond" [1], therise of 5G and the massive growth of connected devices that come with it have also openedup for more security threats. The emerging 6G standard, which will be introduced in about10 years and change the society we live in, also comes with challenging security threats thatneeds to be taken care of [36].One way to address the issue of software vulnerabilities and as such cyber attacks is to introduce secure coding standards into the software development and maintenance of the code[44]. Mark Grover et al. [25] conclude in their study that cyber attacks will increase over timeand that introducing secure coding is an effective countermeasure. By applying these typesof standards, the programmers will be encouraged to follow a collection of guidelines thatare established to make the software more secure. There are a great number of different standards and guidelines that can be followed depending on the type of programming languageused. For example, the SEI CERT Secure Coding Standard [27] and MISRA C [6].Static analysis tools are one way to identify the existing vulnerabilities within the code.These tools can also help with complying to a specific coding standard, since the purpose ofthe tools is to give warnings where the code is non-compliant with the standard. There aremultiple studies that have been conducted showing that static analysis tools result in bothfalse and correct warnings, called false positive and true positive. Studies like Jiang Zhenget al.’s [54], also shows that tools are a good way to observe what mistakes occur most often.They found that "possible use of NULL pointer" stood for 45.92% of all the vulnerabilities.While it can be discussed whether one static analysis tool is better than the other in regardsto violations found, it is equally important to include the run time of the tool as well as theamount of projects the tool actually can be run on. Therefore, an evaluation of different toolsis of great interest when deciding on what tool to use in a project.1

1.1. Motivation1.1MotivationDifferent coding standards have for a long time been suggested to increase the security, reliability and overall quality [27, 13]. Currently there is not much empirical evidence backingthese statements, and studies have even shown that conformance to all rules in a specificstandard may result in more introduced faults [11]. This is beyond doubt an interesting areaand more effort needs to be put into these types of questions. Therefore, the motivation andmain focus of this thesis seeks to establish how compliance to different rules of SEI CERTCoding Standards can be used to reduce the amount of vulnerabilities and as such improvethe quality of the code.1.1.1EricssonThis thesis is conducted at Ericsson, which is a leading company of Information and Communication Technology. Ericsson works with technology ranging from networks and digitalservices, to managed services and emerging business. This leads to Ericsson having to dealwith thousands of lines of code every day. As a part of this, Ericsson needs to handle all vulnerabilities related to the code. A recurring part of Ericsson’s development process is to writetrouble reports (TRs) when problems occur. Since this is taking a substantial amount of time,this is something Ericsson wants to minimize. By investigating whether using the SEI CERTstandard is beneficial, Ericsson hopes to reduce the vulnerabilities, meaning the workload inregards to TRs. Ericsson could further improve the quality of their products by writing moresecure code.1.2AimThis thesis aims to test if compliance to the SEI CERT secure coding standard can help reducevulnerabilities. This can be achieved by analyzing vulnerabilities, both manually and withstatic analysis tools, reported in Common Vulnerabilities and Exposures (CVE) [17], a publicdatabase where a significant number of vulnerabilities from different software projects arereported. A secondary aim of this thesis is to evaluate different static analysis tools in regardsto SEI CERT coverage and performance.1.3Research questionsTo achieve the aim of the thesis, the following research questions will be answered:RQ1. How can vulnerabilities be reduced in the early phase of software development?RQ2. To what extent does SEI CERT compliance help reduce vulnerabilities?RQ3. What static analysis tools can help complying with the SEI CERT secure coding standard?1.4DelimitationsWhen analyzing what tools can help complying with SEI CERT, the time it takes to run thetools on the projects is an important factor and it was decided to limit this by not includingprojects that are very large in size, such as the Linux kernel. The tools analyzed were limitedto three different static analysis tools, mainly because the selected ones were free to use andbecause they cover many SEI CERT rules. Both of these limitations were also due to the 20week time limit for the research, study and report to be finished.2

1.4. DelimitationsAnother delimitation is that this thesis only looks at the C and C SEI CERT codingstandards and not the Android, Java or Perl standards. This is primarily because it wasrequested by Ericsson, but also due to the limited time for the thesis to be completed.3

2TheoryIn this chapter, theory about Secure software development, CVE, and the SEI CERT CodingStandard will be given. After that, CVSS will be briefly presented as well as the static analysistools used.2.1Secure software developmentIn this subsection, secure software development (also referred to as secure coding interchangeably throughout this thesis) and how it can be applied to a project will be presented.The reason secure coding, at this moment, is a prevailing topic and more important than everbefore to devote to, is because of the ever-present threat of cyber attacks. As more and moresystems are getting connected to the internet people need to consider the risks and if protecting the system is cost-effective [10]. As Pawani Porambage et al. talk about in the article "TheQuest for Privacy in the Internet of Things" [37], the big increase of the Internet of Things(IoT) is a reason to why the developers need to take the privacy of their users into consideration and why they need to develop secure and trustworthy software that protects the usersin any case.Secure software development is what developers need to adhere to, to make sure thatthe software is protected from vulnerabilities. By neglecting this, it could result in loss ofimportant data, denial of services, company secrets getting leaked or damage to the system.The software development life cycle (SDLC) is a model that includes different processes ofthe life cycle of the development of a software project [8]. This model consists of six steps, therequirement phase, the architecture and design phase, the implementation phase, the testingphase, the deployment phase and the maintenance phase. Secure coding is not only appliedin the implementation phase, instead this is something that should be considered throughoutthe whole life cycle. Security requirements should start being established as early as in therequirement phase. In the architecture and design phase, risk analysis should be exercised.The implementation phase might contain risk-based security testing and static analysis, anddeployment and verification phase could for example include risk analysis and penetrationtesting.There are many ways developers can make their systems more secure against threats.Commonly used practices could for example be to follow a specific secure coding standard,4

2.2. CVEe.g. the SEI CERT Secure Coding Standard, or adhere to a special SDL method. The nextsection will introduce the CVE database and describe some of its components.2.2CVEThe Common Vulnerabilities and Exposures, or CVE, is a program and a database that waslaunched in 1999 [17]. CVE aims to gather known vulnerabilities from different softwareprojects. CVE consists of countless CVE records, these records contain, amongst other things,a CVE ID number, a description, and a section of references. The CVE records also have thevulnerability analysis and the description that often includes references to the source of thevulnerability. The reference section usually contains links, for example, a GitHub repositorylink or a report of the vulnerability on the developers product website. Because of the highusability of CVE, CVE has become the industry standard for vulnerability reports [18].There are a few other databases, such as the IBM X-Force Exchange [26] and SecurityFocus [45], that also collect and show vulnerabilities. The IBM X-Force Exchange usually has alink to a CVE record in the vulnerability record, if there is one for the vulnerability. Vulnerability records in the IBM X-Force Exchange have tags, making the searching for particularvulnerability types quite easy.2.3SEI CERT Coding StandardThe SEI CERT Secure Coding Standard includes five different components where each of themconsists of guidelines about secure coding in that specific programming language or area:1. SEI CERT C Coding Standard2. SEI CERT C Coding Standard3. SEI CERT Oracle Coding Standard for Java4. Android Secure Coding Standard5. SEI CERT Perl Coding StandardIn particular, CERT stands for Computer Emergency Response Team and is a programthat is part of the Software Engineering Institute (SEI) at Carnegie Mellon University [14,p. xxvii]. Originally the CERT program was created to help teams of experts communicateduring security emergencies, however this is no longer the sole purpose of CERT. They nowproduce analysis in different security areas as well as provide standards for secure codingpractices.Next, theory about the SEI CERT C standard will be introduced. All the sections explainedfor the C standard can be applied for the SEI CERT C standard and most of the SEI CERTC rules are included in the C standard as well. Therefore the C section will be shorter,as otherwise there would be a lot of repetition.2.4SEI CERT C Coding StandardThe CERT C Secure Coding Standard, referred to as CERT C standard at times, is developedby SEI and the goal of the standard is to make it easier to develop safe, reliable, and securesystems [27]. Compliance to the CERT C standard will make sure that the system is moresecure and reliable on a code level, but this is not always enough since there might existcritical design flaws in the system design, which is not something that SEI CERT directlyaddresses. In systems where safety is of utmost importance, the requirements are usuallystricter than that of the CERT C standard.5

2.4. SEI CERT C Coding StandardThe different rules in the SEI CERT C Secure Coding Standard consist of a few parts. Atitle to shortly describe the rule and a description that is a bit more specific and explains therequirements of the rule. There are also code examples, both non-compliant and compliantexamples. The guidelines also consist of recommendations to help guide the programmersto a more secure and reliable code. These recommendations do not need to be followed inthe same way that a rule does and a violation of a recommendation does not automaticallymean that the code is insecure or bad. To check for compliance to the SEI CERT C codingstandard it is most efficient to have a static analysis tool setup, explained in Section 2.7, but itcan also be done manually. However, manual analysis takes a lot more time than automatedtools analysis.The SEI CERT C Secure Coding Standard is meant to make project members change theway they think about secure coding in software development. By adhering to this standardthe team can create the highest form of value, and also gain knowledge that will be useful fora long time in future work.2.4.1Scope of SEI CERT CAs for now, the SEI CERT C Secure Coding Standard focuses mainly on version C11 (ISO/IEC9899:2011), but it can also be practiced in previous versions. The difference between theversions may lead to ambiguities, therefore it is important when following the standard, tolook for notations about how the standard would affect a specific version.Some of the issues that are not addressed in the CERT C standard are the coding style andrules that are seen as controversial. The reason for this is that coding style is usually subjective and it is extremely difficult to create a style guide that is in agreement with everyone.Therefore coding style is skipped completely in the CERT C standard. For a similar reason,controversial rules are skipped. Since there is no broader consensus on these controversialrules CERT have decided to not include these at all.2.4.2ValidationCompliance with the SEI CERT C Secure Coding Standard can be checked with different staticanalysis tools. The reason to use these is because of the increased complexity of a programwith thousands lines of code. The static analysis tools can not be applied to enforce all of theguidelines, since some of the rules are only meant to be descriptive, for example, "MSC41-C.Never hard code sensitive information".A static tool will in most cases not be able to tell whether a program is following a specificguideline or a set of rules. The reason for that is because it is computationally infeasible totell if a program is pursuing a specific rule or recommendation. When deciding which staticanalysis tool to use there are certain aspects that should be taken into consideration. Oneof these aspects is the completeness, which means that no false positives are reported, a

will be done to verify whether applying the SEI CERT secure coding standard will help reduce vulnerabilities. This study also evaluates the SEI CERT rule coverage of three dif-ferent static analysis tools, Rosecheckers, PVS-Studio and CodeChecker by executing them on these vulnerabilities.