Securing the developer environment in Enterprise DevOps

The developer environment is one of three threat surfaces discussed in the new eBook Securing Enterprise DevOps Environments. The developer environment includes everything a DevOps team member uses to produce code, test, and document, from the laptop to the software. As companies transition to a ubiquitous work-from-anywhere styled approach, the control of these devices suffers greatly. Often, cyber security offices lack a consistent understanding of where and how the code is secured and built. Hackers are taking advantage, with an uptick in remote connection hacks and developer identity thefts.

This chapter of the eBook recommends a series of measures to help secure the developer environment. Why are they needed? As shown in this diagram, the developer environment connects to the DevOps tools environment, as well as to 3rd party open-source packages and application extensions. These extensions present new attack vectors for hackers in dependency vulnerabilities and extension application vulnerabilities. Failing to prevent hackers from compromising these corrections can be a costly exercise, as we discover in this chapter with a description of a real-life hack that occurred in 2021.

The five recommended practices described in this chapter are as follows:

Practice 1: Control the developer environment with a cloud environment

Centralized control and templates in a cloud environment form the backbone of efficiency and central management for developer environments. For example, Sogeti’s OneShare solution is a self-service portal that allows teams to create developer machines and test environments based on predefined templates on any public cloud.

Practice 2: Secure the developer environment with containers

With container technology, developers can run their development environment in the cloud and on their device. Although a developer machine in a container can be limited, the power and usages of local and cloud compute resources make them as powerful as Virtual Machines.

Practice 3: Configure least privilege access

The large size of the developers’ environment threat surface makes it unrealistic for a developer to maintain omnipresent system knowledge. The use of least privilege and just-in-time access is not only a good practice for system administrators and end users, but also for Enterprise DevOps. It’s best that team members maintain only minimal access to environments for the shortest amount of time required.

Practice 4: Limit who can change and approve code with branch security

A worst-case scenario occurs when hackers gain access to the code repository and modify code without the teams noticing and then study how the system is secured. To prevent this, implement a branching strategy to establish control over code changes. A controlled flow of changes will deliver a clear chain of command and blueprint for addressing code changes.

Practice 5: Adopt only trusted tools, extensions, and integrations

Make sure your teams take the time to integrate only tools from both trusted marketplaces and publishers. It’s best to set up secure practices to control the extension use to limit the attack surface of developer environments.