Treat Your Development Environments (almost) Like Production

The stakes are higher than you think!

Edoardo Nosotti
Aug 24, 2020 · 3 min read
Photo by Kobby Mendez on Unsplash

I recently came across a tweet sharing a very strong opinion about the separation of “cloud” accounts to isolate environments. The subject has been highly debated over the years and while there is no “one size fits all” solution, there is a widespread consensus on the advantages of separated accounts. It often makes security and cost control easier to deal with and these are sound reasons to opt for the multiple accounts solution. The worst of them all, instead, is: “so I can hand the dev account over to the development team”.

I am a developer myself and worked several “developer” jobs before taking the path of the cloud. I still write a lot of code. So I am not here to bash developers like a cranky old sysadmin. Yet, I think there are some considerations worth making and sharing about this.

Application security is not network security or systems security. Your most experienced developers might have a very good understanding of all of those, but don’t take it for granted. Also, if you are working in a medium or big sized company, chances are that you don’t only have seniores* aboard. If you are wondering why this matters to development environments, keep reading.

* “senior” is a Latin word, so please allow me to use its correct plural form ;)

Yes, you don’t have real users or customers on dev, so who cares if it breaks from time to time? Well, any malicious competitor or hacker might very well care about the code and the configurations you put into your development environment. Information about your software products and services (especially the upcoming ones) might be worth a lot on the corporate espionage market, or be used to learn how to target your production systems. Ensure your development environments are secured, too. Don’t leave “soft targets” around.

One thing I love about modern cloud platforms is the quick prototyping opportunities they offer. It’s really helpful in the design process. Keeping up with change requests from your developers while they try new things and test them might be highly demanding at times, but it also gives you the chance to promptly address any concern you might have about the security design or operating costs of the whole solution. Stepping early into the design and development process and becoming an active part of it might save everybody’s time and a few headaches later on.

The data used for application development and testing purpose should always be fake data, randomly generated for the purpose, but that is not always the case. Especially when people need to test systems under their most realistic working conditions, they might copy data from production environments to the test environments. Such data MUST, of course, get anonymized in the process, but a significant number of data leaks occurred and even big companies that are supposed to enforce strict security practices were involved. Also, people might inadvertently post confidential company files to a development system to test its functionality. So taking good care of the development and test environments can act as a “failsafe” to prevent such incidents.


Tutorials, tips and fast news on Cloud, DevOps and Code

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store