Pre-production security covers the controls applied before software reaches runtime, including repositories, build pipelines, dependencies, and secrets. It matters because many application risks are introduced before deployment and never visible to runtime-only tooling.
Expanded Definition
Pre-production security is the set of safeguards applied while software is being written, assembled, tested, and released, before it reaches live environments. It covers source repositories, dependency management, build systems, configuration templates, and the handling of NIST Cybersecurity Framework 2.0 outcomes such as secure development and controlled change. In practice, the term is broader than code scanning alone: it includes identity controls for developers and automation accounts, secret protection in pipelines, provenance of build artefacts, and review gates that block unsafe releases. Definitions vary across vendors, but the security intent is consistent: stop vulnerabilities, malware, misconfigurations, and exposed credentials before they become part of a shipped product.
This concept is distinct from runtime security, which monitors applications after deployment, and from DevSecOps as an operating model, which describes how teams organise security work across delivery. Pre-production security is the control surface that exists before release, where a small mistake in a repository or pipeline can be replicated into every environment. The most common misapplication is treating it as a tooling problem only, which occurs when teams deploy scanners but leave developer access, pipeline permissions, and secrets management ungoverned.
Examples and Use Cases
Implementing pre-production security rigorously often introduces release friction, requiring organisations to weigh delivery speed against stronger assurance and tighter change control.
- A source control policy requires protected branches, mandatory review, and signed commits so that unauthorised changes cannot be merged into the main codebase.
- Build pipelines use short-lived credentials and secret scanning to prevent API keys, tokens, and certificates from being embedded in artefacts or logs.
- Dependency and package controls verify that third-party libraries are approved, version-pinned, and checked for known vulnerabilities before build promotion.
- Infrastructure-as-code templates are validated against security baselines so misconfigurations do not propagate into cloud environments at release time.
- Release artefacts are signed and traceable, aligning with supply chain guidance such as NIST Secure Software Development Framework expectations for provenance and integrity.
These use cases are especially important when multiple teams, CI/CD runners, and service accounts can all influence the same release path. In that situation, the security question is not only whether code is vulnerable, but whether the path from commit to deployment can be trusted end to end.
Why It Matters for Security Teams
Security teams rely on pre-production controls because many serious failures originate before runtime monitoring has anything to observe. If a secret is committed to a repository, a malicious dependency enters a build, or an automation account is over-privileged, later detection may be too late to prevent exposure. The term also matters for identity and NHI governance, because build systems, deployment bots, code signing services, and CI/CD runners are all non-human identities that must be inventoried, authenticated, and constrained.
That identity angle is where many organisations still struggle. Pre-production environments often accumulate standing access, persistent tokens, and weak approval paths that would never be tolerated in production. Aligning those controls with NIST SP 800-53 and NIST SP 800-63 helps teams translate governance into access assurance, traceability, and authentication strength. Organisations typically encounter the full impact of pre-production security only after a bad build, leaked credential, or supply chain compromise reaches users, at which point the issue becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Secure development lifecycle practices sit within protected process outcomes. |
| NIST SP 800-53 Rev 5 | SA-11 | Security testing and verification map directly to pre-release control assurance. |
| NIST SP 800-63 | IA-2 | Developer and automation authentication strength affects pre-production trust. |
| OWASP Non-Human Identity Top 10 | Covers non-human identities that commonly control CI/CD and build automation. | |
| NIST AI RMF | GOVERN | AI systems built pre-production need governance over data, models, and release controls. |
Inventory pipeline identities and replace persistent secrets with bounded, auditable credentials.
Related resources from NHI Mgmt Group
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI-generated code in production environments?
- How should security teams use LLM-based identity risk scoring in production?
- How should security teams govern authorization for production access?
