Analyser le code permet de vérifier ses fonctionnalités, détecter des bogues ou améliorer sa performance. L’analyse du code peut être statique ou dynamique. Des approches combinants les deux analyses sont plus appropriées pour les applications de taille industrielle où l’utilisation individuelle de chaque approche ne peut fournir les résultats souhaités. Les approches combinées appliquent l’analyse dynamique pour déterminer les portions à problèmes dans le code et effectuent par la suite une analyse statique concentrée sur les parties identifiées. Toutefois les outils d’analyse dynamique existants génèrent des données imprécises ou incomplètes, ou aboutissent en un ralentissement inacceptable du temps d’exécution. Lors de ce travail, nous nous intéressons à la génération de graphes d’appels dynamiques complets ainsi que d’autres informations nécessaires à la détection des portions à problèmes dans le code. Pour ceci, nous faisons usage de la technique d’instrumentation dynamique du bytecode Java pour extraire l’information sur les sites d’appels, les sites de création d’objets et construire le graphe d’appel dynamique du programme. Nous démontrons qu’il est possible de profiler dynamiquement une exécution complète d’une application à temps d’exécution non triviale, et d’extraire la totalité de l’information à un coup raisonnable. Des mesures de performance de notre profileur sur trois séries de benchmarks à charges de travail diverses nous ont permis de constater que la moyenne du coût de profilage se situe entre 2.01 et 6.42. Notre outil de génération de graphes dynamiques complets, nommé dyko, constitue également une plateforme extensible pour l’ajout de nouvelles approches d’instrumentation. Nous avons testé une nouvelle technique d’instrumentation des sites de création d’objets qui consiste à adapter les modifications apportées par l’instrumentation au bytecode de chaque méthode. Nous avons aussi testé l’impact de la résolution des sites d’appels sur la performance générale du profileur. / Code analysis is used to verify code functionality, detect bugs or improve its performance. Analyzing the code can be done either statically or dynamically. Approaches combining both analysis techniques are most appropriate for industrial-scale applications where each one individually cannot provide the desired results. Blended analysis, for example, first applies dynamic analysis to identify problematic code regions and then performs a focused static analysis on these regions. However, the existing dynamic analysis tools generate inaccurate or incomplete data, or result in an unacceptably slow execution times. In this work, we focus on the generation of complete dynamic call graphs with additional information required for blended analysis. We make use of dynamic instrumentation techniques of Java bytecode to extract information about call sites and object creation sites, and to build the dynamic call graph of the program. We demonstrate that it is possible to profile real-world applications to efficiently extract complete and accurate information. Performance measurement of our profiler on three sets of benchmarks with various workloads places the overhead of our profiler between 2.01 and 6.42. Our profiling tool generating complete dynamic graphs, named dyko, is also an extensible platform for evaluating new instrumentation approaches. We tested a new adaptive instrumentation technique for object creation sites which accommodates instrumentation to the bytecode of each method. We also tested the impact of call sites resolution on the overall performance of the profiler.

Made available in DSpace on 2014-12-17T15:48:02Z (GMT). No. of bitstreams: 1 HugoFM_DISSERT.pdf: 1847783 bytes, checksum: 58d9312a629dabdd3fe4b15c8dc44101 (MD5) Previous issue date: 2012-07-26 / The Exception Handling (EH) is a widely used mechanism for building robust systems. In Software Product Line (SPL) context it is not different. As EH mechanisms are embedded in most of mainstream programming languages (like Java, C# and C++), we can find exception signalers and handlers spread over code assets associated to common and variable SPL features. When exception signalers and handlers are added to an SPL in an unplanned way, one of the possible consequences is the generation of faulty family instances (i.e., instances on which common or variable features signal exceptions that are mistakenly caught inside the system). In this context, some questions arise: How exceptions flow between the optional and alternative features an LPS? Aiming at providing answers to these questions, this master thesis conducted an exploratory study, based on code inspection and static analysis code, whose goal was to categorize the main ways which exceptions flow in LPSs. To support the study, we developed an static analysis tool called PLEA (Product Line Exception Analyzer) that calculates the exceptional flows of LPSs, and categorize these flows according to the features associated with handlers and signalers. Preliminary results showed that some types of exceptional flows have more potential to yield failures in exceptional behavior of SLPs / O mecanismo de tratamento de exce??es ? amplamente utilizado para a constru??o de sistemas robustos. No contexto de Linhas de Produto de Software (LPSs) n?o ? diferente. Uma vez que mecanismos de tratamento de exce??es est?o embutidos nas principais linguagens de programa??o da atualidade (como Java, C# e C++), podemos encontrar sinalizadores e tratadores de exce??es espalhados entre os artefatos de c?digo associados a caracter?sticas (do ingl?s: features) opcionais e obrigat?rias de uma LPS. Quando tratadores ou sinalizadores de exce??es s?o adicionados a uma LPS de forma n?o planejada, uma das poss?veis conseq??ncias ? a gera??o de produtos falhos (i.e., produtos em que exce??es lan?adas por features vari?veis ou obrigat?rias s?o erroneamente tratadas). Neste contexto, surge a pergunta: Quais as consequ?ncias de se usar o mecanismo de tratamento de exce??es em LPSs? Com o objetivo de responder a esta pergunta, este trabalho conduz um estudo explorat?rio, baseado em inspe??o de c?digo e an?lise est?tica de c?digo, cujo objetivo foi caracterizar as principais formas em que exce??es fluem em LPSs. Para apoiar a realiza??o deste estudo desenvolvemos a PLEA (Product Line Exception Analyzer), uma ferramenta baseada em analise est?tica de c?digo que calcula os fluxos excepcionais de uma LPS e os classifica de acordo com as features associadas aos seus tratadores e sinalizadores. Resultados preliminares mostraram que alguns tipos de fluxos excepcionais tem mais potencial para originarem falhas no comportamento excepcional das LPSs

Le frelatage (ou fuzzing) est l'une des approches les plus efficaces pour la détection de vulnérabilités dans les logiciels de tailles importantes et dont le code source n'est pas disponible. Malgré une utilisation très répandue dans l'industrie, les techniques de frelatage "classique" peuvent avoir des résultats assez limités, et pas toujours probants. Ceci est dû notamment à une faible couverture des programmes testés, ce qui entraîne une augmentation du nombre de faux-négatifs; et un manque de connaissances sur le fonctionnement interne de la cible, ce qui limite la qualité des entrées générées. Nous présentons dans ce travail une approche automatique de recherche de vulnérabilités logicielles par des processus de test combinant analyses avancées de code binaire et frelatage. Cette approche comprend : une technique de minimisation de suite de tests, pour optimiser le rapport entre la quantité de code testé et le temps d'exécution ; une technique d'analyse de couverture optimisée et rapide, pour évaluer l'efficacité du frelatage ; une technique d'analyse statique, pour localiser les séquences de codes potentiellement sensibles par rapport à des patrons de vulnérabilités; une technique dynamique d'analyse de teinte, pour identifier avec précision les zones de l'entrée qui peuvent être à l'origine de déclenchements de vulnérabilités; et finalement une technique évolutionniste de génération de test qui s'appuie sur les résultats des autres analyses, afin d'affiner les critères de décision et d'améliorer la qualité des entrées produites. Cette approche a été mise en œuvre à travers une chaîne d'outils intégrés et évalués sur de nombreuses études de cas fournies par l'entreprise. Les résultats obtenus montrent son efficacité dans la détection automatique de vulnérabilités affectant des applications majeures et sans accès au code source. / Fuzz testing (a.k.a. fuzzing) is one of the most effective approaches for discovering security vulnerabilities in large and closed-source software. Despite their wide use in the software industry, traditional fuzzing techniques suffer from a poor coverage, which results in a large number of false negatives. The other common drawback is the lack of knowledge about the application internals. This limits their ability to generate high quality inputs. Thus such techniques have limited fault detection capabilities. We present an automated smart fuzzing approach which combines advanced binary code analysis techniques. Our approach has five components. A test suite reduction technique, to optimize the ratio between the amount of covered code and the execution time. A fast and optimized code coverage measurement technique, to evaluate the fuzzing effectiveness. A static analysis technique, to locate potentially sensitive sequences of code with respect to vulnerability patterns. An origin-aware dynamic taint analysis technique, to precisely identify the input fields that may trigger potential vulnerabilities. Finally, an evolutionary based test generation technique, to produce relevant inputs. We implemented our approach as an integrated tool chain, and we evaluated it on numerous industrial case studies. The obtained results demonstrate its effectiveness in automatically discovering zero-day vulnerabilities in major closed-source applications. Our approach is relevant to both defensive and offensive security purposes.

A number of logical code coverage criteria have been used throughout the years in the testing of safety-critical software. Kaminski, et al. proposed Relational Operator Replacement Global (RORG), a method to bring benefits from ROR mutation to Modified Condition / Decision Coverage (MCDC), which is widely used in the avionics industry. However, there is a lack of studies in the industry to support this method. In this thesis, we report on the results of applying RORG to avionic code, augmenting an MCDC adequate test set to satisfy RORG, evaluating its ability to find real faults in industrial software. Conclusions drawn from this thesis are: (1) Faults in relational operators in avionic code are rare, no faults were found in this study. (2) 24% of the relational operators in our study would require additional software requirements to be verified for RORG coverage. (3) 37% of the relational operators in our study were infeasible to test due to program semantics. (4) 84% of the tests added covered enumeration comparisons.

Object-oriented languages have made a shift towards incorporating functional concepts such as lambdas. Lambdas are anonymous functions that can be used within the scope of other functions. In C++ lambdas are considered difficult to use for inexperienced developers. This implies that there may be problems with lambdas in C++. However, studies about lambdas in C++ repositories are scarce, compared to other object-oriented languages such as Java. This study aims to address a knowledge gap regarding how lambdas are used by developers in C++ repositories. Furthermore, examine how developer experience and software engineering practices, such as unit testing and in-code documentation, correlates with the inclusion of lambdas. To achieve this we create a set of tools that statically analyse repositories to gather results. This study gained insight into the number of repositories utilising lambdas, their usage areas, and documentation but also how these findings compare to similar studies’ results in Java. Further, it is shown that unit testing and developer experience correlates with the usage of lambdas. / Objektorienterade språk har gjort en förskjutning mot att integrera funktionella begrepp som lambdas. Lambdas är anonyma funktioner som kan användas inom ramen för andra funktioner. I C ++ anses lambdas vara svåra att använda för oerfarna utvecklare. Detta innebär att det kan vara problem med lambdas i C ++. Emellertid är studier på lambdas i C ++ repositorier mindre vanliga jämfört med andra objektorienterade språk som Java. Denna studie syftar till att ta itu med ett kunskapsgap beträffande hur lambdas används av utvecklare i C++ repositorier. Dessutom undersöks hur utvecklarvanor och sedvänjor i programvaruutveckling, till exempel enhetstestning och dokumentation, korrelerar med inkluderingen av lambdas. För att uppnå detta skapar vi en uppsättning verktyg som statiskt analyserar repositorier för att samla resultat. Denna studie fick inblick i antalet repositorier som använder lambdas, deras användningsområden och dokumentation men också hur dessa resultat jämför sig med liknande studieresultat i Java. Vidare har det visats att enhetstestning och utvecklaren erfarenhet korrelerar med användningen av lambdas.

Security deficiencies that occur in web applications can have major consequences. PHP is a language that is often used for web applications and it places high demands on how the language is used to ensure it is safe. There are several features in PHP that should be handled with care to avoid security flaws. Static code analysis can help find vulnerabilities in code, but there are some drawbacks that can occur with static code analysis tools. One disadvantage is false positives which means that the tool reports vulnerabilities that do not exist. There are also false negatives which means the tool cannot find the vulnerability at all which can lead to a false sense of security for the user of the tool. With the help of completed test cases, three tools have been investigated in a case study to find out if the tools differ in their ability to avoid false positives and false negatives. The study also examines whether the tools' rules consider the PHP language's vulnerable functions. To answer the research question, a document collection was conducted to obtain information about the tools and various vulnerabilities. The purpose of this study is to compare the ability of static code analysis tools to find PHP code vulnerabilities. The tools that were investigated were SonarQube, Visual Code Grepper (VCG) and Exakat. The study's analysis shows that VCG found the most vulnerabilities but failed to avoid false positive vulnerabilities. Exakat had zero false positives but could not avoid false negatives to the same extent as VCG. SonarQube avoided all false positives but did not find any of the vulnerabilities tested in the test cases. According to the rules of the tools, VCG had more consideration for the risky functions found in PHP. The study's results show that the tools' ability to avoid false positives and false negatives differed and their adaptation to the PHP language's vulnerable functions. / Säkerhetsbrister som förekommer i webbapplikationer kan leda till stora konsekvenser. PHP är ett språk som ofta används för webbapplikationer och det ställer höga krav på hur språket används för att det ska vara säkert. Det finns flera funktioner i PHP som bör hanteras varsamt för att inte säkerhetsbrister ska uppstå. Statisk kodanalys kan hjälpa till med att hitta sårbarheter i kod men det finns vissa nackdelar som kan uppkomma med statiska kodanalysverktyg. En nackdel är falska positiva vilket betyder att verktyget rapporterar in sårbarheter som inte finns. Det finns också falska negativa som betyder att verktyget inte hittar sårbarheten alls vilket kan leda till en falsk trygghetskänsla för användaren av verktyget. Med hjälp av färdiga testfall så har tre verktyg utretts i en fallstudie för att ta reda på om verktygen skiljer sig i sin förmåga till att undvika falska positiva och falska negativa. Studien undersöker också om verktygens regler tar PHP-språkets sårbara funktioner i beaktning. För att kunna besvara forskningsfrågan har en dokumentsinsamling genomförts för att få information om verktygen och olika sårbarheter. Studiens syfte är att jämföra statiska kodanalysverktygs förmåga att hitta sårbarheter i PHP-kod. De verktyg som utreddes var SonarQube, Visual Code Grepper (VCG) och Exakat. Studiens analys visar att VCG hittade mest sårbarheter men lyckades inte undvika falska positiva sårbarheter. Exakat hade noll falska positiva men kunde inte undvika falska negativa i lika stor utsträckning som VCG. SonarQube undvek alla falska positiva men hittade inte någon av de sårbarheter som testades i testfallen. Enligt verktygens regler visade sig VCG ta mest hänsyn till de riskfyllda funktioner som finns i PHP. Studiens resultat visar att verktygens förmåga att undvika falska positiva och falska negativa och deras anpassning för PHP språkets sårbara funktioner skiljde sig åt.

In the aviation industry, the use of software development tools is not as easily adopted as in other industries. Due to the catastrophic consequences of software errors in airborne systems, software development processes has rigorous requirements. One of these requirements is that a code standard must be followed. Code standards are used to exclude code constructions which could result in unwanted behaviours. The process of manually ensuring a specific code standard can be costly. This process could be automated by a tool for static code analysis, however, this requires a formal qualification. This thesis evaluates the process of qualifying a tool for static code analysis in accordance with the requirements of the major aviation authorities EASA and FAA. To describe the qualification process, a literature study was conducted. To further explain how an existing tool could be put through the qualification process, a case study of the existing tool Parasoft C/C++ test was conducted. The results of the literature study show what processes must be completed in order to qualify a static code analysis tool. Importantly, the study shows that no requirements are put on the development process of the tool. This was an important takeaway as it meant that an existing tool could be qualified without any additional data from the developer of the tool. The case study of Parasoft C/C++ test showed how the tool could be configured and verified to analyze code in accordance with a small set of code rules. Furthermore, three documents including qualification data were produced showing how the qualification process should be documented in order to communicate the process to an authority. The results of the thesis do not provide the full picture of how a tool could be qualified as the software, in which the tool is used, is considerations the are specific to the software the tool is used to develop still need to be taken into consideration. The thesis does, however, provide guidance on the majority of the applicable requirements. Future research could be done to provide the complete picture of the qualification process, as well as how the process would look like for other types of tools. / Inom flygindustrin är användandet av olika programmeringsverktyg inte lika självklart som inom andra industrier. På grund av de katastrofala konsekvenser som fel i mjukvaran i ett flygplan kan resultera i finns det rigorösa krav på mjukvaruutvecklingsprocessen. Ett av dessa krav är att en viss kodstandard måste upprätthållas. Kodstandarder används för att exkludera vissa strukturer i kod som kan leda till oönskat beteende. Upprätthållandet av en viss kodstandard är en långdragen process att genomföra manuellt, och kan därför automatiseras med hjälp av ett statiskt kodanalysverktyg. För att kunna använda ett sådant verktyg behövs däremot en formell verktygskvalificering. I denna uppsats kommer kvalificeringsprocessen av ett verktyg för statisk kodanalys att evalueras enligt de krav som de två stora flygmyndigheterna EASA och FAA ställer. För att förklara processen av att kvalificera ett sådant verktyg gjordes en litteraturstudie följt av en fallstudie av det existerande verktyget Parasoft C/C++ test. Resultaten av litteraturstudien beskriver de olika processerna som måste genomföras för att kvalificera ett statiskt kodanalysverktyg. Noterbart är att resultaten visar att inga krav ställs på utvecklingsprocessen av verktyget själv. Detta betyder att ett existerande kommersiellt verktyg kan kvalificeras utan att verktygsutvecklarna själva behöver bidra med extra information. Fallstudien visade hur verktyget Parasoft C/C++ test kan konfigureras och verifieras att följa en viss kodstandard. Vidare resulterade fallstudien i utkast av de nödvändiga dokumenten som behöver produceras för att kommunicera kvalificeringsprocessen till en myndighet. De resultat som presenteras i denna uppsats är i sig inte tillräckliga för beskriva hela kvalificeringsprocessen. Ytterligare överväganden som är specifika till den mjukvaran som verktyget ska användas till att utveckla måste göras för att en komplett kvalificering ska kunna genomföras. Uppsatsen bidrar däremot med riktlinjer och vägledning av majoriteten av de processerna som behöver genomföras. Ytterligare forskning kan göras för att bidra med den kompletta bilden av verktygskvalificering av ett statiskt kodanalysverktyg, samt hur kvalificering kan göras av andra typer av verktyg.

Nous proposons une approche basée sur la formulation interactive des requêtes. Notre approche sert à faciliter des tâches d’analyse et de compréhension du code source. Dans cette approche, l’analyste utilise un ensemble de filtres de base (linguistique, structurel, quantitatif, et filtre d’interactivité) pour définir des requêtes complexes. Ces requêtes sont construites à l’aide d’un processus interactif et itératif, où des filtres de base sont choisis et exécutés, et leurs résultats sont visualisés, changés et combinés en utilisant des opérateurs prédéfinis. Nous avons évalués notre approche par l’implantation des récentes contributions en détection de défauts de conception ainsi que la localisation de fonctionnalités dans le code. Nos résultats montrent que, en plus d’être générique, notre approche aide à la mise en œuvre des solutions existantes implémentées par des outils automatiques. / We propose an interactive querying approach for program analysis and comprehension tasks. In our approach, an analyst uses a set of basic filters (linguistic, structural, quantitative, and user selection) to define complex queries. These queries are built following an interactive and iterative process where basic filters are selected and executed, and their results displayed, changed, and combined using predefined operators. We evaluated our querying approach by implementing recent state-of-the-art contributions on feature location and design defect detection. Our results show that, in addition to be generic; our approach helps improving existing solutions implemented by fully-automated tools.

Nous proposons une approche basée sur la formulation interactive des requêtes. Notre approche sert à faciliter des tâches d’analyse et de compréhension du code source. Dans cette approche, l’analyste utilise un ensemble de filtres de base (linguistique, structurel, quantitatif, et filtre d’interactivité) pour définir des requêtes complexes. Ces requêtes sont construites à l’aide d’un processus interactif et itératif, où des filtres de base sont choisis et exécutés, et leurs résultats sont visualisés, changés et combinés en utilisant des opérateurs prédéfinis. Nous avons évalués notre approche par l’implantation des récentes contributions en détection de défauts de conception ainsi que la localisation de fonctionnalités dans le code. Nos résultats montrent que, en plus d’être générique, notre approche aide à la mise en œuvre des solutions existantes implémentées par des outils automatiques. / We propose an interactive querying approach for program analysis and comprehension tasks. In our approach, an analyst uses a set of basic filters (linguistic, structural, quantitative, and user selection) to define complex queries. These queries are built following an interactive and iterative process where basic filters are selected and executed, and their results displayed, changed, and combined using predefined operators. We evaluated our querying approach by implementing recent state-of-the-art contributions on feature location and design defect detection. Our results show that, in addition to be generic; our approach helps improving existing solutions implemented by fully-automated tools.

Establishing and preserving a high level of software quality is a not a trivial task, although the benefits of succeeding with this task has been proven profitable and advantageous. An approach to mitigate the decreasing quality of a project is to track metrics and certain properties of the project, in order to view the progression of the project’s properties. This approach may be carried out by introducing continuous code inspection with the application of static code analysis. However, as the initial common opinion is that these type of tools produce a too high number of false positives, there is a need to investigate what the actual case is. This is the origin for the investigation and case study performed in this paper. The case study is performed at Ida Infront AB in Linköping, Sweden and involves interviews with developers to determine the performance of the continuous inspection platform SonarQube, in addition to examine the general opinion among developers at the company. The author executes the implementation and configuration of a continuous inspection environment to analyze a partition of the company’s product and determine what rules that are appropriate to apply in the company’s context. The results from the investigation indicate the high quality and accuracy of the tool, in addition to the advantageous functionality of continuously monitoring the code to observe trends and the progression of metrics such as cyclomatic complexity and duplicated code, with the goal of preventing the constant increase of complex and duplicated code. Combining this with features such as false positive suppression, instant analysis feedback in pull requests and the possibility to break the build given specified conditions, suggests that the implemented environment is a way to mitigate software quality difficulties. / 建立和保持高水平的软件质量可以带来经济利益等诸多好处，然而这是一项很困难的任务。其中一种防止软件项目质量下降的方法是通过跟踪项目的度量值和某些属性，来查看项目的属性的变化情况。通过引入持续的代码审查和应用静态代码分析方法可以实现这种方法。然而，在人们的印象中，这类工具往往具有较高的误检，因此需要进一步调查实际情况、研究其可行性，这是本文的初始研究目标。本文在瑞典林雪平的Ida Infront AB公司开展了案例研究，调研了该公司开发人员的意见，并通过访问开发人员，确定持续的代码审查平台SonarQube的性能。作者对持续的代码审查环境进行了配置，分析了公司的部分产品，进而确定哪些规则适用于该公司。调查结果表明该工具是高质量并且准确的，还提供了持续监测代码来观察度量值的趋势和进展等先进功能，例如通过监测环路复杂度和重复代码等度量值，来防止复杂度和重复代码的增加。通过组合误检压缩、对pull requests的瞬间分析反馈、以及分解和建立给定的条件等特征，使得所实现的环境成为一种可以降低软件质量保障难度的方式。