Terraform configurations can select provider versions and install provider packages from a registry, a filesystem mirror, or another configured source. The dependency lock file records the selected provider versions and package checksums. That makes it an important control for reproducible infrastructure automation, but it does not prove that a provider is trustworthy or that the configuration is safe.
The lock file is consumed during initialization. Terraform verifies downloaded provider packages against the checksums recorded for the selected platform. When a team uses a filesystem or network mirror, the lock file can compare mirror packages with checksums obtained from the origin registry. This is how a mirror can remain useful without giving it unlimited authority to replace a provider binary.
Generate checksums from a trusted origin
Use terraform providers lock to populate checksums for the platforms the organization needs. The command can record checksums from the origin registry while producing entries that future initialization can verify against a mirror. Review the resulting lock file and commit it with the configuration. A change to a provider source, version, or checksum is a reviewable infrastructure change.
Do not let a compromised mirror overwrite the lock file and become both the package source and the authority for what the package should be. Generate or update the lock file in a controlled environment with access to the trusted origin, then distribute both the configuration and the lock file through reviewed version control. Protect the credentials that can publish to the mirror.
The required_providers block chooses a provider source and version constraint. The lock file records the exact selected version. Keep both. A broad constraint such as >= 5.0 may allow a new provider release during initialization, and the lock file can prevent that drift only if the repository keeps the lock file and the pipeline does not regenerate it silently.
Separate installation from execution
Checksums verify package bytes. They do not establish that the provider code has no harmful behavior, that its API calls follow least privilege, or that the plan being approved matches the intent of the configuration. Review provider upgrades and inspect plans before apply. Use short-lived cloud credentials and a plan artifact that is bound to the configuration and state used for that plan.
Provider plugins run with the authority of the Terraform process. A provider with access to cloud credentials can make API calls that the configuration does not visibly describe. Restrict the execution environment, use separate credentials for plan and apply where possible, and avoid giving the Terraform job broad organization administrator rights when a narrower role can complete the change.
Modules are a separate dependency problem. A remote module can contain provider requirements, local scripts, and data sources. Pin module versions or commits in a reviewed source, and treat a module upgrade as a code change. Terraform's lock file focuses on providers, so the module source policy needs its own review and provenance controls.
Make drift visible
If the pipeline regenerates the lock file on every run, the repository may show a clean diff while the selected provider has changed. Fail the job when initialization modifies the committed lock file. Use a read-only configuration directory during plan, and store the plan artifact with a hash. Compare the provider versions and lock file hash recorded in the plan with the version used for apply.
Test a mirror serving a different package for the same version. Initialization should fail the checksum comparison. Test a provider source change and a lock file deletion. Both should require an explicit review and approval. Also test the normal upgrade path so operators know how to update versions without bypassing the policy.
The lock file is strongest when it is stable, reviewed, and paired with a controlled package source. It gives the organization a precise statement about which provider binary initialization should accept. The remaining work is to decide who may update that statement and what authority the provider receives when Terraform runs it.