Security Vulnerabilities In Categories Of Clones And Non-Cloned Code .
2017 ACM/IEEE International Symposium on Empirical Software Engineering and MeasurementSecurity Vulnerabilities in Categories of Clones andNon-Cloned Code: An Empirical StudyMd Rakibul IslamMinhaz F. ZibranAayush NagpalUniversity of New Orleans, USAEmail: mislam3@uno.eduUniversity of New Orleans, USAEmail: zibran@cs.uno.eduUniversity of New Orleans, USAEmail: anagpal@uno.educhanges [11], [19], [24], [25], [26], [30], [36], [43], [49], theimpacts of clones on program’s changeability [17], [31], [32]and comparative fault-proneness of cloned and non-clonedcode [22], [42].However, the security aspects of code clones have neverbeen studied before, although the reuse of vulnerable components and source code (i.e., code clones) multiply securityvulnerabilities [23], [29], [46]. This paper presents, a largeempirical study on the security vulnerabilities in code clonesand presents a comparative analysis of these vulnerabilities indifferent types of clones as opposed to non-cloned code. Inparticular, we address the following five research questions.RQ1: Do code clones contain higher number of securityvulnerabilities than non-cloned code or vice versa?— The answer to this question will add to our understandingof the negative impacts of clones, which will be useful incost-benefit analysis [40] for improved clone management.RQ2: Do clones of a certain category contain more securityvulnerabilities than others?— If a certain type of clones are found to have higher numberof security vulnerabilities, those clones will be high-prioritycandidates for removal or careful maintenance.RQ3: Do code clones contain more severe (i.e. riskier) vulnerabilities compared to non-cloned code or vice versa?— All the security vulnerabilities are not equally risky interms of security threat. The result of this research questionwill advance our understanding of clones’ impacts and will beuseful in cost-effective clone management [40].RQ4: Do clones of a certain category contain relatively severe(i.e., riskier) security vulnerabilities than others?— If a certain type of clones are found to have riskier securityvulnerabilities, those clones will demand especial attention andhigh-priority in clone-removal process.RQ5: Can we distinguish some security vulnerabilities thatappear more frequently in cloned code as opposed to noncloned code?— If we can distinguish a set of vulnerabilities that appear more frequently in code clones, the finding will helpsoftware developers to stay cautious of such vulnerabilitieswhile cloning source code. In addition, that particular set ofvulnerabilities can be minimized by clone refactoring.To answer the aforementioned research questions, we conduct a large-scale empirical study over 8.7 million lines ofAbstract—Background: Software security has drawn immenseimportance in the recent years. While efforts are expected inminimizing security vulnerabilities in source code, the developers’practice of code cloning often causes multiplication of suchvulnerabilities and program faults. Although previous studiesexamined the bug-proneness, stability, and changeability of clonesagainst non-cloned code, the security aspects remained ignored.Aims: The objective of this work is to explore and understandthe security vulnerabilities and their severity in different typesof clones compared to non-clone code. Method: Using a stateof-the-art clone detector and two reputed security vulnerabilitydetection tools, we detect clones and vulnerabilities in 8.7 millionlines of code over 34 software systems. We perform a comparativestudy of the vulnerabilities identified in different types of clonesand non-cloned code. The results are derived based on quantitative analyses with statistical significance. Results: Our studyreveals that the security vulnerabilities found in code clones havehigher severity of security risks compared to those in non-clonedcode. However, the proportion (i.e., density) of vulnerabilitiesin clones and non-cloned code does not have any significantdifference. Conclusion: The findings from this work add to ourunderstanding of the characteristics and impacts of clones, whichwill be useful in clone-aware software development with improvedsoftware security.I. I NTRODUCTIONSoftware security has become one of the most pressingconcerns recently. Software developers are expected to writesecure source code and minimize security vulnerabilities in thesystems under development. However, the developers’ copypaste practice for code reuse often cause the multiplication andpropagation of program faults and security vulnerabilities [22],[25], [52]. Thus, there is a possibility that such vulnerabilitiescan exist in cloned code at a higher rate.Code clone (i.e., similar or duplicated code) is alreadyidentified as a notorious code smell (i.e., a symptom indicatingsource of future problems) [14] that cause other problemssuch as reduced code quality, code inflation, and change difficulties [25], [31], [50], [52]. Nevertheless, software systemstypically have 9%-17% [53] cloned code, and the proportionis sometimes found to be even 50% [37] or higher [13].Clones are arguably a major contributor to the high maintenance cost for software systems, and as much as 80%of software costs are spent on maintenance [20]. Thus, tounderstand the characteristics and contexts of the detrimentalimpacts of clones, earlier studies examined the comparative stability of clones as opposed to non-cloned code [16],[18], [27], [28], [34], relationships of clones with bug-fixing978-1-5090-4039-1/17 31.00 2017 IEEEDOI 10.1109/ESEM.2017.920
Type-1 Clones: Identical pieces of source code with orwithout variations in whitespaces (i.e., layout) and commentsare called Type-1 clones [51].source code in 34 open-source software systems written in C.Using a wide range of metrics and characterization criteria, wecarry out in-depth quantitative analyses on the source code ofthe systems with respect to different categories of code clones,non-cloned code, and a set of security vulnerabilities. In thisregard, this paper makes the following two contributions: We present a large-scale comparative study of the securityvulnerabilities in code clones and non-cloned code. Tothe best of our knowledge, no such study of the securityvulnerabilities in code clones exists in the literature. We also perform a comparative analysis of securityvulnerabilities in different types of clones (e.g., Type-1,Type-2, and Type-3), which informs the relative securityimplications of clones at different similarity levels.Type-2 Clones: Type-2 clones are syntactically identical codefragments with variations in the names of identifiers, literals,types, layout, and comments [51].Type-3 Clones: Code fragments, which exhibit similarities asof Type-2 clones and also allow further differences such asadditions, deletions or modifications of statements are knownas Type-3 clones [51].By the definitions above, Type-2 clones include Type-1 whileType-3 clones include both Type-1 and Type-2. Let, T1 , T2 , andT3 respectively denote the sets of Type-1, Type-2, and Type-3clones in a software system. Mathematically, T1 T2 T3 .Thus, two additional subsets of Type-2 and Type-3 clones arecharacterized as follows.II. T ERMINOLOGY AND M ETRICSIn this section, we describe and define the terminologiesand metrics that are used in our work. Some of the metricsare adapted from the literature [22], [38].Pure Type-2 Clones: A set of pure Type-2 clones includeonly those Type-2 clones that do not exhibit Type-1 similarity.Mathematically, T2p T2 T1 , where T2p denotes the set ofpure Type-2 clones.A. Security VulnerabilitiesA software security vulnerability is defined as a weakness ina software system that can lead to a compromise in integrity,availability or confidentiality of that software system. Forexample, buffer overflow and dangling pointers are two wellknown security vulnerabilities. The cyber security communitymaintains a community-developed list of common softwaresecurity vulnerabilities where each category of vulnerabilityis enumerated with a CWE (Common Weakness Enumeration)number [1]. For example, CWE-120 refers to those vulnerabilities that fall into the CWE category of classic buffer overflow.More examples of security vulnerabilities along with theirCWE enumerations are presented in Table I.Pure Type-3 Clones: A set of pure Type-3 clones includeonly those Type-3 clones, which do not exhibit similarities atthe levels of Type-1 or Type-2 clones. Mathematically, T3p T3 T2 , where T3p denotes the set of pure Type-3 clones.C. MetricsThe required metrics are defined in terms of density ofvulnerabilities with respect to (w.r.t.) syntactic blocks of code(BOC) as well as w.r.t. lines of code (LOC). Only source linesof code are taken into consideration excluding comments andblank lines.Let, C denote the set of all cloned code blocks and C denotethe set of all non-cloned code blocks.Also let, VC denote the set of vulnerabilities found in C Aand VC denote the set of vulnerabilities located in C.cloned code block in C can be of category X clone whereX 2 {T1 , T2 , T3 , T2p , T3p }. Thus, VC can be split into multiplesets with VX denoting the set of vulnerabilities identified inclones of category X .B. Code ClonesOur study includes code clones at the granularity of syntactic blocks (located between curly braces { and }) known asblock clones. We study clones at different levels of syntacticsimilarities as mentioned below.TABLE IS ECURITY VULNERABILITIES FREQUENTLY IDENTIFIED IN THE SYSTEMSSecurity VulnerabilityDescriptionBuffer OverflowUncontrolled FormatStringAn application attempts to write data past the end of a buffer (CWE-120).Submitted data of an input string is evaluated as a command by the application(CWE-134).The result of an arithmetic operation exceeds the maximum size of the integer typeused to store it (CWE-190).Dereference a pointer that is null (CWE-476).Not release allocated memory (CWE-401).A string is incorrectly terminated (CWE-170).Concurrent execution using shared resource with improper synchronization(CWE-362).The program calls free() twice on the same memory address (CWE-415).Access memory after it has been freed (CWE-416).The software may use insufficiently random numbers or values in a security contextthat depends on unpredictable numbers (CWE-330).Improper neutralization of special elements used in an operating systems command(CWE-78).Creating and using insecure temporary files can leave application and system datavulnerable to attack (CWE-377).The input can be modified by an untrusted actor in a way that bypasses theprotection mechanism (CWE-807).Indication that the product has not been carefully developed or maintained(CWE-398).Code that can never be executed (CWE-561).The code uses deprecated or obsolete functions, which suggests that the code hasnot been actively reviewed or maintained (CWE-477).Stealing the information protected, under normal conditions, by the SSL/TLSencryption (CWE-327).The variable’s value is assigned but never used (CWE-563).Integer OverflowNull Pointer DereferenceMemory LeakNull Termination ErrorsConcurrency ErrorsDouble FreeAccess Freed MemoryInsecure RandomnessOS Command InjectionInsecure Temporary FileReliance on UntrustedInputsPoor Code QualityDead CodeUse of Obsolete FunctionsRisky CryptographyUnused VariableDensity of vulnerabilities w.r.t. BOC in category X clones,denoted as @X , is defined as the ratio of the number ofvulnerabilities found in clones of category X to the numberof cloned blocks in category X clones. Mathematically, VX (1)@X Xwhere VX denotes the number of vulnerabilities found in theblocks of category X clones and X denotes the total numberof block clones of category X . And, X 2 {T1 , T2 , T3 , T2p , T3p }.Density of vulnerabilities w.r.t. BOC in type T code,denoted as @T , is defined as the ratio of the number ofvulnerabilities found in type T code to total number of blocks Mathematically,in type T code, where T 2{C , C}. VT (2)@T T21
where VT 2{V C , VC̄ } andblocks in type T code.TTABLE IIS UBJECT SYSTEMS AND THEIR LOC IN CLONED AND NON - CLONED CODEdenotes the total number of# of LOC written in C Subject SystemDensity of vulnerabilities per 1,000 LOC (KLOC) in category X clones, denoted as @X, is defined as follows: V X 1000(3)@X Xwhere X denotes the total number of LOC in clones ofcategory X .Density of vulnerabilities per KLOC in type T code,denoted as @T , is defined as follows: VT 1000(4)@T Twhere T denotes the total number of LOC in type T rousersViVimXSupplicantZabbixRisk severity score per KLOC in category X clones,denoted as RX , is defined as the ratio of sum of severity scoresof the vulnerabilities found in clones of category X to thenumber of KLOC in the clonesof category X . Mathematically,Ps( ) 1000(5)RX 2VX Xwhere s( ) denotes the severity score of vulnerability .Risk severity score per KLOC in type T code, denoted asRT , is defined as the ratio of sum of severity scores of thevulnerabilities found in type T code to the number of KLOCin that type of code. Mathematically,Ps( )RT 2VT 1000(6) TDensity of a particular group of vulnerabilities G perKLOC in type T code, denoted as @TG , is calculated bydividing the number of vulnerabilities found in CWE categoryG in type T code by the total number of KLOC in that typeof code. Mathematically, GT 1000(7)@TG Twhere GT denotes the number of vulnerabilities belong to aCWE category G found in type T code.TABLE IIIN I C A D S ETTINGS F OR C ODE C LONE D ETECTIONChosen Parametersfor NiCadDissimilarity ThresholdIdentifier RenamingGranularityMinimum Clone SizeTarget Clone TypesType-1Type-2Type-30.00.00.3no renameblind renameno renameblockblockblock5 LOC5 LOC5 LOCThe average size of the subject systems is 256 thousand LOCwhere the largest project consists of 3.4 million LOC and thesmallest one contains 16 thousand LOC.III. S TUDY S ETUPThe procedural steps of our empirical study are summarizedin Figure 1.B. Code Clone DetectionUsing the NiCad [39] clone detector (version 3.5), weseparately detect code clones in each of the subject systemsat the granularity of syntactic code blocks. The parameterssettings of NiCad used in our study are mentioned in Table III.With these settings, NiCad detects Type-1, Type-2, and Type-3clones. Further details on NiCad’s tuning parameters and theirinfluences on clone detection can be found elsewhere [39].Then, we compute the pure Type-2 and pure Type-3 clones inaccordance with their definitions outlined in Section II.A. Subject SystemsOur study investigates the source code of 34 open-sourcesoftware systems written in C. Although some of the systemscontain files written in other languages such as C , Perl andother scripting languages, we only consider those files, whichhave extension ‘.c’ or ‘.h’ to exclude source code written inlanguages other than C. Projects of various sizes are deliberately chosen from different application domains includingnetworking, communication, security, and text editing. Mostof these subject systems are well-reputed in their respectivedevelopment ecosystems (e.g., GitHub and SourceForge) andused in earlier research studies [8], [15], [41], [54], [55].The names and sizes of the subject systems in LOC in clonesand non-clone code are presented in Table II. In computationof sizes, only the source code written in C are considered.C. Security Vulnerability DetectionFor the detection of vulnerabilities in source code, we usetwo open-source static analysis tools Flawfinder (version1.3) [3] and Cppcheck (version 1.76.1) [2]. Their ability todetect different sets of vulnerabilities make them appropriatefor our analysis. For example, Flawfinder is capable ofdetecting vulnerabilities such as Uncontrolled Format String,22
FlawfinderSystem-1VulnerabilityDetectionFlawfinder DetectedVulnerabilities (FDV)Computationof Metrics forFDVSystem-2Cloned Code ction ofPure ClonesType-3Cloned Code BlocksType-1Pure Type-2ComputedMetrics forFDVAnalysisPure Type-3FindingsExtraction ofNon-clonedCode BlocksAll Code Blocks in EachSystemNon-cloned Code BlocksComputationof Metrics forCDVCppcheck DetectedVulnerabilities (CDV)VulnerabilityDetectionComputedMetrics forCDVAnalysisSystem-34CppcheckFig. 1.Procedural Steps of the Empirical StudyTABLE IVR EDUCTION OF FALSE POSITIVES IN VULNERABILITY DETECTION USINGTHE CUSTOMIZED CONFIGURATION OF F L A W F I N D E RInteger Overflow and Use of Risky Cryptographic Algorithm,which Cppcheck fails to detect [12]. On the other hand,Cppcheck is able to detect vulnerabilities such as Memory Leak, Dead Code and Null Pointer Dereference thatFlawfinder cannot detect [12].We now briefly describe how these tools work for thedetection of security vulnerabilities and the ways these toolsare used in our study. We also present justifications forchoosing these tools for our study.1) Flawfinder: The tool contains a database of commonfunctions known to be vulnerable. It operates by performinglexical tokenization of the C/C code and comparing thetokens with those in the database. Once the comparison isperformed, it reports a list of possible vulnerabilities alongwith a source code line number and a numeric risk-level (i.e.,severity score) associated each of the detected vulnerabilities.The severity scores vary from one (indicating little securityrisk) to five (indicating high risk).Although many other open-source static analysis tools suchas, RATS [6], SPLINT [7] and ITS4 [47] exist to identifypotential security issues, we choose Flawfinder for anumber of reasons. This tool is reported to have the highestvulnerabilities detection rate (i.e., highest recall) among all theexisting security vulnerability detectors [12], [33], [48], [35].Moreover, a comparison of vulnerability detection tools [33]also recommend choosing Flawfinder to detect securityvulnerabilities. Flawfinder is also widely used in manyearlier studies [35], [45], [48].To detect vulnerabilities with Flawfinder, we executethe tool from command line interface and separately detectvulnerabilities in each of the subject systems in our study. Werefer to the vulnerabilities detected using Flawfinder asFDV (Flawfinder Detected Vulnerabilities).a) Limiting false positives in Flawfinder: AlthoughFlawfinder has the highest detection rate, at times, itis blamed for reporting many false positives [48]. To reduce the false positives, we alter the default configurationof Flawfinder. We run the tool with ‘-F’ configurationparameter that reduces 62% of the false positives as reportedin a controlled experiment [44]. To further reduce the effectof false positives, we discard any detected vulnerabilitiesassociated with risk-levels less than two.Test SuiteID5758# of False Positives ReportedDefault Config.Customized Config.08100104Reduction ofFalse Positives87.50%60.00%b) Effectiveness of customized configuration: To determine the effectiveness of the customized configuration statedabove, we collect two C/C test suites, test-suite-57 and testsuite-58 from Software Assurance Reference Dataset (SARD)[4]. These test suites include 41 and 39 pieces of coderespectively. While all pieces of code in test-suite-57 areknown to be vulnerable, none of the pieces of code in testsuite-58 are vulnerable.We run Flawfinder on the two test suites separatelyusing both default and customized configurations. By comparing the reported vulnerabilities with the known vulnerabilitiesin the test suites, we compute false positives w.r.t. both testsuites for each of the configurations and present the result inTable IV. Notice that with the customized configuration, falsepositives are reduced by 87.5% and 60% for test-suite-57 andtest-suite-58 respectively. We also observe 30% reduction inthe detection of vulnerabilities mostly due to the eliminationof false positives using the customized configuration for testsuite-57. Thus, at the cost of a minor sacrifice in recall, thecustomized configuration is able to reduce significant numberof false positives.2) Cppcheck: Cppcheck supports a wide variety ofstatic checks that are rigorous, rather than heuristic in nature [2]. Cppcheck is developed aims to report zero falsepositives [2], which makes it unique from other static securityanalysis tools. Unlike Flawfinder, Cppcheck does not assign numeric risk-levels to vulnerabilities. Instead, Cppcheckclassifies vulnerabilities into six severity categories namely,Error, Warning, Style, Performance, Portability, and Information. We operate Cppcheck from command line using itsdefault configuration separately on each of the subject systems.The output of the tool is generated in XML. We refer tothe security vulnerabilities detected by Cppcheck as CDV(Cppcheck Detected Vulnerabilities).Brief description along with CWE numbers of the major vulnerabilities detected in the subject systems usingFlawfinder and Cppcheck are presented in Table I. Those23
PTyp uree-2, 13%83e,lon,3clones,17%5%Pure Type-3, 52%All(a)(b)Fig. 2. Distribution of F DV (a) in Cloned and Non-cloned Code and (b)in Different Types of ClonesNon-cloneAll clonesFig. 3.Type-1Pure Type-2Pure Type-3Densities of F DV w.r.t. BOCperform Kruskalmc [9] test for post-hoc analysis at the samesignificance level. As the non-parametric MWW, KruskalWallis and Kruskalmc tests do not require normal distributionof data, those tests suit well for our purpose. To measure theeffect size, we compute the non-parametric effect size Cliff’sdelta [9].reported as vulnerabilities but do not have an associated CWEnumber are excluded from our analysis to further limit effectsof possible false positives.A. Vulnerabilities in Clones vs. Non-Cloned CodeAnalysis Using FDV: Figures 2(a) and 2(b) present thedistributions of vulnerabilities detected using Flawfinderin non-cloned code and in different types of clones respectivelyover all the systems. As seen in Figure 2(a), 83% of all thevulnerabilities are found in non-cloned source code, whereasthe clones contain only 17% of vulnerabilities.The box-plot in Figure 3 presents the densities of vulnerabilities (i.e. FDV) w.r.t. BOC (computed using Equation 1and Equation 2) found in non-cloned code and in differenttypes of clones over all the subject systems. The ‘x’ marks inthe boxes indicate the mean densities over all the systems. Asseen in Figure 3, the density of vulnerabilities (w.r.t. BOC) innon-cloned blocks is much higher than that in code clones.It is highly probable that a larger portion of source codecontains more vulnerabilities than a smaller portion of sourcecode, which might be a reason why non-cloned code seemsPTyp uree-2, 23%Type-1,29%Non7%-clone,93%IV. A NALYSIS AND F INDINGSAfter detecting clones and vulnerabilities in the softwaresystems, we determine locations of the detected vulnerabilitiesin different types of code (i.e., cloned and non-cloned code).A vulnerability is said to be located in cloned code if thereported source code line number of that vulnerability includedin a cloned block, otherwise, the vulnerability is locatedin non-cloned block. For each of the subject systems, weidentify the co-locations of code clones and vulnerabilities,distinguish the vulnerabilities located in non-cloned portion ofcode, and compute all the metrics described in Section II. Thenumber of FDV, CDV in the clones and non-cloned code ineach of the subject systems, and the cumulative vulnerabilityseverity scores (obtained from Flawfinder) are presentedin Table V.We separately analyze the security vulnerabilities detectedusing both Flawfinder and Cppcheck to derive answers to the research questions RQ1, RQ2, and RQ5. SinceCppcheck does not provide the numeric severity score toindicate risk-level of a security vulnerability, the researchquestions RQ3 and RQ4 are addressed using FDV only.Statisitical measurements. To verify the statistical significance of the results derived from our analyses, we applythe statistical Mann-Whitney-Wilcoxon (MWW) test [9] andKruskal-Wallis test [9] at the significance level 0.05. WeAllclones,Severity 81,252228560224417522,264701,822548992278Non-c# of 59350556624-1Densities of Vulnerabilities# of F 2Here, N C non-cloned code and C cloned E VD ETECTED SECURITY VULNERABILITIES AND THEIR SEVERITY INCLONED AND NON - CLONED CODEPure Type-3, 48%(a)(b)Fig. 4. Distribution of LOC (a) in Cloned and Non-cloned Code and (b) inDifferent Types of Clones24
Densities of VulnerabilitiesDensities of VulnerabilitiesNon-cloneAll clonesFig. 5.Type-1Pure Type-2Non-cloneDensities of F DV w.r.t. LOC-clone,84%re ,Pu e-2pTy13%Type1,27%Type-1Pure Type-2Pure Type-3Densities of CDV w.r.t. LOC3 and Equation 4) found in non-cloned code and in differenttypes of clones over all the subject systems. As seen inFigure 7, the average of densities of vulnerabilities is higherin cloned code (all clones) compared to non-cloned code,although the median of densities of vulnerabilities is slightlyhigher in non-cloned code as opposed to code clones. Again,we conduct a MWW test to measure the statistical significanceof differences in the densities of vulnerabilities (w.r.t. LOC) incloned and non-cloned code. The p-value (p 0.42, p )obtained from the statistical test implies that differences inthe densities of vulnerabilities (w.r.t. LOC) in cloned andnon-cloned code across all the subject systems do not differsignificantly. This result agrees with that obtained for FDV.Therefore, we derive the answer to the RQ1 as follows:Ans. to RQ1: Densities of vulnerabilities in cloned codeare NOT significantly higher than non-cloned code.cloAll(a)All clonesFig. 7.nes,16%NonPure Type-3Pure Type-3, 60%(b)Fig. 6. Distribution of CDV (a) in Cloned and Non-cloned Code and (b) inDifferent Types of Clonesto have more vulnerabilities as observed in Figure 2(a) andFigure 3. To verify this possibility, we compute the distributionof LOC in non-cloned code and different types of clonesover all the systems as presented in Figures 4(a) and 4(b)respectively. In Figure 4(a), we find that the number of LOCin non-cloned code is significantly higher compared to clonedcode. We also compute the lengths of non-cloned and clonedcode blocks in terms of average LOC over all the systemsthat are found to be 48.69 and 12.97 respectively. Thus, thepossibility of influence of code size (in terms of LOC) on thenumber and density of vulnerabilities w.r.t. BOC is found tobe true.We, therefore, continue our investigations at a deeper levelusing the densities of vulnerabilities w.r.t. LOC. The box-plotin Figure 5 presents the densities of vulnerabilities w.r.t. LOC(computed using Equation 3 and Equation 4) found in noncloned code and in different types of clones over all the subjectsystems. Figure 5 shows that both the median and averageof densities of vulnerabilities (w.r.t. LOC) in cloned code (allclones) are higher compared to non-cloned code. We conduct aMWW test to measure the statistical significance of differencesin the densities of vulnerabilities (w.r.t. LOC) in cloned andnon-cloned code. The p-value (p 0.20, p ) obtainedfrom the MWW test implies that observed differences in thedensities of vulnerabilities (w.r.t. LOC) in cloned and noncloned code across all the subject systems are not statisticallysignificant.Analysis Using CDV: Figures 6(a) and 6(b) present thedistributions of CDV in non-cloned code and in different typesof clones respectively over all the systems. Interestingly, thepattern of the distributions of vulnerabilities is similar to thepattern observed in Figures 2(a) and 2(b) drawn for FDV.Similar to Figure 5, Figure 7 presents the densities of vulnerabilities (i.e., CDV) w.r.t. LOC (computed using EquationB. Densities of Vulnerabilities in Different Types of ClonesAnalysis Using FDV: The distribution of FDV portrayedin Figure 2(b) shows that the pure Type-2 clones are foundto have the minimum vulnerabilities whereas the number ofvulnerabilities found in Type-1 clones is higher than thatin pure Type-2 clones. The vulnerabilities found in clonedportion of source code are found to be dominated by thosefound in pure Type-3 clones. However, the majority of clonedLOC are also in pure Type-3 clones as can be observed inFigure 4(b), which migh
A. Security Vulnerabilities A software security vulnerability is defined as a weakness in a software system that can lead to a compromise in integrity, availability or confidentiality of that software system. For example, buffer overflow and dangling pointers are two well known security vulnerabilities. The cyber security community
Each Microsoft Security Bulletin is comprised of one or more vulnerabilities, applying to one or more Microsoft products. Similar to previous reports, Remote Code Execution (RCE) accounts for the largest proportion of total Microsoft vulnerabilities throughout 2018. Of the 292 RCE vulnerabilities, 178 were considered Critical.
The security threats and vulnerabilities of mobile Quran ap-plications can be viewed from both developers’ and a service perspective. Similar to other apps categories like entertainment apps, games apps, bank-ing apps and many others, understanding the threats and vulnerabilities of mobile Quran apps and the ways to manage them is crucial.
Towards Understanding Android System Vulnerabilities: . could be due to the difficulty of understanding low-level system vulnerabilities and the lack of analysis resources. The recent arise of bug bounty programs gives researchers a new source to systematically analyzing vulnerabilities. For example,
operating system (OS) security, or network level security. The vulnerabilities and suggested mitigations are based on observations made during CS assessments. Each vulnerability section will conclude with an actual CS example. SECURITY POLICIES AND PROCEDURES . Effective security policies and procedures ar
priority security vulnerabilities. However, the study was lim-ited to official images and a small random sampling of com-munity images. Additionally, Docker Inc. has worked with the Center for Internet Security (CIS) to release a Docker Security Benchmark to recommend best security practices for deploying Docker [5]. In May 2016, Docker Inc. also
vulnerabilities in Java. In our evaluation, we nd 41 security vulnerabilities in 150 Java programs collected from Github with a 11% false positive rate. 2 Overview We illustrate our technique using the code snippet shown in Fig. 1, which shows two relevant classes, namely RegExValidator, that is used to validate that cer-
Why Database security? Database vulnerabilities affect all database vendors –Some vendors (like Oracle) are more affected than others. On 2006 Oracle released 4 Critical Patch Updates related to database servers –Fixed more than 20 remote vulnerabilities!!! On 2007 there are still 50 unpatched vulnerabilities on Oracle Database
An Introduction to Effective Field Theory Thinking Effectively About Hierarchies of Scale C.P. BURGESSc. i Preface It is an everyday fact of life that Nature comes to us with a variety of scales: from quarks, nuclei and atoms through planets, stars and galaxies up to the overall Universal large-scale structure. Science progresses because we can understand each of these on its own terms, and .
