Terraform security checklist for SaaS infrastructure
Secure Terraform and infrastructure as code with protected state, secret handling, reviewed plans, trusted modules, scoped CI access, and drift checks.
In this guide
What is infrastructure as code security?
Infrastructure as code (IaC) security is the practice of protecting cloud resources and the code, credentials, plans, state files, and automation used to create them. For a SaaS team using Terraform, a sound baseline keeps secrets out of source control, reviews proposed changes before production, limits who and what can apply them, and checks deployed resources for drift. A scanner helps find issues; it does not replace human review or a tested change process.
Treat Terraform state and saved plans as sensitive data
State and plan files can contain resource details and secret values. Do not commit `terraform.tfstate`, backup state, saved plan files, sensitive variable files, or local Terraform working directories. Use a remote backend that supports access control, encryption, audit records and state locking; confirm the provider's exact behavior and recovery process.
Separate infrastructure code from secret values
Do not hard-code credentials in `.tf` files, pull requests, command arguments or test fixtures. Terraform's `sensitive` marker redacts some output but does not automatically prevent a value from being stored in state. Use supported ephemeral or write-only features only when the Terraform and provider versions support them, and keep the source secret in an approved secrets system.
Make the expected security boundary explicit
Document which accounts, projects, regions, networks, data stores and production services the code can change. Identify approved public entry points and exceptions, along with the owner who can accept a material risk. A clear boundary helps reviewers spot a proposed public database, overly broad role or cross-environment connection before it reaches production.
| Change or workspace | Sensitive values and state | Planned access or exposure | Reviewer and test evidence | Apply owner and rollback |
|---|---|---|---|---|
| Production network change | ||||
| New storage or database | ||||
| CI provider or module update |
How do you secure a Terraform workflow before apply?
Run source, dependency and plan checks in a protected pull request
Validate formatting and configuration, review provider and module sources, and scan the proposed plan for public exposure, broad privileges, unencrypted storage and policy violations. Pin trusted dependencies to reviewed versions and retain the plan with controlled access. A clean static scan is useful evidence, not proof that the design is safe.
Use a dedicated, short-lived deployment identity
Give the automation identity only the cloud permissions needed for its environment and deployment role. Prefer federation or the platform's workload identity over long-lived access keys. Protect the CI workflow definition, secrets, runners and approval rules; an attacker who can alter trusted pipeline code may inherit its deployment authority.
Require a second-person check for high-impact production changes
Show reviewers the readable plan, affected environment, resource replacements or deletions, security exceptions and expected customer impact. Require explicit approval for changes that expose a service publicly, alter identity boundaries or delete data. Run `apply` only from the reviewed plan or otherwise prove the applied plan matches what was approved.
How should SaaS teams protect Terraform state and detect drift?
Restrict state access to people and automation that need it
State can reveal infrastructure relationships and values, so grant access by workspace and role rather than sharing one broad backend credential. Enable backend encryption and access logs, protect backups, and test restore procedures. Removing a person from the repository alone may not remove their access to old state versions or plan artifacts.
Detect changes made outside the reviewed workflow
Compare deployed resources with the approved baseline using provider configuration history, policy checks or a drift review. Investigate whether each change was authorized, an emergency fix, a provider default change or an untracked resource. Reconcile the code and live system deliberately; do not automatically overwrite a production change before its owner and impact are understood.
Plan a safe response to a leaked value or unsafe deployment
Revoke or rotate the exposed credential, determine whether state, logs, plans, caches and backups also contain it, and assess access history. For an unsafe change, first stabilize the service and preserve needed evidence; then revert or repair through a reviewed change. Record what failed and add a control that would catch the same path earlier.
Terraform and infrastructure as code security FAQs
Does `sensitive = true` keep a secret out of Terraform state?
No. HashiCorp documents that the marker redacts selected output, while values can still be stored in state and plan files. Use a supported mechanism that omits a value from persistence when available, and protect the backend as sensitive data.
Can an IaC scanner approve a production change by itself?
No. Scanners can flag patterns and policy violations, but they may miss context, provider behavior, runtime exposure and business exceptions. Review the plan, trust boundary, evidence and rollback path before applying high-impact changes.
Should teams commit Terraform lock files?
Commit `.terraform.lock.hcl` so the selected provider versions and checksums are reviewable and consistent. Keep state, local working directories and saved plans out of version control, and review provider upgrades as code changes.
What if a cloud console change creates Terraform drift?
Check who made it and why, preserve emergency changes that keep users safe, and compare the live resource with the repository. Update code and state through the normal reviewed process or revert only after confirming the service impact and the right owner.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Infrastructure as Code Security Cheat SheetOWASP Foundation
- Terraform: Manage Sensitive Data in Your ConfigurationHashiCorp
- AWS Config: Managing and Viewing AWS Resource ConfigurationsAmazon Web Services
- NIST SP 800-128: Guide for Security-Focused Configuration ManagementNational Institute of Standards and Technology