How would you gate a Terraform plan so every module call uses an approved source at a pinned version?

### The control, stated plainly "Only approved modules, at a pinned version." It is a provenance control, not a configuration control: it says nothing about whether a bucket is encrypted, only about where the code that creates the bucket came from and whether you can name exactly which revision of it ran. Organisations adopt it because it converts an unbounded review problem — every resource every team writes — into a bounded one: review the modules, then require that everything comes through them. ### Why the expanded view cannot answer it A plan flattens modules into concrete resources addressed like `module.network.aws_s3_bucket.flow_logs`. That address proves a call named `network` exists. It does not say the module came from your internal registry rather than a stranger's repository, and it certainly does not carry a version. Any attempt to write this rule over the planned resource list fails silently: the fields it needs are not there, so the rule matches nothing and reports green. A gate that passes because it is looking in the wrong place is worse than no gate, because someone will cite it in a review. ### Where to look instead The plan's `configuration` section preserves the configuration as written, before expansion. Under the root module it carries `module_calls`, an object keyed by the call name. Each entry records the module's `source`, the version constraint when the call sets one, the expressions passed as inputs, and a nested `module` object holding that module's own resources and its own `module_calls` — so the entire call tree is reachable from the top. ### The two predicates **Approved source.** Maintain an allowlist, and match the source string against it by prefix, not by exact equality — an internal registry namespace, or the organisation's repository host and path. Prefix matching is the point that gets botched: a substring test lets a lookalike host pass, and an exact-match list needs editing for every new module. Decide explicitly what a local relative path means. A call into a directory inside the same repository has no version at all, so a naive pinning check either crashes on the missing field or waves it through; treat local paths as their own case and rule on them deliberately — often permitted, because the code is in the same reviewed repository as the call. **Pinned version.** The interesting judgment is what "pinned" means. A constraint that permits a range means today's plan and next month's plan can run different code from the same unchanged file — the gate approved something it cannot name. So require an exact version, and treat a branch name, a moving tag, or a default-branch reference as unpinned even though it looks specific. What you are really asking for is immutability: given the call, can I fetch exactly the code that ran? This is also what makes an audit trail possible later — the same reason a control that says "a version is set" is weaker than it sounds. ### Depth: whose calls do you rule on? Because the nested `module` objects expose calls made by modules further down, you can enforce provenance at any depth. You usually should not enforce it at every depth in the caller's pipeline. If an approved module internally calls something outside the allowlist, the developer whose plan you just blocked cannot fix it — they do not own that code. The workable split is: enforce on the root configuration's own calls in the application team's gate, and enforce the same rule on module repositories' own calls in the module release pipeline, where the person who can fix it is the person who gets the failure. Same rule, two places, addressed to whoever can act. ### What the control proves, and what it does not It proves you know which artifact ran. It does not prove the module is safe, secure or correct — that is what module review, and the resource-level rules that still run over the expanded output, are for. Nor does a green result prove that the approved module was used *for everything*: a team can call approved modules and still declare raw resources beside them, so provenance is a complement to resource rules, never a replacement. The strength of the control is entirely a function of how well the allowlisted modules are reviewed and how quickly a fixed version reaches the callers pinned to the old one. ### Practical notes Because `source` and version constraints are static configuration, they are known at plan time and never appear as values resolved only during apply — this is one of the few rules on an infrastructure plan that never has to reason about missing data. And the rule should identify the offending call by its name and source in the denial, since the call name is what the developer can find in their own file.