Safeguard
Supply Chain•

What does the Terraform dependency lock file protect, and what not?

The .terraform.lock.hcl file records provider versions and checksums with trust on first use. It does not cover modules. What to commit and review.

Safeguard Security Team
4 min read

The Terraform dependency lock file records which provider versions you selected and their checksums, so later runs make the same choice and flag a changed package. It uses trust on first use, and at present it tracks only providers, not modules. Commit it and review changes to it like code.

Definition

The lock file is named .terraform.lock.hcl and belongs to the configuration as a whole. Terraform creates or updates it each time you run terraform init. Version constraints in your configuration say which versions are acceptable, and the lock file remembers the exact choice so it can be repeated.

Providers are plugins. Terraform downloads them and runs them with access to whatever credentials you gave the provider block, so a provider package is high trust code in an infrastructure pipeline.

What the lock file does

BehaviorDetail
Pins selectionSame provider version on later runs, by default
Verifies on installEach installed package must match at least one recorded checksum, or Terraform errors
Trust on first useThe first install defines what "expected" means
Signed checksumsIf the origin registry signs checksums, Terraform treats the signed ones as valid as long as one matches
Multi platformThe file can include checksums for packages for other platforms

The documentation is explicit that the checksum check is a trust on first use approach. If the first install already came from a bad source, the lock file records the bad result faithfully. The signature behavior gives extra assurance on signed providers, and the init output shows the key fingerprint, with a label such as signed by a HashiCorp partner.

What it does not protect

First, modules. The docs say the lock file currently tracks only provider dependencies. Module sources need their own pinning, using exact versions or commit references and review of changes.

Second, the first install. Nothing in the file proves the original download was legitimate. That is why you also care about where providers come from: official namespaces versus community providers.

Third, the provider's behavior. A correctly pinned and signed provider can still have a bug or a vulnerability. The lock file preserves integrity, not safety.

Habits that make it useful

  1. Commit the lock file. The docs recommend including it in version control so changes go through code review.
  2. Treat a diff in the lock file as a review item. Ask which provider changed, from which version to which, and why.
  3. Generate checksums for every platform your team and CI use, so nobody runs init and silently rewrites the file because of a platform mismatch.
  4. Upgrade providers deliberately with an init upgrade in a branch, not as a side effect.
  5. Pin module versions explicitly and avoid floating references to a branch name.
  6. Prefer providers from official or well known publishers. For community providers, read the repository and release process before first use, since first use is the moment the file trusts.
  7. Run planning with the least privileged credentials that can do the job, because providers run with them.

A quick review prompt

When a pull request touches .terraform.lock.hcl, ask three questions: did a version change on purpose, did the source address stay the same, and did the set of checksums change in a way that matches adding a platform rather than swapping a package?

Try it yourself

Click through it at your own pace, or open it full screen. Watch a dependency change get checked before merge, as a lock file diff should be.

Where Safeguard fits

Safeguard's SBOM and dependency scanning, plus policies and gates, can check infrastructure repositories for changes before merge. The free scan is at gold.safeguard.sh/scan.

Quick check

Does the lock file cover Terraform modules?

Not at present. The documentation says it tracks only provider dependencies, so pin modules separately.

What does trust on first use mean here?

The first download defines the expected checksums. Later installs are checked against them, but the first one is taken on trust unless the provider's signed checksums apply.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.