How should security teams implement preventive controls in CI/CD pipelines before infrastructure changes reach production?

Security teams should place policy checks inside the CI pipeline so proposed infrastructure changes are evaluated before deployment. The goal is to block non compliant or unsafe changes early, when fixes are cheaper and faster. Good preventive controls are parameterized, cloud ready, and usable by DevOps teams without deep policy coding or Terraform internals.

Why This Matters for Security Teams

preventive controls in CI/CD are about stopping unsafe infrastructure changes before they become durable risk in production. That matters because infrastructure as code can spread misconfigurations, exposed secrets, and over-permissioned access at machine speed. NHI Management Group’s research shows how often identity and secret failures begin long before an incident is visible, including the State of Non-Human Identity Security, which highlights the visibility gap that makes pre-deployment policy checks so important.

Security teams often get this wrong by placing controls after deployment, or by relying on manual review for changes that are too frequent and too complex for humans to assess consistently. A better pattern is to evaluate Terraform, Kubernetes, and policy-as-code artifacts at commit and merge time, using rules that developers can understand and repeat. That approach aligns with NIST SP 800-53 Rev. 5 Security and Privacy Controls because it supports enforceable change control, least privilege, and configuration integrity before release. In practice, many teams discover drift and privilege creep only after the pipeline has already promoted the change.

How It Works in Practice

Effective preventive control design starts by inserting policy evaluation at the points where infrastructure changes become actionable: pull requests, merge gates, and pipeline stages immediately before apply. The control should inspect the proposed state, not just the source code, so it can reason over planned IAM permissions, network exposure, secret references, encryption settings, and resource naming conventions. Current best practice is to use policy-as-code engines and reusable modules rather than hard-coded exceptions, so teams can update rules centrally without rewriting every pipeline.

A practical implementation usually includes:

• Static checks for IaC patterns such as public buckets, open security groups, and privileged service roles.
• Policy gates that evaluate the change against environment context, such as prod versus non-prod.
• Exception handling with expiry dates, owner approval, and audit logs.
• Fail-closed behaviour for high-risk controls, especially secrets exposure and identity-related permissions.

For deeper context on the attack paths these controls are meant to stop, the CI/CD pipeline exploitation case study shows how pipeline trust can be abused when guardrails are weak, while the Reviewdog GitHub Action supply chain attack illustrates why pipeline components themselves must be treated as security-relevant assets. The main goal is to make the safe path the easiest path for developers, not to bolt on a brittle approval layer.

These controls tend to break down when organisations allow unmanaged custom scripts, one-off approval bypasses, or environment-specific logic that policy engines cannot reliably evaluate.

Common Variations and Edge Cases

Tighter pipeline controls often increase friction, so organisations have to balance release speed against the risk of shipping unsafe infrastructure. That tradeoff becomes sharper in multi-cloud, multi-account, or platform-engineering environments where the same pipeline serves many teams with different blast radii.

There is no universal standard for how strict every gate should be. Current guidance suggests using the strongest preventive checks for production-bound changes, while allowing lighter-weight feedback in earlier stages so developers can iterate quickly. In edge cases such as emergency fixes, teams should use time-boxed break-glass procedures with explicit approval, scoped access, and post-change review rather than permanent bypasses. The Guide to the Secret Sprawl Challenge is a useful reminder that hidden credentials and copied configuration fragments can undermine even well-designed gates if pipeline inputs are not controlled. For identity-heavy builds, preventive controls should also reject over-privileged roles and long-lived secrets, because those defects often travel with the infrastructure change itself.

Where teams are still maturing, the safest sequencing is to start with high-signal controls on production pipelines, then expand coverage to reusable modules and shared templates as policy quality improves.

Related resources from NHI Mgmt Group

• How should teams implement code security controls in CI/CD pipelines?
• How should security teams implement asynchronous code controls in CI/CD pipelines to avoid race conditions and hidden failures?
• How should security teams implement consistent character encoding controls in CI/CD pipelines?
• How should security teams hunt for malicious logic in code repositories and CI/CD pipelines before it reaches production?