auditing-iac-module-and-provider-supply-chain

Auditing IaC module and provider supply chain: when planning runs someone else's code

Infrastructure-as-code feels declarative, but modules and providers are code, and they run with the credentials of whoever plans or applies them, which in a pipeline is usually a highly privileged identity. That makes the module and provider supply chain a direct path to those credentials. A module sourced from an unpinned reference can change under you between runs; a provider or plugin pulled without integrity verification can be swapped at the registry; a module that shells out or fetches remote content during planning executes on the runner before anyone reviews an apply; and a lockfile that is absent or not enforced lets the resolved versions drift. The declarative surface hides that a plan is an execution. You audit this by finding where module and provider code enters and whether its source and integrity are pinned.

When to use

• Infrastructure is built from third-party or shared modules and from providers pulled at init time.
• Module sources or provider versions are unpinned, or a dependency lockfile is missing or unenforced.
• Plan or apply runs in CI with a privileged identity, so executing module code reaches real credentials.

Scope check

Audit IaC supply chain only for infrastructure and pipelines you own or are authorized to assess, on non-production state. Confirming that a module executes at plan time runs code on the runner, so keep any proof benign and inside the authorized pipeline. If you can't name the authorization, stop.

The loop

1. Establish the apply identity and its power first. Name the credentials that plan and apply run under and what they can do in the environment. This is the false-positive killer that sets severity: an unpinned module matters far more when apply holds broad cloud permissions than when it is tightly scoped. Name the identity, then trace what code runs under it.

2. Inventory every module and provider source. List where each module comes from (a registry, a version- control reference, a local path) and every provider or plugin the configuration pulls. Each external source is code that will run under the apply identity. Distinguish first-party internal modules from third-party ones, since the trust question differs.