May 19, 2022

How do you give DevOps team members flexibility and control, without opening the door to malicious attacks? This is the fundamental challenge for many security offices today and is discussed in a new eBook published by Sogeti and Microsoft as part of the Modern App Development and Enterprise DevOps series.

2022 DevOps blog 1 Picture1.png

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.

Clemens Reijnen

Clemens Reijnen

Global CTO of Cloud Services

Read the eBook

The above is just a brief summary of the recommended practices. The eBook covers them in much more detail and offers advice on how to set about achieving them in order for your Enterprise DevOps teams to secure the developer environment.