Security Within Your Development, Staging, and Production Environments

by Sarah Harvey / February 7th, 2020

When information security, data security, and cybersecurity measures aren’t followed in development, staging, and production environments, the consequences can be detrimental. We’ve seen that time and time again. Last year, a bug bounty discovered a data breach at Imperva – a leading provider of firewall services. How did it happen? An unauthorized user stole an administrative API key from a production AWS account. What was the mistake behind Uber’s 2016 data breach? Developers published code that led to hackers gaining access to developers’ privileged accounts and to Uber’s servers.

Are your developers following the security standards you’ve put into place? Are you aware of the security concerns with DevOps? Let’s discuss how to securely manage multiple environments, from development to deployment.

Development, Staging, and Production Environments

A typical development workflow has three environments: development, staging, and production. Some developers don’t view staging as an environment, but we included it here to give you a full scope of the process.

Development Environment

A development environment is on your computer. It’s the environment where you’ll conduct all your code development without touching with the actual data. In development, you can test upgrades, new features, and improvements without impacting the customer’s view. You may find bugs along the way, but that’s what this environment is meant to discover.

Ideally, the development environment is similar to the production environment, with the same operating system, tools, software libraries, and a copy of the product data. Developers will often use virtual machines or container systems like Docker to mimic the production environment, ensuring that code that works in development will also work in production. 

Typical use-cases for a development environment include:

• Building new features, extending existing features, and code refactoring.
• Running integration tests. 
• Debugging.

There are few restrictions on what developers can do in their development environment, and they are free to experiment with code until they are happy with it, at which point they will push it to the staging environment.

Staging Environment

The staging environment is a production-like environment to see how your code will perform. This is the final testing ground before the code is pushed into production. Staging environments are often used for:

• Quality assurance and performance testing.
• Vulnerability testing and risk analysis.  
• Integration testing, to ensure that the code integrates well with services and databases the app depends on. 

Staging environments also give other developers, project managers, and clients an opportunity to examine software before it goes live. 

Because extensive testing takes place in the staging environment, it’s important that it is as similar to production as possible, including both the software and hardware. While it’s fine to host a development environment on a laptop, the staging environment should be on a server with the same hardware it will run on in production. 

Production Environment

In a production environment, systems go live and your developed code is released to end-users. You deploy completed code that has endured proper vulnerability testing and risk analysis. All of the testing is complete and there’s the expectation that you’ll find only minor bugs, if any. Once it’s released, you’re relying on it as a profit source, so you want to make sure it’s secure

In theory, major bugs and software vulnerabilities should have been discovered before the code goes to production, but that’s rarely the case for complex software systems. It is likely that at least some bugs made it through testing, so organizations must design and  implement network and data security systems that assume the existence of vulnerabilities. 

Importance of Security Throughout Dev, Staging, and Production

With multiple environments comes the difficulty of securely managing them. Best practice is to separate your development, staging, and production environments. This allows each to evolve at its own pace – maybe the development environment is testing out features that won’t be available in production for at least a year – and reduces the risk of cross contamination. Any bugs discovered in staging, for example, will be contained within that environment and not spread any further. Most importantly, keeping your development, staging, and production environment separate will help protect data.

In audits or penetration testing, we see many organizations failing to test their test all of their environments, but there could be a vulnerability in the test environment that compromises the production environment. It’s problematic to avoid testing all environments.

Security Concerns in DevOps

For organizations that use the DevOps approach, security is an even greater concern. It’s face-based, there’s more overlap, there’s automation – there are many reasons to implement and verify security processes in DevOps.

To preserve high-level compliance practices within your development, staging, and production environments, you can implement configuration management techniques, monitoring and logging processes, and even integrate infrastructure as code or policy as code. You can set yourself up for success by performing regular code review during the development process, making changes proactively to all environments, confirming that you have limited access to the proper channels, or even engage in continuous penetration testing to ensure no vulnerability is overlooked. These practices will ensure you’re doing your due diligence to securely manage your various environments.

If you’re interested in advanced penetration testing services that will locate your vulnerabilities and help you avoid harmful gaps in your code, KirkpatrickPrice can help! Contact us to learn more.

More DevOps Security Resources

Think Like a Hacker: How Could Your Mobile Apps Be Compromised?

Best Practices for Configuring Your AWS Perimeter

PCI Requirement 6.5 – Address Common Coding Vulnerabilities in Software-Development Processes