Terraform Security Review Checklist

Review the intended change and the plan

Start with the purpose of the change: which service needs access, to what, and for how long? Then inspect the plan for creation, replacement, and deletion, including changes in dependent resources. A seemingly small variable update can have a much larger effect than the diff suggests.

Plans depend on the configuration, state, input values, and provider behavior used to create them. Review the plan produced by the actual change workflow, and understand what can change between review and apply. The Terraform plan reference describes planning modes and saved plans. Keep an explicit human decision before applying a change to a production environment.

terraform fmt -check -recursive
terraform validate

Run validation in an initialized working directory. These checks help with formatting and configuration validity; they do not certify the proposed access rules or predict every runtime consequence.

Treat state and plan artifacts as sensitive

Marking an input sensitive affects how Terraform displays it. It does not automatically remove the value from state or make the state file safe to publish. Review backend access, artifact permissions, retention, and what CI logs expose.

Do not commit state files or share saved plan artifacts as public examples. Before sending configuration to any analysis service, remove real credentials and unnecessary private values. A filename such as example.tf does not make its contents anonymous. HashiCorp’s sensitive data guidance explains the distinction between redaction and storage, including features that depend on your Terraform and provider versions.

Explain every broad network rule

For an AWS security group, review the source or destination, protocol, port range, and attached resources together. A public web listener and an administrative port have different exposure requirements. Ask whether a narrowly scoped security group reference or network range can satisfy the actual need.

Security groups contain allow rules, and the rules associated with a resource combine. Inspect that combined access rather than reviewing one rule in isolation. Remember to consider IPv6 as well as IPv4 when present. The AWS security group guide describes this behavior. A configuration warning should lead to a specific access decision, not an automatic blanket replacement that interrupts a service.

Keep findings attached to a decision

For each finding, record the affected resource, proposed change, reviewer, and validation step. If you accept an exception, explain the business requirement and when to revisit it. If you change access, test the intended connection and verify that the broader access is no longer required.

Sentinel can inspect supported Terraform configuration patterns and provide file-level findings. It does not execute Terraform plans, inspect every cloud permission, or prove the effective permissions of a live account. Review supported fix previews as proposed changes. Keep your provider-specific checks, plan approval, and rollout procedure alongside them.

For teams reviewing several client environments, see the DevOps agency workflow. Before uploading private infrastructure, review how Sentinel handles configuration and optional AI context.