This document describes how the security team continuously reviews code within Sourcegraph. Not to be confused with our formal security review.

Introduction

We use a combination of SAST (Static Code Analysis tools) and code monitors to receive alerts when we detect certain functionalities or bug patterns. This allows us to perform incremental code reviews that scale with the growth of the application. We also aim to make this process as effortless as possible, for both the security team and the engineers. We use automated reviews so we can create awareness about best practices and common anti-patterns. This should lead to a more robust codebase and an increased level of security.

Sensitive interactions

We have defined a set of interactions that can be dangerous. Especially when a user manages to inject unsanitized data in a function call. Typical examples include interactions with:

• Operating system interfaces (e.g., filesystem, execution environment, sockets);
• External services (e.g. HTTP with user input, outgoing webhooks, gRPC);
• Cryptographic libraries (e.g. TLS, encryption or hashing of user-data).

If an attacker has (partial) control over the data that, for example, gets passed to a Golang exec call, it might lead to a command execution bug. Most of these interactions can lead to vulnerabilities as described in the OWASP top 10.

Automated reviews

Using GitHub actions we are scanning for sensitive interactions, known bug patterns or violations of our secure coding guideline. If an alert has been created it will notify the user in their PR, but send a message to the security team. Sourcegraph’s Cody then looks at the code scanning result and the PR, and provides a brief summary of the PR changes and grades the “risk factor” of the code change. It also determines a false positive rate. Depending on Cody’s output the security team will conduct a more thorough review.

Manual reviews

The security team still reviews the alerts manually as most day-to-day reviews are small and happen in merge requests. The security team can also decide to look deeper into a new or existing feature on-demand. Engineers can also request formal code reviews

When reviewing code we look for vulnerabilities such as the ones defined by the OWASP Top 10. After finding a vulnerability it gets logged as an issue. This issue then ends up in the Vulnerability Management Process.