The Terraform dependency lock file records provider selections, not remote module versions. So a scan reading the lock file can report providers exactly, but module versions are only as precise as the version constraints in your configuration. Pin modules explicitly if you want a scan to know what you use.
What the lock file tracks
The HashiCorp documentation states that the dependency lock file, a feature of Terraform 0.14 and later, tracks only provider dependencies at present, and that Terraform does not remember version selections for remote modules, so it always selects the newest available module version that meets the specification. It also explains that the lock file belongs to the configuration as a whole, living in the working directory with the root module, and that it lets Terraform make the same decisions again in future.
So there are two kinds of dependency with different pinning behaviour.
| Dependency | Pinned by lock file | Where precision comes from |
|---|---|---|
| Provider | Yes | Lock file |
| Remote module | No | Your version constraint |
| Local module | Not applicable | Your own code |
Why this matters for coverage
If a module source says version = "~> 3.0", a plan today may select a different release than a plan next month. A scanner reading only configuration sees a range, not the resolved version. That is the same range problem seen in other ecosystems. See lockfile or installed packages: what the scanner actually reads.
How to pin and inventory
- Commit
.terraform.lock.hclto version control so provider choices are shared and reviewable. - Pin remote modules to an exact version, not a range, and review changes in pull requests.
- For modules sourced from git, pin to a tag or commit. See does a scanner match a dependency pinned to a git commit.
- Produce an inventory of providers and modules with versions from your pinned configuration and keep it with each release.
- Update on a schedule, reading provider and module changelogs.
What scanners cover here
Two different things are scanned in Terraform work. Configuration scanners check your resources for misconfiguration. Dependency scanners check the providers and modules as software. Do not assume one does the other's job. Ask your tool which it does, and test with a canary.
Review checklist
- Is the lock file committed and current?
- Are remote modules pinned exactly?
- Is there an inventory per release?
- Do you know who updates providers, and how often?
Safeguard offers dependency scanning and a free scan at gold.safeguard.sh/scan. Check how any tool treats providers and modules before relying on it.
Quick check
Is the lock file enough to know my full Terraform dependency set?
No. It covers providers only, so pinned module versions are also needed.
Should the lock file be committed?
Yes, so provider selections are consistent across machines and visible in review.
Sources
Last reviewed: 19 October 2026.
