Terraform security review: why a passing scanner is not proof of secure infrastructure

Terraform turns infrastructure changes into reviewable artifacts, but a successful pipeline does not become a security conclusion. A scanner sees the material it receives, applies its configured rules, and reports within that model. It does not inherently know whether the CI role matches the trust model, who can read state, which resources changed outside Terraform, or whether a fix was verified in the cloud. A buyer therefore needs an assessment of the path from HCL to the running resource, not another CI checkbox.

A useful review answers a practical question: can the team explain and demonstrate what was tested, in which context, and what remained outside the boundary? The approach below helps purchase that outcome without promising absolute security or replacing expert judgment with an automated report.

A green scanner is a signal, not a verdict

The first distinction is between syntax, an evaluated plan, and the live environment. terraform validate checks whether configuration is internally consistent, but it does not validate remote services. A plan adds the values and proposed actions of a particular run. Scanning plan JSON can give a tool more context and dependencies, yet some HCL information is absent from the plan and the plan itself may contain sensitive values. Each layer is useful, but each answers a different question.

Scanner output also depends on the active policy set. A resource-level suppression, a severity filter, or soft-fail behavior can produce a passing job without removing the original condition. Review scope should therefore include the scanner configuration: which policies ran, where suppressions exist, who approved them, when they expire, and whether skipped checks remain visible in the build artifact.

What the purchased assessment should include

The minimum review object is broader than a directory of .tf files. The reviewer needs root modules, in-house and external modules, provider versions, the dependency lock file, variable contracts, and backend configuration without receiving secret values. A saved plan for an agreed environment matters because it exposes evaluated values and intended actions. CI workflow files, the identity matrix, state-access policy, and a description of manual cloud changes complete the evidence set.

The buyer should decide whether the engagement is limited to code review or also compares code with the cloud environment. A code-only review can identify risky HCL and weak pipeline settings, but it cannot establish the absence of drift, external policies, or resources created outside Terraform. A production-relevant conclusion needs controlled read-only access to the agreed accounts and logs, or a guided evidence session in which the system owner demonstrates the relevant facts.

State and secrets form a separate trust boundary

The sensitive marker redacts normal output but does not by itself omit a value from state or plan. Terraform supports ephemeral mechanisms for some temporary values, but their availability depends on the Terraform version, provider support, and the specific argument. A review should determine the complete secret path rather than merely noticing a marker: secret store, CI issuance, logs, plan, state, backups, and administrative access.

Treat state as a sensitive asset. Scope the backend, encryption, locking, workspace separation, emergency access, read auditing, and recovery process. Review who can change backend settings or run state commands. The buyer does not need to email state to a supplier; limited access inside an agreed environment, or a guided demonstration of properties and evidence, usually provides a safer route.

Plan, CI, and cloud identity must be reviewed together

A protected pipeline does not end when the scanner runs. The assessment connects the triggering event, reviewed commit, generated plan, and identity permitted to apply it. For GitHub Actions, that means examining permissions, untrusted input, third-party actions, reusable workflows, environments, and cloud-token conditions. OIDC can remove the need for a long-lived cloud key, but the cloud trust policy must still constrain the repository and the applicable execution context, such as a branch, environment, or reusable workflow, using supported audience and subject conditions.

Providers and actions are executable dependencies. The Terraform lock file records selected provider versions and checksums to support reproducible installation, so changes to it belong in code review. References to third-party actions, token permissions, and any path that executes pull-request code form part of the same boundary. Even when no defect is found, the report should name dependencies that were not inspected and assumptions about hosted or self-hosted runners.

1. CommitIdentifies the reviewed HCL, module references, lock file, and workflow
2. PlanEvaluates the change for the selected workspace
3. ReviewCompares policies, exceptions, and intended effect
4. Apply identityReceives only the agreed privileges
5. Live verificationConfirms the result and remaining drift

Drift changes the meaning of a code-only result

Terraform decides from configuration, state, and data returned by the provider. A console edit, emergency change, or separate automation system can create a mismatch. A refresh-only plan reveals remote-object changes and previews the proposed state update; only a refresh-only apply records that update without changing the remote resources themselves. The owner must still decide whether to accept or reverse that drift. Clean HCL does not answer whether production matches the repository.

The engagement should record the evidence time and the included accounts, regions, and workspaces. For critical resources, compare permissions, network boundaries, encryption, and logging in the live cloud with the intended model. Classify each mismatch as an accepted exception, an untracked change, an unmanaged resource, or a code defect. This produces actionable remediation instead of a generic “Terraform error.”

What fix verification looks like

Consider a hypothetical team whose HCL creates storage and a role, whose scanner passes, and whose CI applies the plan through OIDC. During review, the assessor finds that a sensitive output still enters state, a suppression hides a public-access policy, the trust policy permits an extra branch, and a bucket setting was changed manually. This is not a real incident; it demonstrates how four locally green components can form a weak system.

Verify each fix against its cause. For the secret, demonstrate the new data path and the absence of the value from a new plan or state where an appropriate ephemeral or write-only mechanism is supported. For the suppression, retain a defensible exception or restore the check. For OIDC, narrow the trust policy and demonstrate rejection from an unapproved context. For drift, agree on the desired state, rerun the plan, and compare the live resource. The retest should record the commit hash, workspace, time, and observed result rather than only a screenshot of a green job.

A buyer matrix and a useful deliverable

A narrow HCL-and-plan review can fit a new module when its limitations are explicit. Before a material release, include state, CI identity, the evaluated plan, and a read-only cloud comparison. With multiple accounts, shared modules, and different pipelines, use a sampling design: inspect critical trust boundaries deeply, select representative repeated configurations, and list every exclusion.

The buyer should receive a coverage matrix, evidence-backed findings, the suppression and untested-component register, impact scenarios, remediation priorities, and retest results. Our guide to a useful pentest report explains the reporting standard, while the related Infrastructure as Code assessment separates the general IaC process from Terraform-specific concerns.

Pentest.red can perform a cloud security audit with an agreed Terraform boundary and fix verification. Before requesting an assessment, record repositories, workspaces, cloud accounts, permitted access, and required evidence in the scope planner. Quotes can then compare the same work, and the engagement will deliver more than another scanner run.