GitHub Codespaces Security Best Practices

When GitHub released Codespaces last year it was touted as their best release since GitHub Actions. If you’re using Codespaces or thinking about it, make sure you understand the security risks involved. When Codespaces is implemented without following the best practices below, your software supply chain will be at increased risk of malicious code submissions.

What is GitHub Codespaces?

Codespaces is GitHub's remote development environment platform. It provides an on-demand development environment pre-configured with GitHub repositories and dev tools so you can focus on coding your features. GitHub itself has actually migrated most of its internal development from macOS to Codespaces because they saw an opportunity to start treating their dev environments like they do their infrastructure – as a commodity they can churn. In addition, new hires are now able to go from “zero” to a functioning development environment in less time than it takes to install Slack.

If you haven’t heard of Codespaces and want to test it out for yourself, you can get a taste by pressing '.' on any repository on GitHub. This will open a web-based version of Visual Code so you can browse the repository source code and make small changes. Codespaces is an extended version of this web editor, which gives a complete development environment in which you can browse, build and run your code. (Available for organizations using GitHub Teams or GitHub Enterprise Cloud.)

But here’s the catch: like most new and innovative capabilities, GitHub Codespaces becomes another source of critical security risks if handled or setup incorrectly. In this blog, we'll provide you with four best practices to keep your GitHub Codespaces secure:

1. Limit Codespaces to specific users

2. Limit forwarded ports visibility

3. Don’t add Codespaces IPs to an IP allowlist

4. Monitor the audit logs

#1 – Limit Codespaces to specific users

In the user permissions settings for Codespaces, GitHub provides a few options to choose from. We recommend limiting Codespaces use to specific users. Why? Two main reasons:

Secrets security risk

Organization and repository owners can configure environment secrets that could be injected into each codespace created for that organization or repository. Any user that has permission to create a codespace can access these secrets. This creates a big security risk if a codespace user shouldn't have access to these secrets.

Billing financial risk

Codespaces charge you for both compute time and storage usage. Not limiting Codespace for the required users could lead to high, unexpected charges.

#2 – Limit Codespaces Forwarded Ports Visibility

To allow remote debugging and running of your application, GitHub allows for port-forwarding from the Codespaces machine (e.g., if you run a node server, you'll be able to access the server from your local machine).

 

A forwarded port can be configured as follows:

1. Private: only the codespace owner can access the port

2. Private to Organization: Any user in the organization can access the port

3. Public: Anyone that has the Codespace URL can access the port

We recommend using only Private or Private to Organization ports. Using publicly exposed ports creates a new attack surface that could let attackers access your SDLC assets. (Especially since code that runs inside a codespace is a work in progress and due to this probably won't include the appropriate security guardrails.)

Organization owners can create a codespace policy that restricts who can forward public ports.

#3 – Don't Add Codespaces IP To An IP Allowlist

Sometimes Codespaces environments will need access to a private network to operate. (For example, to access a private package registry or database.) Adding the codespace IP or IP Range to the private network IP allowlist might be tempting, but it is very dangerous. These IPs are shared between all GitHub Codespaces and will allow other GitHub customers to access your private network.

You should use a VPN solution to access the private network.

#4 – Monitor The Audit Logs

Codespaces activity is written to GitHub's audit logs. We recommend monitoring your audit logs for suspicious activity. Some examples of suspicious activity include:

1. A user connecting from an unrecognized location

2. Codespace allowed repository permission change

3. Suspicious Codespace creation and deletion

Holistically Reduce Your Software Supply Chain Security Risks