Susan’s post — est. reading time: 11 min

In most organisations, security investment and attention are squarely aimed at production environments. This makes intuitive sense—production systems hold customer data, run core business processes, and are the most visible targets in the event of a breach. But this laser focus can leave critical blind spots elsewhere in the software delivery pipeline. Environments like staging, testing, and quality assurance (QA) are often treated as low-risk, low-priority, or temporary. In reality, they are soft targets—and attackers know it.

These non-production environments often replicate production configurations. They may include real data or access live APIs. They are frequently shared between developers, loosely governed, and left outside the scope of standard compliance checks. Yet they serve as on-ramps to production environments. The security gaps found here are not theoretical—they are operational liabilities waiting to be exploited.

A Breach in the Shadows: A Case in Point

A global manufacturing company recently faced this reality during a scheduled internal audit. The audit revealed that its QA environment housed an unencrypted copy of the customer database. There were no access controls, no audit logs, and no enforcement of multi-factor authentication. The environment had been temporarily exposed to the internet to facilitate third-party testing—and never properly secured.

The board’s response was swift: how did this happen, and why was production-level data sitting in an unprotected sandbox? The truth was simple but sobering. A shortcut had been taken for the sake of speed, and no one had reassessed the risk. Though the incident was caught early, the lesson was clear. Neglecting non-production environments is not just a security oversight—it is a strategic misstep.

Common Vulnerabilities in Non-Production Environments

These environments tend to be informal by nature. They’re used for experimentation, debugging, and validation. But informality often leads to inattention. Consider the following risks:

• Cloned production data used for testing without proper anonymisation or masking
• Shared service accounts with persistent credentials used across dev, test, and prod environments
• Relaxed network rules to allow faster testing—rules that are never tightened again
• Untracked secrets stored in plaintext within scripts, containers, or version control systems
• Limited visibility into access logs, monitoring, or audit trails in these ephemeral setups

Each of these vulnerabilities creates opportunity for lateral movement. Once an attacker finds a foothold in a less secure environment, they can quietly pivot to more sensitive systems. These weaknesses also expose organisations to regulatory and reputational risk—even if the breach occurs outside of production.

Security Must Be Lifecycle-Wide

Security should not be conditional. It must be applied consistently across every environment in the software lifecycle. The notion that “non-production is low risk” is a fallacy. The more accurate framing is that non-production is low visibility. For this reason, organisations must adopt a lifecycle-wide DevSecOps strategy—one that includes proactive controls for development, staging, testing, and QA.

This means treating every environment as production in terms of:

• Secrets management – using vault-based systems to manage credentials and tokens securely
• Identity and access controls – enforcing least privilege across all roles and stages
• Data handling policies – applying masking, encryption, and access logging to all data, even test copies
• Policy enforcement – running vulnerability scans, compliance checks, and configuration audits before anything goes live

These controls are not about bureaucracy. They’re about resilience. If an environment can be breached, it must be secured. That includes the temporary, the internal, and the assumed-to-be-safe.

Changing the Culture of “It’s Just Testing”

One of the biggest barriers to securing non-production environments is mindset. Many developers view these spaces as safe zones—places to move fast, break things, and clean up later. Security is seen as an obstacle to that flexibility. This thinking must change.

Security teams need to work closely with engineering to strike a balance between velocity and control. Automation is key. By embedding scanning tools, policy-as-code frameworks, and secrets management into CI/CD workflows, teams can apply consistent guardrails without slowing development.

The Executive Mandate: Treat Every Environment Like Production

For executives and business leaders, the call to action is clear: if an environment holds real data, touches production systems, or is exposed to the internet, it must be secured as if it were production. The cost of ignoring this reality is measured in data loss, downtime, and loss of customer trust.

Leadership must sponsor continuous security practices that span the entire delivery pipeline. This includes investing in monitoring tools that track activity in all environments, enforcing encryption and IAM policies by default, and requiring non-production environments to meet the same standards as production.

Conclusion: Security Is Not a Stage, It’s a Standard

Modern software delivery moves too fast to treat security as a final checkpoint. In DevSecOps, security must be ever-present—from the first commit to the last deployment. That includes the overlooked, the temporary, and the assumed-to-be-unimportant.

By securing non-production environments with the same rigour as production, organisations reduce risk, eliminate blind spots, and ensure that their agility does not come at the cost of safety.

Because in the eyes of an attacker, there is no such thing as “just testing.”