IaC Bazaar
Browse modules
Menu

The verification standard

Proof you can
look into.

Know what was checked, what actually ran, and what the evidence does—and doesn’t—say.

Explore the process Inspect a module
Per-version evidence. Independent checks. Confirmed teardown.
THE EVIDENCE MODEL
Every claim
has a boundary.
  • 01
    Does the code hold up?Static validation and disclosed findings
  • 02
    Are these the signed bytes?Checksum and artifact signature
  • 03
    Was it tested in the real world?Live evidence, only where earned

A pass in one area never implies a pass in another.

01 / From code to cleanup

A test has to finish
what it started.

Choose a stage to see what happens. This walkthrough explains the live-test lane; it does not run infrastructure.

Inside a live testIllustrative walkthrough

Step 01 / 04

Inspect the code.

Validate structure and lint the module. Where applicable, security checks report findings as a separate result.

Evidence producedStatic checks and applicable security findings

Passing a static check does not prove a cloud deployment works.

02 / Read the whole picture

Three questions.
Independent answers.

The module’s headline badge is a starting point. Its evidence panel separates code checks, signatures, and functional results.

Conformance

Code quality

Formatting, validation, and lint checks. Terraform and OpenTofu use their applicable checks; Ansible roles use YAML and Ansible linting. Security findings are disclosed separately.

Provenance

Trusted bytes

A published checksum and cryptographic signature let you check the artifact you download against the version we signed.

Functional evidence

Observed behavior

A live-tested release was really applied, checked, and torn down with cleanup confirmed. Ansible roles additionally have to demonstrate idempotence.

Security is its own result. “Findings”, “not applicable”, and “not yet scanned” mean different things. A functional test does not replace a security assessment.

901Published modules
341Recorded live-test passes
317Security scans passed
11Security scans with findings

348 modules have no applicable security policy. Counts reflect the published catalog and refresh periodically.

03 / Evidence earns the label

How far was
this version tested?

Each level describes a different depth of functional evidence. Security scanning stays separate from this ladder.

  1. 01

    Parses

    Syntactically valid; types and required arguments check out.

    Code only
  2. 02

    Static-verified

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

    No cloud credentials
  3. 03

    Plan-validated

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

    Mocked provider
  4. 04

    Plan-verified

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

    Real cloud account · no resources created
  5. 05

    Live-tested

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

    Real sandbox · apply and confirmed teardown

Cleanup is part of the proof.

A live test checks the result, then destroys the resources and confirms teardown. An apply that does not tear down is an incident, never a pass. Only releases carrying the live-tested mark earned that level; the module’s receipt distinguishes machine-readable evidence from older recorded attestations.

04 / Independently checkable

Verify the signature
yourself.

Download a module’s tarball and its Sigstore bundle from the Verification panel, then check the bytes against our pinned public key.

Download the public key
View the pinned key
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE2OroUv91BLVWzKADQqbRUZE49vw2
4gA2Y96H2afJdjHSbB8DffKWA9mCNwjE1y4ltqv0e6XcP3QjESgN2Wdltg==
-----END PUBLIC KEY-----
YOUR TERMINALcosign
# Get the published public key
curl -O https://www.iac-bazaar.com/cosign.pub

# Verify your downloaded artifact
cosign verify-blob \
  --key cosign.pub \
  --bundle <module>-<version>.sigstore.json \
  <module>-<version>.tar.gz

A valid signature proves the signed bytes match. Read the verification evidence to understand what was tested.

Before you rely on it

Know the boundaries.

Does “verified” mean every module was live-tested?

No. Every published module is statically validated. Only the marked subset earned a real live-test pass. The badge is derived from stored evidence for that version.

What does a live test check?

It applies the module, runs functional assertions where the module provides them, at minimum confirms its promised outputs, then tears down and confirms cleanup. It is evidence about that run—not a guarantee for every account or configuration.

How does this relate to Azure Verified Modules?

Azure Verified Modules is Microsoft’s module program for Azure. To compare a module, review that program’s specifications alongside the specific checks and receipts shown here.

Read the AVM documentation ↗
What verification does not prove →

Make the next decision with evidence

See the proof
for your next module.

Explore the catalog →Verify a licence key