IaC Bazaar

How we test and verify every module

“Verified” is a word most marketplaces wave around. We make it mean something specific and checkable. Every module is graded on a transparent ladder, and we never claim a rung it hasn't earned - in particular, we never call a module live-tested unless it was really applied, verified, and destroyed in a cloud sandbox.

Three independent trust axes

A green badge on one axis never implies the others. We show all three, with the receipts.

Conformance

Does the code hold up to static analysis? Formatting, validation and lint gates that block publication when they fail (Terraform: fmt + validate + tflint; Ansible: ansible-lint). A Checkov security scan runs alongside them, and its findings are disclosed on the module rather than hidden.

Provenance

Can you trust the bytes you download? Every version ships a SHA-256 checksum and a cryptographic signature, so you can verify it was published by us and not tampered with in transit.

Functional

Does it actually run? Only modules really applied to a cloud, asserted against, and torn down clean earn the "live-tested" mark - with the teardown confirmed. Ansible roles additionally have to prove they are idempotent.

The verification ladder

Each module climbs as far as the evidence allows. Rungs 0–3 need no cloud account at all; the top two require real infrastructure.

  1. 0
    ParsesNo credentials

    Syntactically valid; types and required arguments check out.

  2. 1
    Static-verifiedNo credentials

    Passed: validated and lint-clean (provider-schema-validated for AWS/Azure/GCP; Terraform-language lint elsewhere).

  3. 2
    Plan-validatedNo credentials (mocked provider)

    Passed: module logic verified on a mocked plan - inputs, validation rules, conditional creation and outputs resolve (no real provider, no cloud).

  4. 3
    Plan-verifiedA real, empty cloud account (no resources created)

    Passed: plans cleanly against a real provider account; no resources created.

  5. 4
    Live-testedAn isolated cloud sandbox (real apply → destroy)

    Really deployed to a cloud sandbox, verified against its outputs and assertions, then destroyed - with the teardown confirmed.

What “live-tested” means

A module marked live-tested earned it per release, on a real cloud account: we run a real apply, run verification checks against the result (functional assertions where the module ships them, at minimum confirming the promised outputs materialized), then destroy it - and the teardown must be confirmed for the run to count. An apply that did not tear down is treated as an incident, never a pass. Only the subset of the catalog carrying the live-tested mark has been through this; every other module is labeled with exactly the rung it did earn (statically validated, security scanned, and so on).

Verify the signature yourself

Every published artifact is signed with cosign. Don't take our word for it - check the bytes against our pinned public key. The “Cosign signature” link on any module's Verification panel downloads its Sigstore bundle.

# 1. Get our public key (also served at /cosign.pub)
curl -O https://www.iac-bazaar.com/cosign.pub

# 2. Download the module tarball + its signature bundle, then:
cosign verify-blob \
  --key cosign.pub \
  --bundle <module>-<version>.sigstore.json \
  <module>-<version>.tar.gz
# → Verified OK
Our pinned cosign public key
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2OroUv91BLVWzKADQqbRUZE49vw2
4gA2Y96H2afJdjHSbB8DffKWA9mCNwjE1y4ltqv0e6XcP3QjESgN2Wdltg==
-----END PUBLIC KEY-----

Our honesty commitment

The badge on every module is computed from stored evidence by a pure function - it is impossible for a listing to claim more than the verification that actually ran. Static-only modules are labeled exactly that, and when a provider has no applicable security policies we say so rather than implying a clean pass.

How this differs from Azure Verified Modules

Azure Verified Modules (AVM) is Microsoft's own module program: official Terraform and Bicep modules for Azure, maintained to Microsoft's specifications and published free of charge. “Verified” there means Microsoft owns the module and it conforms to the AVM specs - a genuinely useful guarantee if you build on Azure. It is a different thing from what this page describes: AVM covers one cloud, the modules are not sold, and releases do not ship per-release apply→verify→destroy receipts or cosign signatures. IaC Bazaar is a multi-cloud, paid marketplace where every module is statically validated, a marked subset is live-tested per release with public verification receipts, and every artifact is cosign-signed. The two are not mutually exclusive - plenty of estates can use both.