auditing-iac-module-and-provider-supply-chainlisted

# 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 t