Every Code Review Is a Security Review

If you had a mission statement for your engineering team, it would probably emphasize delivering features, functionality, and value for users.

It probably won’t mention security. This is shortsighted because security is a crucial part of each of those. Insecure products, by definition, don’t function properly, and they certainly don’t bring value to users. Security is a checklist item rather than a foundational element.

This traditional approach, where security checks are relegated to the end of the development process, is akin to locking the doors after the burglars have already entered. However, this methodology is rapidly becoming obsolete. The imperative now is to embed security into the DNA of software development from the first line of code, or “Shift Security Left.”

Let’s consider what this means and how you can integrate it into your development cycles.

Understanding “Shifting Security Left”

"Shift Security Left" is more than just a catchphrase; it's a pivotal strategy reshaping how we approach security in engineering.

The term originates from the DevOps movement and implies moving security to the 'left,' the earlier stage of the software development lifecycle. It's about considering security from the start of the first line of code.

You can think of this literally. What is the first line of code in most development files? An import. Developers import libraries and other engineer’s code without considering the security implications. If you were trying to parse user agent strings in a JavaScript application in 2021, you might have added this line of code to your project:

var parser = require('ua-parser-js');

This would have been a mistake. The code within this project was hacked to install cryptominers and password stealers within users' browsers. Shifting security left means interrogating this line and every subsequent line throughout development.

This is a radical departure from the way it has worked. Traditionally, security has often been a reactive process. Developers would first focus on building functionality, and only after completing a product or a significant feature would security teams step in to identify vulnerabilities. "Shifting Security Left" advocates for a proactive stance. It's about integrating security practices and checks into every development phase, from design and coding to testing and deployment.

Let's consider a practical example. In the traditional model, a team might develop an application and then, after completion, conduct a security audit. This often leads to discovering vulnerabilities that require significant rework, delaying the release and inflating costs. On the other hand, with the "Shift Security Left" approach, the same team would perform security analysis during the coding phase itself, regularly reviewing each other's code for potential vulnerabilities. This identifies issues early when they're easier and less costly to fix and embeds a culture of security within the team.

The benefits of this proactive approach are huge. 

• First, it significantly reduces the risk of security breaches. By identifying and addressing vulnerabilities early, there's less chance for them to be exploited in a released product.
  
  
• Second, it streamlines development. Teams avoid the time-consuming and often frustrating process of revising completed work to fix security issues.
  
  
• Finally, and perhaps most importantly, it shifts the perception of security from a checklist item to a foundational element of quality software. It fosters an environment where security is not an afterthought but a fundamental aspect of the development process.

Shifting security left is transitioning from a reactive, "fix-it-later" approach to a proactive, preventative methodology. By embedding security practices throughout the development lifecycle, we create more secure products and enhance the efficiency and quality of our software development processes.

The Role of Code Reviews in Security

Code reviews have traditionally been viewed as a tool to enhance code quality and maintainability. But they need to include security.

They should already–security is a core component of code quality and maintainability. But this, unfortunately, just isn’t true. Code reviews focus solely on improving code's readability, performance, and maintainability. While these are key objectives, security should be given equal importance. Well-written code vulnerable to attacks is as problematic as poorly-written, inefficient code.

Why doesn’t it have the same weight? A few reasons:

1. Many developers may not be fully aware of the security implications of their code. Without proper training in security best practices, they might not recognize potential vulnerabilities.
   
   
2. In many development teams, the culture prioritizes rapid feature development and deployment. This focus on speed and functionality often comes at the expense of security considerations.
   
   
3. Security can be complex and intimidating, especially for developers not specialized in this area. The complexity of understanding and implementing security measures can be a deterrent.
   
   
4. Developers might underestimate the potential risks or think that their project is not a likely target for attacks. This complacency can lead to a lackadaisical attitude towards security.
   
   
5. If the development environment lacks integrated security tools and processes, it becomes more challenging for developers to incorporate security into their workflow.

Added to these, traditionally, security reviews happen post-development, often conducted by a separate security team. This siloed approach can lead to significant gaps in security. Integrating security checks into regular code reviews bridges this gap, ensuring continuous and comprehensive scrutiny.

Adding Security to Code Review

It’s easy to say this is important. Luckily, it is also easy to implement in your code review process. Imagine a scenario where a developer has written a new feature for an application that involves handling user inputs. Here's how a security-focused code review might unfold:

1. Initial Review. The reviewer checks the code against the security checklist. This should include common vulnerabilities relevant to the technology stack, such as SQL injection, cross-site scripting, or improper error handling. They pay special attention to how user input is handled and validated.
   
   
2. Contextual Understanding. Reviewers should understand not just the code but the context in which it operates. This includes understanding user roles, data flow, and external systems interacting with the code. The reviewer understands the feature's context, including user privileges required to access this feature and how the input data is processed and stored.
   
   
3. Active Testing. The reviewer actively tests the feature for SQL injection vulnerabilities by inputting malicious SQL commands.
   
   
4. Collaborative Discussion. Code reviews should be collaborative, with team members sharing knowledge about potential security pitfalls and best practices. The reviewer discusses potential risks with the developer. They talk about input validation techniques and the importance of prepared statements for database queries.
   
   
5. Documentation and Action Items. Identified vulnerabilities are documented, and actionable items are created. The developer is tasked with modifying the code to ensure proper input validation and parameterized queries.

Some of these are difficult to implement. For instance, you can create a security checklist, but getting every reviewer always to check everything is another story. The same goes for active testing–this is easy to skip in a fast-paced, agile environment. You are putting an extra burden on your team when you ask them to perform these additional checks. This is why we built Codacy Security. 

Codacy Security is designed to provide a comprehensive suite of application security testing tools that can be incorporated into your development workflow. It addresses some common challenges in integrating security checks into code reviews, making the process more manageable and efficient.

Codacy Security's features include:

1. Static Application Security Testing (SAST): This has always been a core part of Codacy’s product and involves scanning your code for security issues. It leverages open-source linters and scanners to help find and fix issues early in the development lifecycle.
2. Infrastructure-as-Code Misconfiguration Detection: This capability prevents cloud infrastructure issues by detecting misconfigurations in your infrastructure code.
3. Secret Detection: This detects sensitive hardcoded values like passwords and tokens in your code, helping to prevent accidental exposure of sensitive data.

Integrating Codacy Security into your development process can enhance your team’s ability to identify and address security issues, making every code review a comprehensive check for quality and security.

Security as Forethought

Bad actors are looking for vulnerabilities in your code all the time. It allows them to steal users' data, implement trojans or miners, or ransom your code for crypto. If you are lax with security, you are opening your company up to these threats.

Shifting security left and implementing security tools within your code reviews as part of the core process can significantly reduce the threat level. This is why we’ve built Codacy Security and continue to build out its feature set. We want our customers to ship the highest-quality, most secure code possible while reducing the security burden on your team.

Check out our January 2024 Product Showcase to learn more about our latest security features and integrations, as well as our plans for the future of Codacy Security.