DOCSLIB.ORG

Code Review Guide

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Code Review Guide CODE REVIEW GUIDE 2.0 RELEASE Project leaders: Larry Conklin and Gary Robinson Creative Commons (CC) Attribution Free Version at: https://www.owasp.org 1 F I 1 Forward - Eoin Keary Introduction How to use the Code Review Guide 7 8 10 2 Secure Code Review 11 Framework Specific Configuration: Jetty 16 2.1 Why does code have vulnerabilities? 12 Framework Specific Configuration: JBoss AS 17 2.2 What is secure code review? 13 Framework Specific Configuration: Oracle WebLogic 18 2.3 What is the difference between code review and secure code review? 13 Programmatic Configuration: JEE 18 2.4 Determining the scale of a secure source code review? 14 Microsoft IIS 20 2.5 We can’t hack ourselves secure 15 Framework Specific Configuration: Microsoft IIS 40 2.6 Coupling source code review and penetration testing 19 Programmatic Configuration: Microsoft IIS 43 2.7 Implicit advantages of code review to development practices 20 2.8 Technical aspects of secure code review 21 2.9 Code reviews and regulatory compliance 22 5 A1 3 Injection 51 Injection 52 Blind SQL Injection 53 Methodology 25 Parameterized SQL Queries 53 3.1 Factors to Consider when Developing a Code Review Process 25 Safe String Concatenation? 53 3.2 Integrating Code Reviews in the S-SDLC 26 Using Flexible Parameterized Statements 54 3.3 When to Code Review 27 PHP SQL Injection 55 3.4 Security Code Review for Agile and Waterfall Development 28 JAVA SQL Injection 56 3.5 A Risk Based Approach to Code Review 29 .NET Sql Injection 56 3.6 Code Review Preparation 31 Parameter collections 57 3.7 Code Review Discovery and Gathering the Information 32 3.8 Static Code Analysis 35 3.9 Application Threat Modeling 39 4.3.2. Step 1: Decompose the Application 39 5 A2 5.4.3. Step 2: Determine and rank threats 42 5.4.4. Step 3: Determine countermeasures and mitigation 45 Broken Authentication And Session Management 3.10 Metrics and Code Review 45 60 A2 Broken Authentication 3.11 Crawling Code 49 60 Forgot Password 62 CAPTCHA 63 Out-of-Band Communication 64 4 A2 Session Management 66 .Net ASPX web.confi 67 Java web.xml 68 Reviewing by Framework 9 PHP.INI 68 Apache Struts 10 .Net ASPX 68 Java Enterprise Edition Declarative Configuration 10 Java 68 JEE Annotations 11 PHP 68 Framework Specific Configuration: Apache Tomcat 15 Session Attacks 69 2 Session Hijacking 69 4.5 Framework Specific Configuration: Jetty 84 Session Fixation 69 4.6 Framework Specific Configuration: JBoss AS 86 Session Elevation 70 4.7 Framework Specific Configuration: Oracle WebLogic 86 Server-Side Defenses for Session Management 70 4.8 Programmatic Configuration: JEE 86 .NET ASPX 70 4.9 Microsoft IIS 89 Java 70 4.10 Framework Specific Configuration: Microsoft IIS 90 PHP.INI 70 4.11 Programmatic Configuration: Microsoft IIS 93 4.12 Further IIS Configurations 94 4.13 Strongly Named Assemblies 102 4.15 Round Tripping A3 105 5 4.16 .NET Authentication Controls 107 Cross-Site Scripting (Xss) 71 Use Microsft’s Anti-XSS library 72 5 A6 .NET ASPX 72 .NET MVC 72 JavaScript and JavaScript Frameworks 72 Sensitive Data Exposure 112 1.1 Cryptographic Controls 112 1.1.1 Description 112 1.1.2 What to Review: Protection in Transit A4 112 5 1.1.3 What to Review: Protection at Rest 115 1.1.4 References 121 1.1.5 Encryption, Hashing & Salting 121 Insecure Direct Object Reference 74 1.1.6 References 124 SQL Injection 74 1.2 Reducing the attack surface 125 HTTP POST requests 74 1.2.1 Description 125 Indirect Reference Maps 75 1.2.2 What to Review 125 Data Binding Technique 75 1.2.3 References 126 Secure Design Recommendation: 76 Review Criteria 76 What the Code Reviewer needs to do: 76 Binding issues in MVC .NET 76 5 A7 A.K.A Over-Posting A.K.A Mass assignments 76 Corresponding view (HTML) 76 Recommendations 77 Missing Function Level Access Control 127 1.3.1 Authorization 127 1.3.2 Description 127 1.3.3 What to Review A5 129 5 1.4 From Access Control Cheat Sheet 131 Security Misconfiguration 78 4.1 Apache Struts 78 4.2 Java Enterprise Edition Declarative Configuration 79 4.3 JEE Annotations 83 4.4 Framework Specific Configuration: Apache Tomcat 84 3 5 A8 Cross-Site Request Forgery (CSRF) 133 5.5.4 What to Review: Potentially Vulnerable Code 156 2.1 Description 133 5.5.5 What to Review: Error Handling in IIS 158 2.2 What to Review 134 5.5.6 What to Review: Error Handling in Apache 160 2.3 References 139 5.6 What to Review: Leading Practice for Error Handling 161 5.6.1 What to Review: The Order of Catching Exceptions 162 5.6.2 What to Review: Releasing resources and good housekeeping 163 5.6.3 References A9 164 5 5.7 Reviewing Security alerts 164 5.7.1 Description 164 5.7.2 What to Review 166 Using Components With Known Vulnerabilities 140 5.7.3 References 167 3.1 Description 140 5.8 Review for active defense 167 3.2 What to Review 140 5.9 Description 167 3.3 References 141 5.10 What to Review 168 5.11 References 169 5.12 Race Conditions 169 5 A10 5.13 Description 170 5.14 What to Review 170 5.14.1 References 171 5.15 Buffer Overruns 171 Unvalidated Redirects And Forwards 142 5.15.1 Description 171 4.1 Description 142 5.15.2 What to Review: Buffer Overruns 172 4.2 What to Review 143 5.15.3 What to Review: Format Function Overruns 173 4.3 References 145 5.15.4 What to Review: Integer Overflows 174 5. AX - General 145 5.16 References 176 5.1 HTML5 145 5.1.1 Description 145 5.1.2 What to Review: Web Messaging 145 5.1.3 What to Review: Cross Origin Resource Sharing 146 6 5.1.4 What to Review: WebSockets 147 5.1.5 What to Review: Server-Sent Events 148 5.2 Same Origin Policy 148 Code Review Do’s And Dont’s 178 5.2.1 Description 149 Code Review Do’s And Dont’s 178 5.3 What to Review 150 5.4 Reviewing Logging code 150 5.4.1 Description 150 5.4.2 What to Review 151 7 5.4.3 References 152 5.5 Error Handling 152 5.5.1 Description 153 Apendix 180 5.5.2 What to Review 154 7.1 Contributors 180 5.5.3 What to Review: Failing Securely 155 4 SDLC Diagrams - 184 184 Code Review Checklist - 191 191 5 F Code Review Guide Foreword - By Eoin Keary 6 Foreword by Eoin Keary, OWASP Global Board The OWASP Code Review guide was originally born from the OWASP Testing Guide. Initially code review was covered in the Testing Guide, as it seemed like a good idea at the time. However, the topic of security code review is too big and evolved into its own stand-alone guide. I started the Code Review Project in 2006. This current edi- tion was started in April 2013 via the OWASP Project Reboot initiative and a grant from the United States Department of Homeland Security. The OWASP Code Review team consists of a small, but tal- ented, group of volunteers who should really get out more often. The volunteers have experience and a drive for the best practices in secure code review in a variety of organi- zations, from small start-ups to some of the largest software development organizations in the world. It is common knowledge that more secure software can be produced and developed in a more cost effective way when bugs are detected early on in the systems development lifecycle. Organizations with a proper code review function integrated into the software development lifecycle (SDLC) produced remarkably better code from a security stand- point. To put it simply “We can’t hack ourselves secure”. At- tackers have more time to find vulnerabilities on a system than the time allocated to a defender. Hacking our way se- cure amounts to an uneven battlefield, asymmetric warfare, and a losing battle. By necessity, this guide does not cover all programming lan- guages. It mainly focuses on C#/.NET and Java, but includes C/C++, PHP and other languages where possible. However, the techniques advocated in the book can be easily adapted to almost any code environment. Fortunately (or unfortu- nately), the security flaws in web applications are remark- ably consistent across programming languages. Eoin Keary, OWASP Board Member, April 19, 2013 7 Introduction - Contents I INTRODUCTION Welcome to the second edition of the OWASP Code Review Guide Project. The second edition brings the successful OWASP Code Review Guide up to date with current threats and countermeasures. This ver- sion also includes new content reflecting the OWASP communities’ experiences of secure code review best practices. C CONTENTS The Second Edition of the Code Review Guide has been developed to advise software developers and management on the best practices in secure code review, and how it can be used within a secure soft- ware development life-cycle (S-SDLC). The guide begins with sections that introduce the reader to secure code review and how it can be introduced into a company’s S-SDLC. It then concentrates on specific technical subjects and provides examples of what a reviewer should look for when reviewing technical code. Specifically the guide covers: Overview This section introduces the reader to secure code review and the advantages it can bring to a devel- opment organization.
Load more

Recommended publications
  • Pragmatic Version Control Using Subversion
    What readers are saying about Pragmatic Version Control using Subversion I expected a lot, but you surprised me with even more. Hav- ing used CVS for years I hesitated to try Subversion until now, although I knew it would solve many of the shortcom- ings of CVS. After reading your book, my excuses to stay with CVS disappeared. Oh, and coming from the Pragmatic Bookshelf this book is fun to read too. Thanks Mike. Steffen Gemkow Managing Director, ObjectFab GmbH I’m a long-time user of CVS and I’ve been skeptical of Sub- version, wondering if it would ever be “ready for prime time.” Until now. Thanks to Mike Mason for writing a clear, con- cise, gentle introduction to this new tool. After reading this book, I’m actually excited about the possibilities for version control that Subversion brings to the table. David Rupp Senior Software Engineer, Great-West Life & Annuity This was exactly the Subversion book I was waiting for. As a long-time Perforce and CVS user and administrator, and in my role as an agile tools coach, I wanted a compact book that told me just what I needed to know. This is it. Within a couple of hours I was up and running against remote Subversion servers, and setting up my own local servers too. Mike uses a lot of command-line examples to guide the reader, and as a Windows user I was worried at first. My fears were unfounded though—Mike’s examples were so clear that I think I’ll stick to using the command line from now on! I thoroughly recommend this book to anyone getting started using or administering Subversion.
    [Show full text]
  • Static Analysis the Workhorse of a End-To-End Securitye Testing Strategy
    Static Analysis The Workhorse of a End-to-End Securitye Testing Strategy Achim D. Brucker [email protected] http://www.brucker.uk/ Department of Computer Science, The University of Sheffield, Sheffield, UK Winter School SECENTIS 2016 Security and Trust of Next Generation Enterprise Information Systems February 8–12, 2016, Trento, Italy Static Analysis: The Workhorse of a End-to-End Securitye Testing Strategy Abstract Security testing is an important part of any security development lifecycle (SDL) and, thus, should be a part of any software (development) lifecycle. Still, security testing is often understood as an activity done by security testers in the time between “end of development” and “offering the product to customers.” Learning from traditional testing that the fixing of bugs is the more costly the later it is done in development, security testing should be integrated, as early as possible, into the daily development activities. The fact that static analysis can be deployed as soon as the first line of code is written, makes static analysis the right workhorse to start security testing activities. In this lecture, I will present a risk-based security testing strategy that is used at a large European software vendor. While this security testing strategy combines static and dynamic security testing techniques, I will focus on static analysis. This lecture provides a introduction to the foundations of static analysis as well as insights into the challenges and solutions of rolling out static analysis to more than 20000 developers, distributed across the whole world. A.D. Brucker The University of Sheffield Static Analysis February 8–12., 2016 2 Today: Background and how it works ideally Tomorrow: (Ugly) real world problems and challenges (or why static analysis is “undecideable” in practice) Our Plan A.D.
    [Show full text]
  • List of Requirements for Code Reviews
    WP2 DIGIT B1 - EP Pilot Project 645 Deliverable 9: List of Requirements for Code Reviews Specific contract n°226 under Framework Contract n° DI/07172 – ABCIII April 2016 DIGIT Fossa WP2 – Governance and Quality of Software Code – Auditing of Free and Open Source Software. Deliverable 9: List of requirements for code reviews Author: Disclaimer The information and views set out in this publication are those of the author(s) and do not necessarily reflect the official opinion of the Commission. The content, conclusions and recommendations set out in this publication are elaborated in the specific context of the EU – FOSSA project. The Commission does not guarantee the accuracy of the data included in this study. All representations, warranties, undertakings and guarantees relating to the report are excluded, particularly concerning – but not limited to – the qualities of the assessed projects and products. Neither the Commission nor any person acting on the Commission’s behalf may be held responsible for the use that may be made of the information contained herein. © European Union, 2016. Reuse is authorised, without prejudice to the rights of the Commission and of the author(s), provided that the source of the publication is acknowledged. The reuse policy of the European Commission is implemented by a Decision of 12 December 2011. Document elaborated in the specific context of the EU – FOSSA project. Reuse or reproduction authorised without prejudice to the Commission’s or the authors’ rights. Page 2 of 51 DIGIT Fossa WP2 – Governance and Quality of Software Code – Auditing of Free and Open Source Software. Deliverable 9: List of requirements for code reviews Contents CONTENTS............................................................................................................................................
    [Show full text]
  • Undefined Behaviour in the C Language
    FAKULTA INFORMATIKY, MASARYKOVA UNIVERZITA Undefined Behaviour in the C Language BAKALÁŘSKÁ PRÁCE Tobiáš Kamenický Brno, květen 2015 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Vedoucí práce: RNDr. Adam Rambousek ii Acknowledgements I am very grateful to my supervisor Miroslav Franc for his guidance, invaluable help and feedback throughout the work on this thesis. iii Summary This bachelor’s thesis deals with the concept of undefined behavior and its aspects. It explains some specific undefined behaviors extracted from the C standard and provides each with a detailed description from the view of a programmer and a tester. It summarizes the possibilities to prevent and to test these undefined behaviors. To achieve that, some compilers and tools are introduced and further described. The thesis contains a set of example programs to ease the understanding of the discussed undefined behaviors. Keywords undefined behavior, C, testing, detection, secure coding, analysis tools, standard, programming language iv Table of Contents Declaration ................................................................................................................................ ii Acknowledgements .................................................................................................................. iii Summary .................................................................................................................................
    [Show full text]
  • Parasoft Dottest REDUCE the RISK of .NET DEVELOPMENT
    Parasoft dotTEST REDUCE THE RISK OF .NET DEVELOPMENT TRY IT https://software.parasoft.com/dottest Complement your existing Visual Studio tools with deep static INCREASE analysis and advanced PROGRAMMING EFFICIENCY: coverage. An automated, non-invasive solution that the related code, and distributed to his or her scans the application codebase to iden- IDE with direct links to the problematic code • Identify runtime bugs without tify issues before they become produc- and a description of how to fix it. executing your software tion problems, Parasoft dotTEST inte- grates into the Parasoft portfolio, helping When you send the results of dotTEST’s stat- • Automate unit and component you achieve compliance in safety-critical ic analysis, coverage, and test traceability testing for instant verification and industries. into Parasoft’s reporting and analytics plat- regression testing form (DTP), they integrate with results from Parasoft dotTEST automates a broad Parasoft Jtest and Parasoft C/C++test, allow- • Automate code analysis for range of software quality practices, in- ing you to test your entire codebase and mit- compliance cluding static code analysis, unit testing, igate risks. code review, and coverage analysis, en- abling organizations to reduce risks and boost efficiency. Tests can be run directly from Visual Stu- dio or as part of an automated process. To promote rapid remediation, each problem detected is prioritized based on configur- able severity assignments, automatical- ly assigned to the developer who wrote It snaps right into Visual Studio as though it were part of the product and it greatly reduces errors by enforcing all your favorite rules. We have stuck to the MS Guidelines and we had to do almost no work at all to have dotTEST automate our code analysis and generate the grunt work part of the unit tests so that we could focus our attention on real test-driven development.
    [Show full text]
  • Parasoft Static Application Security Testing (SAST) for .Net - C/C++ - Java Platform
    Parasoft Static Application Security Testing (SAST) for .Net - C/C++ - Java Platform Parasoft® dotTEST™ /Jtest (for Java) / C/C++test is an integrated Development Testing solution for automating a broad range of testing best practices proven to improve development team productivity and software quality. dotTEST / Java Test / C/C++ Test also seamlessly integrates with Parasoft SOAtest as an option, which enables end-to-end functional and load testing for complex distributed applications and transactions. Capabilities Overview STATIC ANALYSIS ● Broad support for languages and standards: Security | C/C++ | Java | .NET | FDA | Safety-critical ● Static analysis tool industry leader since 1994 ● Simple out-of-the-box integration into your SDLC ● Prevent and expose defects via multiple analysis techniques ● Find and fix issues rapidly, with minimal disruption ● Integrated with Parasoft's suite of development testing capabilities, including unit testing, code coverage analysis, and code review CODE COVERAGE ANALYSIS ● Track coverage during unit test execution and the data merge with coverage captured during functional and manual testing in Parasoft Development Testing Platform to measure true test coverage. ● Integrate with coverage data with static analysis violations, unit testing results, and other testing practices in Parasoft Development Testing Platform for a complete view of the risk associated with your application ● Achieve test traceability to understand the impact of change, focus testing activities based on risk, and meet compliance
    [Show full text]
  • Codesonar the SAST Platform for Devsecops
    DATASHEET CodeSonar The SAST Platform for DevSecOps Accelerate Application Security Software teams are under constant pressure to deliver more content with higher complexity, in shorter timeframes, with increased quality and security. Static Application Security Testing is a proven best practice to help software teams deliver the best code in the shortest timeframe. GrammaTech has been a leader in this field for over 15 years with CodeSonar delivering multi-language SAST capabilities for enterprises where software quality and software security matter. DevSecOps - Speed and Scale Language Support Software developers need rapid feedback on security CodeSonar supports many popular languages, including vulnerabilities in their code. CodeSonar can be integrated into C/C++, Java, C# and Android, as well as support for native software development environments, works unobtrusively to binaries in Intel, Arm and PowerPC instruction set architectures. the developer and provides rapid feedback. CodeSonar also supports OASIS SARIF, for exchange of information with other tools in the DevSecOps environment. Examples of Defects Detected • Buffer over- and underruns • Cast and conversion problems • Command injection • Copy-paste error • Concurrency • Ignored return value • Memory leak • Tainted data • Null pointer dereference • Dangerous function • Unused parameter / value And hundreds more Security Quality Privacy Broad coverage of security vulnerabilities, Integration into DevSecOps to improve Checkers that detect performance including OWASP Top10, SANS/CWE 25. quality of the code and developer impacts such as unnecessary test for Support for third party applications efficiency. Find code quality and nullness, creation of redundant objects or through byte code analysis. performance issues at speed. superfluous memory writes. Team Support Built In CodeSonar is designed to support large teams.
    [Show full text]
  • Devnet Module 3
    Module 3: Software Development and Design DEVASCv1 1 Module Objectives . Module Title: Software Development and Design . Module Objective: Use software development and design best practices. It will comprise of the following sections: Topic Title Topic Objective 3.1 Software Development Compare software development methodologies. 3.2 Software Design Patterns Describe the benefits of various software design patterns. 3.3 Version Control Systems Implement software version control using GIT. 3.4 Coding Basics Explain coding best practices. 3.5 Code Review and Testing Use Python Unit Test to evaluate code. 3.6 Understanding Data Formats Use Python to parse different messaging and data formats. DEVASCv1 2 3.1 Software Development DEVASCv1 3 Introduction . The software development process is also known as the software development life cycle (SDLC). SDLC is more than just coding and also includes gathering requirements, creating a proof of concept, testing, and fixing bugs. DEVASCv1 4 Software Development Life Cycle (SDLC) . SDLC is the process of developing software, starting from an idea and ending with delivery. This process consists of six phases. Each phase takes input from the results of the previous phase. SDLC is the process of developing software, starting from an idea and ending with delivery. This process consists of six phases. Each phase takes input from the results of the previous phase. Although the waterfall methods is still widely used today, it's gradually being superseded by more adaptive, flexible methods that produce better software, faster, with less pain. These methods are collectively known as “Agile development.” DEVASCv1 5 Requirements and Analysis Phase . The requirements and analysis phase involves the product owner and qualified team members exploring the stakeholders' current situation, needs and constraints, present infrastructure, and so on, and determining the problem to be solved by the software.
    [Show full text]
  • Code Review Guide
    CODE REVIEW GUIDE 3.0 RELEASE Project leaders: Mr. John Doe and Jane Doe Creative Commons (CC) Attribution Free Version at: https://www.owasp.org 1 2 F I 1 Forward - Eoin Keary Introduction How to use the Code Review Guide 7 8 10 2 Secure Code Review 11 Framework Specific Configuration: Jetty 16 2.1 Why does code have vulnerabilities? 12 Framework Specific Configuration: JBoss AS 17 2.2 What is secure code review? 13 Framework Specific Configuration: Oracle WebLogic 18 2.3 What is the difference between code review and secure code review? 13 Programmatic Configuration: JEE 18 2.4 Determining the scale of a secure source code review? 14 Microsoft IIS 20 2.5 We can’t hack ourselves secure 15 Framework Specific Configuration: Microsoft IIS 40 2.6 Coupling source code review and penetration testing 19 Programmatic Configuration: Microsoft IIS 43 2.7 Implicit advantages of code review to development practices 20 2.8 Technical aspects of secure code review 21 2.9 Code reviews and regulatory compliance 22 5 A1 3 Injection 51 Injection 52 Blind SQL Injection 53 Methodology 25 Parameterized SQL Queries 53 3.1 Factors to Consider when Developing a Code Review Process 25 Safe String Concatenation? 53 3.2 Integrating Code Reviews in the S-SDLC 26 Using Flexible Parameterized Statements 54 3.3 When to Code Review 27 PHP SQL Injection 55 3.4 Security Code Review for Agile and Waterfall Development 28 JAVA SQL Injection 56 3.5 A Risk Based Approach to Code Review 29 .NET Sql Injection 56 3.6 Code Review Preparation 31 Parameter collections 57 3.7 Code Review Discovery and Gathering the Information 32 3.8 Static Code Analysis 35 3.9 Application Threat Modeling 39 4.3.2.
    [Show full text]
  • Grammatech Codesonar Product Datasheet
    GRAMMATECH CODESONAR PRODUCT DATASHEET Static Code Analysis and Static Application Security Testing Software Assurance Services Delivered by a senior software CodeSonar empowers teams to quickly analyze and validate the code – source and/or binary – engineer, the software assurance identifying serious defects or bugs that cause cyber vulnerabilities, system failures, poor services focus on automating reliability, or unsafe conditions. reporting on your software quality, creating an improvement plan and GrammaTech’s Software Assurance Services provide the benets of CodeSonar to your team in measuring your progress against that an accelerated timeline and ensures that you make the best use of SCA and SAST. plan. This provides your teams with reliable, fast, actionable data. GrammaTech will manage the static Enjoy the Benets of the Deepest Static Analysis analysis engine on your premises for you, such that your resources can Employ Sophisticated Algorithms Comply with Coding Standards focus on developing software. The following activities are covered: CodeSonar performs a unied dataow and CodeSonar supports compliance with standards symbolic execution analysis that examines the like MISRA C:2012, IS0-26262, DO-178B, Integration in your release process computation of the entire program. The US-CERT’s Build Security In, and MITRE’S CWE. Integration in check-in process approach does not rely on pattern matching or similar approximations. CodeSonar’s deeper Automatic assignment of defects analysis naturally nds defects with new or Reduction of parse errors unusual patterns. Review of warnings Analyze Millions of Lines of Code Optimization of conguration CodeSonar can perform a whole-program Improvement plan and tracking analysis on 10M+ lines of code.
    [Show full text]
  • Metrics for Gerrit Code Reviews
    SPLST'15 Metrics for Gerrit code reviews Samuel Lehtonen and Timo Poranen University of Tampere, School of Information Sciences, Tampere, Finland [email protected],[email protected] Abstract. Code reviews are a widely accepted best practice in mod- ern software development. To enable easier and more agile code reviews, tools like Gerrit have been developed. Gerrit provides a framework for conducting reviews online, with no need for meetings or mailing lists. However, even with the help of tools like Gerrit, following and monitoring the review process becomes increasingly hard, when tens or even hun- dreds of code changes are uploaded daily. To make monitoring the review process easier, we propose a set of metrics to be used with Gerrit code review. The focus is on providing an insight to velocity and quality of code reviews, by measuring different review activities based on data, au- tomatically extracted from Gerrit. When automated, the measurements enable easy monitoring of code reviews, which help in establishing new best practices and improved review process. Keywords: Code quality; Code reviews; Gerrit; Metrics; 1 Introduction Code reviews are a widely used quality assurance practice in software engineer- ing, where developers read and assess each other's code before it is integrated into the codebase or deployed into production. Main motivations for reviews are to detect software defects and to improve code quality while sharing knowledge among developers. Reviews were originally introduced by Fagan [4] already in 1970's. The original, formal type of code inspections are still used in many com- panies, but has been often replaced with more modern types of reviews, where the review is not tied to place or time.
    [Show full text]
  • Best Practices for the Use of Static Code Analysis Within a Real-World Secure Development Lifecycle
    An NCC Group Publication Best Practices for the use of Static Code Analysis within a Real-World Secure Development Lifecycle Prepared by: Jeremy Boone © Copyright 2015 NCC Group Contents 1 Executive Summary ....................................................................................................................................... 3 2 Purpose and Motivation ................................................................................................................................. 3 3 Why SAST Often Fails ................................................................................................................................... 4 4 Methodology .................................................................................................................................................. 4 5 Integration with the Secure Development Lifecycle....................................................................................... 5 5.1 Training ................................................................................................................................................. 6 5.2 Requirements ....................................................................................................................................... 6 5.3 Design ................................................................................................................................................... 7 5.4 Implementation ....................................................................................................................................
    [Show full text]