This also means that there need to be more security mechanisms in place to detect that someone is not injecting malicious code from a compromised machine or that someone has been able to steal an access token from a developer to gain access to CI/CD pipeline and steal environment variables for instance.
Some of the recent security articles show different attack methods related to development.
In addition, Microsoft has stated that they have seen an increase in an identity-based attacks by over 300% over the last years. There was also information that in the Uber attack the attacker managed to gain access to the internal Slack service as well Teen hacker behind Uber security breach announced hack in the company’s own Slack. | Mashable and many know that Slack is a platform that might contain a lot of information and secrets.
Unlike end-users, developers are both consuming and building applications which requires that they need to have various levels of access to internal systems and services to be able to test applications, and local test environments and can have the required software installed, and application libraries on a machine. I found this picture as a good description of how a developer environment should look like, essentially a workbench. Most developers I’ve spoken to want to use something familiar, and personal, and built up the way they want it to be with a lot of customization.
Securing the developer experience
Most enjoy using their own machine as their primary workbench to develop and build applications and not use VDI. Have been forced to use VDI because of security requirements since your own machine which might be a corporate device didn’t have the necessary security features in place to ensure secure access.
However, with a modern approach to secure access built upon ZTNA (Zero-Trust Network Access), we can mechanisms in place on end-user’s machines to verify the health of an endpoint before they are allowed to gain access to internal tools and services. 
There are a lot of vendors in this space that provide ZTNA-based services that can handle uses context-based access using posture from both the user’s identity and the device, meaning that it can check the health of the device before granting access.
I’ve written a blog previously about this here –> Secure Remote Access in 2022 with ZTNA | Marius Sandbu (msandbu.org) that is focused on offerings from Microsoft, Cloudflare, and Citrix. It should be noted that there are other vendors in this market
- Palo Alto
- CheckPoint
- ZScaler
While this part handles the way to do a check of their endpoints before they are allowed to access services such as Slack, Jira, GitHub, and others it is just a small part of the architecture. Now to try and put this in a broader perspective, to try and maintain a secure development environment.
1: ZTNA-based access to internal services which require identity and device posture to verify “health” and other conditions of the access. This ensures that only approved users and devices are allowed to access services such as GitHub, Slack, and Jira (as long as you have integrated those services with an IDP that supports the posture check)
2: Integrated collaboration and code tools with external CASB services, this can be used to ensure that access is not granted to external users and that you do not have any data stored there that should be protected using DLP. Also, monitor for abnormal activity such as mass downloads from the repository.
3: Having tooling also integrated with a SIEM product to monitor (for instance if a compromised machine and someone can steal a GitHub personal access token, which they are trying to abuse from an unknown location)
4: Identity integration into all SaaS services to ensure lifecycle management of access to the different services. To ensure that access to the services is only from actual active users.
5: Monitor that external services are not collecting information from Slack that they shouldn’t be collecting using CASB services.
This example architecture is showing what a developer setup could look like from a security perspective in terms of providing access and an example pipeline. How the pipeline should be built is of course fully dependent on what kind of application/service is being built.
Now in this scenario, development is being done using a local machine with an IDE. Meaning that the development environment is locally on the machine.
There are of course also other options here on how to access a workbench, another option could be
- GitHub Codespaces
- GitPod
- AWS Cloud9
These all offer a web-based IDE, which means that the developer workbench is directly available from the web browser. This however also means that you are restricted to those application libraries that work within that environment.
The good part is that with a web-based IDE is that most of these provider supports integration via custom iDP that allows us to have context checks before the developer is allowed access.
If a web-based IDE is not enough, and you require local access to internal services you can still use VDI or have a network tunnel service on your developer machines using a ZTNA approach.
Microsoft recently released a new service called Azure DevBox which provides self-service-based VDI. Meaning that developers can provision their own VDI machine based on a predefined image –> Getting started with Microsoft DevBox | Marius Sandbu (msandbu.org)
In terms of setting up remote access without a full VPN approach (per-application access), there are also numerous services that one can use.
- Cloudflare Zero-Trust
- Teleport
- Pomerium
- Hashicorp Boundary
- (In addition to others already mentioned on the list) Citrix, Microsoft, VMware, and Palo Alto
Most of these also support easy access to virtual machines in addition to providing access to internal services using TCP/UDP like in most cases where developers need just-in-time access to internal lab environments or debugging services running inside a Kubernetes cluster.
For instance, Cloudflare can run as its own Container inside a Kubernetes cluster, making access easy.