Should organisations prioritise runtime detection or pre-production controls first?

Why This Matters for Security Teams

The question is really about where to intercept risk most efficiently. Pre-production controls reduce the chance that insecure code, misconfigured infrastructure, or exposed secrets ever reach production, while runtime detection limits blast radius when something slips through. Current guidance from the NIST Cybersecurity Framework 2.0 supports balancing preventive and detective safeguards across the full security lifecycle, but teams often overinvest in alerting before establishing basic release hygiene.

That imbalance matters because runtime tooling can only see what is already executing. If secrets are embedded in a repository, a dependency is vulnerable, or a build pipeline is permissive, detection may surface the issue only after deployment or compromise. For security teams, the practical issue is not whether detection is valuable. It is whether the organisation can reliably stop known-bad changes before they become operational exposure. In practice, many security teams encounter weaknesses in runtime monitoring only after a noisy alert has been ignored or a compromised deployment has already been promoted.

How It Works in Practice

The most effective sequence is to use pre-production controls as the primary filter and runtime detection as the secondary containment layer. That usually means building guardrails into source control, CI/CD, and release approval paths before investing heavily in live telemetry. For example, secrets scanning should block commits or builds that include credentials, dependency analysis should flag known-vulnerable packages, and policy-as-code should prevent insecure infrastructure changes from being deployed.

Runtime detection still has an important role. It identifies abuse that prevention cannot always stop, such as stolen credentials, malicious insiders, or zero-day exploitation. But its value depends on the quality of the preventive baseline. If the build and release process is weak, the volume of runtime noise grows faster than the security team can investigate. NIST guidance on application security and secure software development reinforces the need to embed controls early in the lifecycle, not bolt them on after deployment.

• Use secrets detection, dependency checks, and IaC policy gates to stop obvious issues before release.
• Connect CI/CD controls to approval workflows so high-risk changes require review.
• Deploy runtime detection for credential misuse, anomalous process behaviour, and suspicious API activity.
• Feed runtime findings back into pre-production rules so the same issue is blocked earlier next time.

This sequencing also aligns well with identity and privilege governance. If service accounts, API keys, and automation tokens are treated as non-human identities with defined ownership and lifecycle controls, pre-production checks can validate whether those identities are over-privileged or improperly embedded. These controls tend to break down when deployments are fully manual, infrastructure is highly ephemeral, or shadow pipelines bypass the approved release path because preventive gates no longer cover the actual route to production.

Common Variations and Edge Cases

Tighter pre-production control often increases release friction, requiring organisations to balance delivery speed against assurance. That tradeoff becomes more visible in high-velocity engineering environments, where product teams may resist blocked builds or lengthy approvals. Best practice is evolving toward risk-based gating, where low-risk changes move quickly but changes affecting secrets, identity, or production access face stronger checks.

There are edge cases where runtime detection deserves earlier investment. In environments with mature automation but poor observability, detection may be the fastest way to gain visibility into active compromise. The same is true for regulated or high-impact systems where continuous monitoring is mandatory and failure containment matters as much as prevention. Still, that should not be mistaken for a replacement for pre-production controls. CISA secure software development guidance and the broader secure development lifecycle make the case for preventative assurance as the default.

Where agentic AI or automated tooling is involved, the same logic applies with extra care. Autonomous systems that can call tools, access secrets, or trigger deployments need stronger pre-production validation because runtime detection may only reveal misuse after an action has already executed. There is no universal standard for the exact split between prevention and detection, but the more a system can change state or access credentials, the more the balance should shift toward pre-release controls.

Related resources from NHI Mgmt Group

• Should organisations prioritise token rotation or behavioural detection first?
• Should organisations prioritise secrets rotation or policy controls first for agents?
• Should organisations prioritise static testing or runtime testing first?
• When should organisations prioritise runtime guardrails over model-focused AI controls?