Provider and Module Supply Chain

Scenario: A configuration references a mutable Git branch, and compromised upstream code runs with production credentials on the next init/apply.

Pin Terraform versions, provider constraints and lock checksums, and immutable module versions or commits. Review dependency upgrades, use trusted registries or mirrors, verify provenance where available, scan configuration and modules, and restrict outbound access from runners. Remember that a module is executable infrastructure logic and a provider is native code loaded by Terraform.

Analogy: IaC dependencies are contractors handed keys to the building. Reputation helps, but identity, contracts, inspection, and restricted access are still required.

A worked configuration

terraform {
  required_version = "~> 1.9.0"
  required_providers {
    fakecloud = { source = "shellgenius/fakecloud", version = "~> 1.0" }
  }
}

Mirror dependencies for resilience and review, but maintain an upgrade cadence for security patches. Indefinite pinning avoids surprise only by accumulating known vulnerabilities and incompatibility.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-version-lockfile Terraform lab. Open /labs/terraform and choose slug tf-version-lockfile; the lab runs real Terraform against the offline FakeCloud provider.