TTerramantle
Get Started Free
Supply chain

You scan every container. Then terraform init runs unvetted code.

Container images go through a scanner before they ship, as a matter of routine. Meanwhile terraform init pulls modules and provider binaries from wherever the source address points and runs them in your pipeline, often with credentials, usually unreviewed. It is the same supply chain, held to a lower standard.

What can actually go wrong

The failure modes are not hypothetical.

None of these are exotic. They are the ordinary ways infrastructure code gets you, and most teams have no control that would catch them.

Typosquatted providers

A provider address off by one character resolves to something you did not write. The binary runs with whatever your pipeline has, and provider code is not sandboxed.

Compromised module tags

A Git tag is mutable. A module you reviewed at v1.4.0 can be quietly repointed at different code, and every consumer picks it up on the next init.

Transitive dependencies

You reviewed the module you called. You did not review the three modules it calls, or the provider versions they pull. Nobody did.

Code that just runs

A null_resource with a local-exec provisioner runs arbitrary commands on the machine doing the apply. A module is not inert data, it is code.

The right layer

Scan once, at the registry, not in every consumer's CI.

You can bolt scanning onto every pipeline that runs Terraform, and then maintain it in every pipeline forever. Or you scan at the point of distribution, once, where the artifact enters your organisation. The registry is the natural chokepoint: everything published passes through it, so it is the one place a check runs on everyone's behalf.

What Terramantle doesHow
Module scanning on publishSecrets, misconfiguration, malware, and known-vulnerability checks run when a version is published, and findings are normalised into tool-agnostic categories.
CVE checks on provider binariesProvider binaries are scanned for known CVEs with severity and fixed-version detail, and a provider SBOM is produced in SPDX form.
Blocking policy at publishResults feed OPA policies. A version that fails an enforcing policy is marked non-consumable and returns 403 on download, so the block is enforced at the registry.
Live-state findingsThe state scanner extracts the endpoints your infrastructure exposes and probes the reachable ports, surfacing the gap between what was reviewed and what is actually reachable.
Honest limits

What scanning at the registry cannot do.

Registry scanning is a layer, not a guarantee, and selling it as a guarantee would be the fast way to lose an engineering audience. It catches known-bad and obvious-bad at the distribution point. It does not watch runtime behaviour, it cannot reason about a module that does something dangerous but legitimate by design, and it does not replace code review, least-privilege credentials, or runtime controls. It moves the cheap, catchable problems to the earliest possible point. The expensive judgement calls are still yours.

For regulated environments where this scanning has to run with no outbound access, see the air-gapped registry page. The supply-chain risks here are also part of why a registry is worth having over Git source refs.

Supply-chain FAQ

What does Terramantle scan?

Modules, provider binaries, and live state. Modules are scanned on publish for secrets, misconfiguration, malware, and known vulnerabilities. Provider binaries are scanned for CVEs. State is scanned for secrets and, where your infrastructure exposes endpoints, the reachable ports are probed. Findings are normalised into tool-agnostic categories so you are not reading five different scanners output.

Do you generate an SBOM?

For providers, yes, as SPDX. When a provider is built or scanned, Terramantle produces an SPDX software bill of materials for it. Per-module SBOMs are not generated today; module scanning focuses on the finding categories above rather than a full bill of materials. We would rather tell you that than imply a capability that is not there.

Can a failing scan block a publish?

Yes, via policy. Scan results feed OPA policies, and a version that fails an enforcing policy is marked non-consumable, which means it returns a 403 on download rather than being silently served. So the block happens once, at the registry, instead of every consumer having to catch it in their own CI.

What can registry scanning not catch?

Plenty, and it is worth being honest about it. It does not see runtime behaviour, it does not evaluate your live cloud configuration beyond what state reveals, and it cannot judge whether a module does something legitimate-but-dangerous by design. It is one layer. It catches known-bad and obvious-bad at the distribution point; it does not replace review, least-privilege, or runtime controls.

Last reviewed