Afraid of your source code leaking? I can tell by the Twitch in your eye…!

Nir Valtman
CEO & Co-Founder
January 10, 2022
Nir is an experienced information & application security leader, most recently as VP security at Finastra and CISO at Kabbage. Nir is a frequent public speaker at leading conferences globally, including Black Hat, Defcon, BSides, and RSA.


In a recent attack, Twitch had 6,000 internal git repositories and 3,000,000 documents – containing 6,600 secrets and over 150 API keys across services like Twilio, Google, and Stripe – exposed on 4chan. This leak represents yet another instance of a recurring problem — excessive permissions to Source Code Management. In this post we discuss the best practices to avoid source code leaks.


Introduction: Excessive access to source code is a serious concern

The publication about the Twitch source code leak represents yet another instance of a repetitive problem — excessive permissions to Source Code Management. Code exfiltration is easy to exploit, but what are the reasons for it?

Default Access to Source Code

Source Code Management tools are designed to enable collaboration with minimal impact on development velocity. For example, when a user is invited to collaborate on GitHub, there are generally 2 access levels:

  1. Owner: full administrative rights to the organization and have complete access to all repositories and teams.
  2. Member: can see all other members, and can be granted access to repositories. A member can also create new teams and repositories.

In addition to these levels, there is an option to add membership in specific teams, which have more specific permissions. Below is an illustration of a user invitation to an organization with specific group membership.

By looking into this group membership, it can be determined what is the additional permission beyond the default access granted to members:

Permission management appears to be simple, but the challenge is that
permissions are derived from the most common denominator — having a READ access permission to all repositories. Below is a screenshot representing this default setting.

Common causes of source code exploitation

From adversarial perspective, an access to source code can be exploited by any of the following:

1. Leverage the git client on the developer’s workstation

Given access to a developer workstation, especially in the post COVID world with developers working from home in a less secure environment, it is simple to exploit as the access token already stored in the Git Credential Storage, which “serves” the token to the git client.

2. Leverage the browser’s context

In many cases, project and product management tasks are managed in the Version Control tool. It means that additional roles beyond developers typically have access to source code, such as project managers, which don’t use a git client. An adversary with a malware accessing the browser context can download the zip file containing the archive of the source code. It is harder to exploit but has much broader outreach.

3. Get an access token

Any access to private source code requires an access token or SSH key, regardless the source of the request. For example, a build system uses a short-lived token to clone repositories, a developer may use a long-lived token on the git client, and the project manager has a cookie with the token. There are many ways to get the access to these type of tokens, for example:

Best practices for minimizing source code risk

  1. Modify the base permissions in your Source Control Management to be less permissive or manage micro-organizations within the enterprise.
  2. Use SSH keys with a passphrase to authenticate into the Source Control Management tool. Worth knowing that if the user stores the passphrase in the built-in key storage (such as keychain), it beats the purpose.
  3. User entitlements review is common practice for regulated companies. The challenge is that these reviews tend to be rubber stamped by the employee managers or repository owners. To minimize the risk, measure the user entitlements over time and expect to see a trend of decreasing user entitlements from time to time.
  4. Educate yourself about how permissions are constructed by playing with them in a sandbox. For this purpose, we created GitGoat, which is an open source tool that was built to enable DevOps and Engineering teams the opportunity to design and implement a sustainable misconfiguration prevention strategy. It can be used to test products (such as OpenSSF) with access to GitHub repositories without risking your production environment.


More from our blog

Malicious Code Campaign on GitHub Repos: Is it Hype or a Dire Threat?
Malicious Code Campaign on GitHub Repos: Is it Hype or a Dire Threat?
March 25, 2024
Need for AppSec exposed by the ‘ResumeLooters’ SQL Injection & XSS Attacks
Need for AppSec exposed by the ‘ResumeLooters’ SQL Injection & XSS Attacks
March 25, 2024
How to ensure you don’t have Sourcegraph secrets in source code
How to ensure you don’t have Sourcegraph secrets in source code
March 25, 2024