Beyond Production: Why Securing Dev and QA Environments Matters

In secure software development, development teams usually write and test their code in dedicated environments before it goes live for customers. These are called the development (dev) and quality assurance (QA) environments. The dev environment is where engineers build and test their own parts of the software or application. It’s set up with all the tools, packages and mock data they need, and engineers often start with a branch or snapshot of the latest code from the production. Once the code is ready, it moves to the QA environment, where automated tests run to check if everything works as expected.

Most people know it’s important to protect the production system, but they often forget about dev and QA environments. If these environments are left open to the internet, attackers can use them to find vulnerabilities that are not even introduced in production yet. That’s why it’s just as important to secure dev and QA environments as it is to protect production. Treating them with the same level of security helps keep your whole organization safe.

Why Securing Dev and QA Environments Is Business Critical

Before we discuss why securing development environments is critical, let’s examine the current landscape:

• The State of API Exposure 2024 report found nearly 3,945 development APIs publicly accessible across major organizations, with 198 highly critical vulnerabilities directly related to these exposures. Many of these APIs lacked proper security controls, exposing sensitive information and providing easy entry points for attackers.
• According to Black Duck’s 2024 snapshot, information leakage and predictable resource locations are among the most common vulnerability classes, affecting 66% and 35% of organizations respectively. These issues frequently stem from exposed development environments, where sensitive data and endpoints are inadvertently left accessible.
• In December 2024, Cisco confirmed that attackers accessed and exfiltrated data from its public-facing DevHub environment. The breach involved leaked source code, credentials, and confidential documents, all due to a misconfigured environment that was accessible from the internet without proper authentication or authorization controls.

These incidents highlight a systemic problem which is publicly exposed Dev and QA environments are a prime target for attackers. When these environments are accessible over the internet, they act as an open invitation for threat actors to probe, enumerate, and exploit vulnerabilities that would otherwise remain internal.

You might wonder why attackers are so interested in dev and QA environments. Here’s a closer look at the reasons:

• Constant Change and Lower Security: Dev and QA environments are where new code is written, integrated, and tested daily. Unlike production, these environments often lack rigorous security controls, as the focus is on rapid development and testing rather than security hardening.
• Incomplete Security Coverage: Security teams may not continuously monitor or test these environments, leading to unpatched vulnerabilities, misconfigurations, and exposed secrets (like API keys and credentials).
• Shadow APIs and Unmanaged Assets: The rapid pace of development can lead to “shadow APIs” endpoints that are undocumented, unmanaged, or forgotten. These APIs often bypass security reviews and are left exposed, increasing the attack surface.
• Weak Authentication: Development APIs and services may use weak or default authentication, or none at all, making it trivial for attackers to gain access.
• Risky Dependencies: Developers may install third-party libraries or packages that contain known vulnerabilities, further weakening the environment’s security posture.

Once attackers discover an exposed Dev or QA environment, they can:

• Enumerate APIs and endpoints to find vulnerabilities.
• Extract sensitive data, credentials, and source code.
• Use the environment as a foothold for lateral movement into more sensitive systems.
• Exploit misconfigurations and unpatched software to escalate their access.

Best Practices for Protecting Dev and QA Environments

While there are many ways to improve security, every Dev and QA environment should meet these basic requirements set by a security architect:

1. Keep Dev and QA Environments Internal

• Dev and QA environments should not be exposed to the public internet. Some people worry that moving these environments behind internal networks or VPNs will hurt productivity, but this step is crucial for security. Exposing these environments makes it much easier for attackers to find and exploit vulnerabilities before they are fixed. The biggest lesson from past breaches is simple: always keep Dev and QA environments internal.
• If certain APIs need internet access (for example, A Vendor API), only expose those specific endpoints. Use a Web Application Firewall (WAF) to restrict access by IP address and allow only the necessary paths. This targeted approach protects your environment while still enabling essential connectivity.

2. Scan for Vulnerabilities from the Start

A common problem is when developers install vulnerable packages in their virtual environments and then push this code to GitHub or another source code repository. To prevent this:

• Set up vulnerability scanning in your CI/CD pipeline or source control system to block commits or deployments that contain known vulnerable packages.
• Use automated tools or built-in security features in GitHub to scan dependencies.
• While EDR solutions can help detect malware, dedicated dependency scanning tools are better suited for catching vulnerable packages early.

3. Enforce Automated Code Review Before Deployment

Only allow code to be deployed after all issues flagged by automated code review tools (such as SonarQube, CodeRabbit, or Codacy) have been addressed and fixed. This ensures that code quality and security standards are met before anything reaches the Dev or QA environment.

4. Additional Best Practices

• Network Segmentation: Isolate Dev and QA environments from production and from each other to reduce the risk of lateral movement if one is compromised.
• Datas
• Regular Updates and Patching: Keep all software, dependencies, and operating systems up to date in Dev and QA environments.
• Audit and Monitor: Continuously monitor these environments for suspicious activity and regularly review access logs.
• Always use mock or anonymized data in Dev and QA environments to protect sensitive information. This minimizes the risk of data leaks if these environments are exposed or compromised.
• Secure Secrets Management: Never hard-code secrets or credentials in code. Use secure vaults or environment variables managed by trusted tools.

About the Author

Ranjan Kathuria has over nine years of experience in the security industry, where he has played a key role in building security programs and mentoring security engineers. Currently, he serves as a Cloud Security Architect at Rubrik Inc, where he focuses on safeguarding the cloud environment. Additionally, he is recognized as a top-tier security researcher for HubSpot and Quora’s Bug Bounty Programs on Bugcrowd, contributing to the enhancement of security measures on these platforms.