Pre-production risk is exposure introduced before software reaches production, including source code flaws, dependency weaknesses, secrets, and pipeline misconfigurations. It matters because fixing issues earlier is usually cheaper and more reliable than remediating them after deployment.
What Pre-production Risk Means
Pre-production risk is the exposure created before software reaches production, when flaws in code, dependencies, secrets, build logic, and deployment configuration can still be introduced, detected, and corrected.
Why Pre-production Risk Matters
This risk exists because earlier stages often have weaker separation of duties, faster change rates, and more experimental tooling than production. That combination can let defects accumulate quietly in source control, build systems, test environments, or release pipelines until they become harder and costlier to fix.
Pre-production risk is especially important when teams treat non-production as inherently safe. A compromised build step, an embedded secret, or a bad dependency can move downstream into production with high trust if it is not caught before release.
Common Sources of Pre-production Risk
The most common sources are insecure code, vulnerable open-source dependencies, hardcoded or leaked secrets, misconfigured CI/CD pipelines, and weak environment isolation. Each of these can create a different failure mode, but they often reinforce one another when the same controls are reused across development, testing, and deployment.
Dependency risk is often underestimated because it sits outside the application’s own codebase. A package, container image, or build plugin can introduce a flaw even when the primary application appears clean.
Secrets risk is also central in pre-production because build logs, repository history, and shared test systems can expose credentials long before release. OWASP Non-Human Identity Top 10 is relevant here because secret sprawl, overprivilege, and poor rotation often show up first in delivery pipelines and automation.
How Organisations Reduce Pre-production Risk
Teams reduce pre-production risk by shifting validation left, making security checks part of the normal delivery path, and treating build and release systems as sensitive assets. That usually means testing code and dependencies early, scanning for secrets, enforcing environment separation, and hardening the pipeline itself.
Release integrity improves when delivery controls are explicit rather than assumed. SLSA is a useful reference for build provenance and artifact integrity, while OWASP SAMM helps teams build security into the software delivery process rather than bolting it on later.
NIST SP 800-53 Rev 5 Security and Privacy Controls is also relevant because configuration management, access control, system integrity, and auditability all affect whether pre-production issues are detected before release.
Risk and Threat Considerations
Pre-production risk is attractive because it offers a path to production impact before formal defenses are in place. If an attacker can tamper with source, dependencies, build jobs, or release scripts, they may be able to seed a compromise that looks legitimate by the time it reaches deployment.
Failure mechanism: Weak pipeline controls let unsafe code, compromised packages, leaked secrets, or altered build outputs progress from development into trusted release artifacts.
Impact: The result can be widespread compromise, persistent backdoors, credential exposure, or a repeatable path for malicious code to enter production at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP SAMM and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Pre-production risk includes build and artifact integrity failures. |
| Recommendation — Adopt SLSA practices to verify build provenance and protect release artifacts. | ||
| OWASP SAMM | Software Assurance Maturity Model | Pre-production risk is reduced by embedding security into software delivery. |
| Recommendation — Use SAMM to mature security checks across the development lifecycle. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Pipeline and environment misconfiguration are core pre-production risks. |
| AC-6 — Least Privilege | Pre-production systems often fail when build and release access is too broad. | |
| SI-7 — Software, Firmware, and Information Integrity | Early validation of code and dependencies addresses integrity risk before production. | |
| Recommendation — Establish approved baselines for build and test environments. Restrict pipeline and repository access to the minimum required. Validate software and dependencies before release to detect tampering. | ||
Practitioner Guidance
What to watch for: Repeated manual exceptions, shared credentials in delivery tooling, unreviewed dependency updates, and pipeline steps that are difficult to audit are all signs that pre-production risk is not being controlled well. The most useful question is not whether a defect exists, but whether the process would reliably catch it before release.
Governance implication: Ownership of pre-production risk should sit with the teams that control code, build, and release paths, not only with production operations. If those controls are fragmented, risk accumulates in the handoffs between development, security, and platform engineering.
Related resources from NHI Mgmt Group
- Why do pre-deployment tests fail to manage production AI risk?
- Why do agentic AI systems create more governance risk when pre-production testing and production monitoring are disconnected?
- How should security teams correlate pre-production application findings with cloud risk in one workflow?
- How should security teams limit the risk from AI agents that have access to production systems?