How should security teams embed security checks into Infrastructure as Code workflows before deployment?

Why Pre-Deployment IaC Checks Matter

Infrastructure as Code shifts security from manual review after deployment to repeatable control before cloud resources exist. That matters because IaC usually defines network exposure, encryption settings, logging, service roles, and access paths in the same files developers use to ship change. If those files are not checked early, insecure defaults can become infrastructure quickly and consistently, which makes them harder to unwind later.

Pre-deployment scanning also turns configuration drift into a pipeline problem instead of a production problem. A good control path should catch risky changes while they are still diffable, attributable, and easy to block or amend. For teams that need a practical reference point on how secret sprawl and hardcoded credentials show up in delivery pipelines, Guide to the Secret Sprawl Challenge is a useful companion. In practice, many teams discover the issue only when an exposed template has already created real infrastructure.

Using one statistic from the supplied source, 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which is exactly why IaC checks need to cover templates, variables, and pipeline-adjacent files together.

How It Works in Practice

A workable IaC security workflow usually combines static analysis, policy enforcement, and change gating. Static analysis should inspect Terraform, CloudFormation, Kubernetes manifests, Helm charts, and similar artefacts for misconfigurations before merge or deployment. Policy-as-code then applies organisation rules for encryption, public exposure, tagging, logging, and approved regions so the pipeline can reject unsafe changes consistently rather than depending on reviewer memory.

The strongest teams treat the pipeline as the enforcement point, not just the detection point. That means a finding should either block deployment, route for explicit exception handling, or fail into a remediation path that is visible to the change owner. Review gates are most effective when they are precise enough to explain the issue, but not so noisy that engineers bypass them. A recurring pattern is to check for:

• open security groups and overly broad network access
• public storage or permissive bucket settings
• unencrypted data services and missing key management controls
• overprivileged roles, policies, and access bindings
• hardcoded secrets, tokens, or credentials in templates

Repeatable rollback also matters because pre-deployment controls are not perfect. If a bad change slips through a branch, rollback should restore the last known safe state without requiring ad hoc manual repair. For a real-world example of how exposed pipeline artefacts can be abused, GitHub Action tj-actions Supply Chain Attack shows why pipeline integrity and secret hygiene belong in the same control conversation. These controls tend to break down when teams allow direct deployment paths that bypass code review, because the pipeline can no longer act as a reliable enforcement boundary.

Common Variations and Edge Cases

Tighter IaC control often increases delivery overhead, so teams have to balance speed against how much risk they are willing to accept in non-production and production environments. Not every finding should be treated the same way. A public test sandbox may justify different network exposure than a production payment service, but the decision should be explicit and recorded rather than left to whoever approved the last merge.

Some environments also make pre-deployment checks harder to operationalise. Generated templates, multi-account landing zones, and shared modules can hide the true blast radius of a single change, so scanning only the top-level file is often too shallow. Current guidance suggests checking rendered or compiled artefacts as well as source templates when the deployment tool materially changes the final infrastructure shape.

Another edge case is compensating control reliance. If a platform assumes every risky setting will be fixed later by cloud guardrails, the IaC workflow stops being a prevention mechanism and becomes a notification system. That is acceptable only when the compensating control is reliable, measured, and enforced at the same boundary. Otherwise, the safest interpretation is that the pipeline should stop the change before it reaches deployment. The hardest failures are the ones that look like ordinary configuration changes until the first production incident proves they were not.

Practitioner Guidance

What to prioritise: Focus first on changes that can create immediate exposure, especially public ingress, permissive roles, unencrypted services, and embedded secrets. If the pipeline cannot reliably catch those four classes, broader policy coverage will not matter much.

What to verify: Verify that the scanner evaluates the same artefact that is actually deployed, not only the source file. Also verify that a failed check blocks release by default and that exception handling is auditable, time-bound, and owned by the service team rather than the platform team alone.

Decision rule: If a finding would make the deployed environment harder to recover, harder to audit, or more broadly reachable, treat it as a pre-deployment stop rather than a post-deployment cleanup item.

Practitioner takeaway: IaC security works when the pipeline becomes the place where insecure infrastructure is prevented, not merely reported, and the control is only credible if bypass paths are treated as a design defect.

Related resources from NHI Mgmt Group

• How should security teams embed code quality checks into AI-assisted development workflows without creating bottlenecks?
• How should security teams discover AI usage in source code before deployment?
• How should security teams validate policy-as-code rules before deployment?
• How should security teams govern smart contract code before deployment?