Securing the developer environment for Zero Trust

  • Article

This article will help you, as a developer, to secure your development environment so that you can implement Zero Trust principles (verify explicitly, use least privilege access, assume breach). It features content from our Securing Enterprise DevOps Environments eBook and highlights best practices for branch security and trusting tools, extensions, and integrations.

Developer velocity relies on your ability to work how and where you want to maximize business outcomes. You want powerful, customizable machines with root or administrator access. However, developer demands can run contrary to compliance regulations and the need to audit and control private employee environment access and storage.

Unmanaged machines that connect to the organization network challenge security teams, procurement, and the governance board. The best-case scenario of providing developers with default and hardened employee environments creates disdain on both sides. When employees connect from anywhere, vulnerable Wi-Fi networks are an open door for cyberattack. Hardware theft and loss are major concerns.

Vulnerabilities extend to development environment integrations. Development tools that feature rich extensibility may have unmaintained integrations in their marketplaces. Malicious extensions can endanger developer tools and cause company-wide breaches.

In the diagram below, notice how the developer environment connects to the DevOps tools environment to affect Git branches. It widens the environment surface through connection to third-party open-source packages and application extensions. Extensions present attack vectors in dependency and extension application vulnerabilities.

Diagram illustrates developer environments and security threats as described in previous eBook and summarized in related articles linked herein.

Giving DevOps team members flexibility and control while preventing malicious attacks is a fundamental challenge for security offices. DevOps can control the developer environment with a cloud environment (see Trusted launch for Azure VMs and GitHub Enterprise Cloud Docs) and secure the developer environment with containers (see GitHub Codespaces Documentation).

In addition, developers can implement these Zero Trust measures to help secure the developer environment:

  • Configure least privilege.
  • Limit who can change and approve code with branch security.
  • Adopt only trusted tools, extensions, and integrations.

Best practices for least privilege

Developers often believe that they can catch malware, phishing, and breaches in their environments. Large developer environment threat surfaces make it unrealistic for developers to maintain omnipresent system knowledge. When an organization detects a breach after an attack compromises a developer environment that has administrator access to all systems, precious remediation time may have already passed.

To remediate potential access opportunities that cause hackers to target the software developer role, consider the following Zero Trust least privilege security best practices for apps.

  • Implement least privilege and just-in-time access for DevOps. Make sure that team members maintain only minimal access to environments for the shortest required time. Put policies in place to cover administrator access rights on main devices, DevOps tools, release pipelines, code repositories, environments, secret stores, and databases. For DevOps teams, the base requirement is a connection to the organization identity store. Use identity federation for integrating with SaaS environments to avoid duplication of identities on third party platforms and to reduce exposure risk.
  • Don't use personal access tokens for source code access. Secure practices for DevOps teams include access to SaaS-based DevOps tools, code repositories (via SSH, HTTPS, or personal access token). For SaaS-based environment access, have clear instructions for how access principles dictate who can download (clone) systems code repos and from which devices (local, cloud, and container). For example, OneDrive can block or limit unmanaged device access.
  • Standardize and synchronize GitHub Enterprise Managed User (EMU) user accounts with corporate identities. With Enterprise Managed Users, you can control the user accounts of your enterprise members through your identity provider (IdP). In your organization identity store, explicitly define GitHub usernames, emails, and display names. Users then easily identify collaborators even when they've never met face-to-face.
  • For the three ways a developer can connect to a SaaS environment (HTTPS with an identity, personal access token, connecting with SSH key), make connections with the organization identity store. With GitHub (except for GitHub EMU accounts), your identity is and always will be your public identity. Controlled access via SSO requires connection with the organization identity store.
  • Use an SSH certificate authority (CA) to provide signed SSH certificates for members to securely access resources with Git. An SSH certificate is a mechanism for one SSH key to sign another SSH key. GitHub Enterprise Cloud supports SSH certificates to give organizations more control over how members access repositories. Admins can upload their SSH CA public key and issue certificates for members to use for Git authentication. Certificates can only access repositories that belong to the organization. Admins can require members to use certificates when accessing their repositories.
  • Use a Git credential manager to harden access to your code. Tools like Visual Studio (VS) have built-in identity support. VS Code will defer to a Git credential manager.

Best practices for branch security

When hackers gain access to the code repository, they can study system security and modify code without teams noticing. To prevent unauthorized code repository access, implement a branching strategy to establish control over code changes (see example illustrated in the following diagram).

Diagram illustrates an example branching strategy that protects the main repository.

To remediate potential repository access opportunities, consider the following branch security best practices.

  • Protect branches with code reviews to give DevOps teams control over code changes and auditing advances. The branching strategy in the preceding diagram articulates a controlled flow of changes that delivers a clear chain of command and blueprint for addressing code changes. Of the different approaches for the branching strategy, one commonality is that protected branches serve as the source for new releases to production.
  • Have administrators of Git repositories control approval authorizations. The control mechanism of branching strategies is in the approval workflow. Protected branches require validations, reviews, and approvals before accepting changes. One option is to create a branch protection rule to enforce workflows. For example, require an approval review or status check pass for all pull requests merged into the protected branch. Branch policies help teams protect important branches of development. Policies enforce your team's code quality and change management standards.

Best practices for trusting tools, extensions, and integrations

Extensibility in integrated developer environments (IDE) is so productive that it's essentially a mandated feature. You rely on the ability to apply and curate extensions within the marketplace of a specific IDE to design your optimal work environment.

To remediate secure IDEs, consider the following tool, extension, and integration best practices.

  • Ensure that you only integrate tools from both trusted marketplaces and publishers. For example, the VS Code marketplace has thousands of extensions to make your life easier. However, when your teams adopt new tools or extensions, the most important aspect can be verifying a publisher's trustworthiness.
  • Set up secure practices to control extension use to limit the attack surface of developer environments. Most IDE extensions require approving certain privileges to function, often as a file with read permissions on the system to analyze code. Extensions require connections to cloud environments to function (common in metric tools). Approving extra functionalities on top of the IDE opens up organizations to more threats.
  • On developer machines, track the number and maturity of used extensions to understand the potential attack surface. Incorporate only VS Code marketplace extensions from verified publishers. When you're installing third-party application extensions with VS Code, regularly check extensions that you're running with the command line, code --list-extensions --show-versions. Have a good understanding of extensible components that you're running in your developer environment.

Next steps