How to have security and usability with your development environments in regulated industries

Reading “There is sometimes a perceived conflict between security and usability”, in the context of development environments, has led me to writing this blog post. Let me tell you why.

Development environments are the frontier of cybersecurity for software companies. A single misconfiguration or lax security updates can leak CI/CD and production secrets, introduce backdoors in your code (looking at you, xz!) or worse: impact your customers, leading to a SolarWinds situation.

No one wants that, but how do we secure our environments without creating obstacles for software engineering teams? Rapid development is crucial for many companies, making efficiency non-negotiable. Yet, especially among companies in regulated industries, they are forced to choose security over usability. Can you get both? Let’s explore.

Where to start with security?

We are seemingly on a mission impossible here, security AND usability? No way! Let’s first answer how to get our environments secured and come back to usability after. Luckily, many have been on this path before us so we can cherry pick frameworks, checklists and guides to our liking. Here are a few to consider:

• The UK National Cyber Security Center offers a comprehensive guide with actionable items – a great place to get you started.
• The OWASP Devsecops Maturity Model measures the maturity of your current processes by assessing key aspects of your program, ranging from Level 1 (lowest) to Level 5 (highest). This can help you to quickly identify what’s lacking.
• Need something more rigorous? NIST’s Special Publication (SP) 800-218 provides the Secure Software Development Framework (SSDF), outlining around 40 desirable outcomes.

Significantly reducing your attack surface

My head is spinning after reading all of that, what’s the summary here? What are the most important controls to mitigate the biggest risk factors? While there are no silver bullets the most important step to take is reducing the available attack surface. Here are some easy controls to get started with:

• Version, review and approve all changes to code: This control is fundamental. There are a variety of source code repositories allowing you to track, review and approve changes to your software. Define code ownership and require an additional pair of eyes to gatekeep adjustments.
• Separated environments: Testing software in production is a bad idea. Restrict access to production environments and implement quality gates to ensure releases are tested before deployment.
• Keeping your development environments up-to-date: Software ages like milk. Use Software Composition Analysis (SCA) to assess dependencies, but don’t underestimate alert fatigue. Prioritize vulnerabilities based on exploitability and attack surface.
• Secure secrets storage: Never hard-code secrets. Use secret managers to secure access and provide a central place to rotate secrets if compromised.
• Standardized environments: If the menu of a restaurant is 20 pages long I assure you the dishes won’t be amazing. Turns out security is no different. Simplify to reduce errors. Standardized environments allow central security applications. Looking at the xz backdoor earlier this year, it’s more crucial than ever to have dev environments operate securely.
• Educate staff on common vulnerabilities: There are several trainings on how to write code securely. This can range from in-house sessions to online content available on-demand, such as the Secure Software Development Course (https://training.linuxfoundation.org/training/developing-secure-software-lfd121/) (by OpenSSF (https://openssf.org/) and The Linux Foundation (https://www.linuxfoundation.org/)). The most basic aspects you want to cover include OWASP Top 10 (https://owasp.org/www-project-top-ten/) and SANS Top 25 (https://www.sans.org/top25-software-errors/).

How does usability come into play? (https://www.gitpod.io/blog/security-and-usability-with-your-development-environments#how-does-usability-come-into-play)

Now, we’ve got a set of controls we’d like to implement. How do we do this effectively while striking the balance between security and usability? Let’s look into our options.

Local environments: provide usability, remove security (https://www.gitpod.io/blog/security-and-usability-with-your-development-environments#local-environments-provide-usability-remove-security)

To developers, this might provide the greatest perceived benefit in terms of usability since they set up and maintain their environments on their own. However, having everyone individually responsible is an error-prone process and a large sprawl of secrets and code across several devices. Had a typo when installing a dependency? Too bad, your code can get exfiltrated now and you’ve invited some guests into production!

VDIs: provide security, remove usability (https://www.gitpod.io/blog/security-and-usability-with-your-development-environments#vdis-provide-security-remove-usability)

Virtual Desktop Infrastructure (VDI) is a form of virtualization that enables remote access to a full desktop environment. In the event of a security event, admins can reset the entire desktop to its default settings. Admins can also apply security updates from a central place. However, VDIs were not built as secure options for development environments, they were built as remote access to an entire desktop, making them a nightmare to develop with (https://www.gitpod.io/blog/writing-software-with-chopsticks-an-intro-to-vdi).

Cloud development environments: provide security and usability (https://www.gitpod.io/blog/security-and-usability-with-your-development-environments#cloud-development-environments-provide-security-and-usability)

Local environments are insecure and VDIs are bad for usability. Cloud Development Environments or CDE in short can be the best of both worlds.

Within cloud development environments, there are a few types of deployment models. Each model comes with distinct pros and cons, all related to security and usability.

• Self-hosted and self-managed: self-hosted in your organization’s cloud infrastructure, operationally managed by your team – this can include homegrown solutions or infrastructure orchestrators like Coder (https://www.gitpod.io/blog/gitpod-vs-coder).
• Self-hosted and vendor-managed: self-hosted in your organization’s cloud infrastructure, operationally managed by a vendor – Gitpod.
• Vendor-hosted, vendor-managed: hosted in a vendor’s cloud infrastructure, as well as operationally managed by the vendor – SaaS offerings like GitHub Codespaces.

Self-hosted and self-managed CDEs require security and infrastructure experts to implement the right solution. If your organization is resourced with both, and wants to dedicate a team to maintaining the CDE, then this is an option. To learn more about self-hosting and self-managing CDEs, read here. (https://www.gitpod.io/blog/self-hosted-not-self-managed)

Vendor-hosted and vendor-managed CDEs are mentioned because they are a type of CDE, but we would not recommend them for security-conscious organizations. They do not enable you to self-host the CDE which is often a deal-break in regulated industries.

Finally, self-hosted and vendor-managed CDEs like Gitpod are self-hosted in your organization’s cloud infrastructure, and operationally managed by Gitpod. This removes the need for in-house security and infrastructure experts. It also provides all security requirements for regulated industries available out of the box. The best part is? They are also purpose-built to be used as development environments, so usability is not compromised.

Interested in learning more about Gitpod and how to improve your security posture? We are happy to chat! Reach out to our team here.