Checkov and Tirith: Where Each Fits in Your IaC Policy Pipeline

TL;DR

• Checkov and Tirith solve different parts of infrastructure policy. Checkov is a strong choice for broad security scanning; Tirith is a focused way to write and enforce the rules that are specific to your organisation or specific IaC project.
• A passing security scan can still leave gaps: a missing ownership tag, a plan over your cost ceiling, or one repository running an older copy of a rule.
• Already running Checkov? Keep it or move it to StackGuardian. Use Tirith for the rules only your team cares about, such as required tags or cost limits.
• Both can run in the CI you already have, between plan and apply. Neither CLI makes a gate unavoidable on its own; your pipeline configuration does.
• Connect StackGuardian when scaling to multiple IaC repos. It can enforce Checkov (every check or selected rules) and Tirith centrally, so enforcement no longer depends on each team adding them to its pipeline, and it reports pipelines where neither is applied.

Most platform teams do not choose between a security scanner and a policy engine. They already run one, usually Checkov, and discover a second category of rule the scanner was never meant to own: the operating conventions of their own organisation. Who owns this resource? Does this change fit the budget? Is every repository enforcing the same version of the rule?

This post is not a head-to-head. It explains where Checkov fits, where Tirith fits, how the two sit in one pipeline, and at what point shared governance through StackGuardian becomes the more important question. Product status was checked on 28 September 2026 against Tirith 1.2.1 and the public documentation linked at the end.

Why a Passing Scan Can Still Leave Gaps

An encrypted, private bucket can still lack the ownership tag your incident process depends on. A technically valid plan can exceed the monthly cost limit your finance partner agreed. A team can run the right checks in one repository while another repository runs a copy of the policy that was last updated a year ago.

None of these are failures of security scanning. They are governance problems that sit alongside it, and they are specific to how your organisation operates. That is the gap worth being precise about.

To be fair to Checkov: it can express custom rules too, in Python or declarative YAML, including graph checks across resource relationships. The case for Tirith does not rest on Checkov being unable to inspect plans, block CI or enforce custom policies. It rests on Tirith’s authoring workflow, its providers for different infrastructure documents, and its optional connection to StackGuardian.

Where Each Fits

The useful question is not which tool wins but which job you are trying to do.

Use Checkov when you want an established catalogue of built-in checks, broad coverage of IaC source formats, and resource-relationship analysis. Add Tirith when its JSON policy model and workflow fit the rules your team needs to write, review and maintain. Connect StackGuardian when the bigger problem is making sure those checks run everywhere: it can take over enforcement of both Checkov and Tirith centrally and show you where they are missing.

The table below compares the right layers: Checkov OSS, Tirith OSS, and StackGuardian running either or both. Commercial capabilities are identified separately. Checkov also integrates with Prisma Cloud, which has its own runtime and governance capabilities.

A note on enforcement: neither CLI makes a gate unavoidable by itself. Configure CI to stop on failure, protect the required checks, and make sure apply uses the exact plan that was evaluated.

Where Tirith Earns Its Place

Rules That Are Easy to Write and Review

Tirith gives policy authors one consistent JSON structure: choose a provider, select the value or operation, then state the condition. The beta interface in Tirith 1.2.1 helps build policies and inspect the resource behind a failure, and lint catches an invalid policy structure before you need a plan. Checkov’s YAML policies are declarative too, so the honest test is practical: write the same operating requirement in each and compare the authoring and review experience for your team.

One Policy Approach Across Documents

Infrastructure decisions involve more than a Terraform plan. They involve an Infracost estimate, a Kubernetes manifest or a CI workflow definition. Tirith supplies providers for each. A plan policy can require an ownership tag while a separate cost policy checks an Infracost total. That is a consistent authoring approach across inputs; a single rule that joins several documents is still roadmap work.

Findings That Become Future Guardrails

Tirith at scale connects scheduled cloud checks with preventive Tirith policies, so a misconfiguration found in a running account can become a rule that stops the same mistake in the next plan. The StackGuardian MCP server exposes workflows, templates, policy attachments and run information to an authorised agent, and Tirith’s policy-authoring skill guides that agent to draft policy JSON against the real schema.

The value is specific to you: your ownership identifiers, the conventions your templates establish, the mistakes you do not want to repeat. Generated rules still need human review and both passing and failing test cases. An LLM drafts; the deterministic evaluator decides whether a change passes.

How Checkov and Tirith Fit in One Pipeline

Illustrative scenario. A team already runs Checkov on its Terraform plan. The selected security checks pass. The organisation also requires an ownership tag on every resource and a monthly cost limit. This is an example of complementary configuration, not a benchmark, and not evidence that Checkov cannot express these rules.

A Small Starting Point

Install Tirith 1.2.1 from the pinned Git tag documented in the repository. The bare PyPI package named tirith is a different project.

pip install "git+https://github.com/StackGuardian/tirith.git@1.2.1"
tirith --version

A minimal plan policy for the ownership rule in the scenario, adapted from the example in Tirith’s policy-authoring skill. Test it against a plan that should pass and one that should fail before you rely on it.

{
  "meta": {
    "version": "v1",
    "required_provider": "stackguardian/terraform_plan",
    "name": "Every resource carries an owner tag"
  },
  "evaluators": [{
    "id": "owner_tag_present",
    "description": "Every taggable resource declares an owner tag",
    "provider_args": {
      "operation_type": "attribute",
      "terraform_resource_type": "*",
      "terraform_resource_attribute": "tags.owner"
    },
    "condition": {"type": "IsNotEmpty"}
  }],
  "eval_expression": "owner_tag_present"
}

With Terraform initialised and the reviewed policy saved as policy.json, place the check between plan and apply. This sequence stops on any error and applies the saved binary plan rather than re-planning:

set -e
terraform plan -out=tfplan -input=false
terraform show -json tfplan > plan.json
tirith -policy-path policy.json -input-path plan.json --fail-on-error
terraform apply -input=false tfplan

Treat plan artifacts as sensitive and protect the CI workflow that consumes them. Tirith does not yet provide built-in plan identity verification, so reusing the saved plan and protecting the required checks remain your responsibility.

From One Repository to Central Enforcement

One rule in one repository is a good start. The question changes when that rule belongs in fifty repositories: who owns it, how is a new version rolled out, and where can you see every result, including the repositories that are not running it at all?

Running checks inside each team’s pipeline has a weak point: enforcement depends on every team adding the step, keeping it current and not switching it off. StackGuardian supports Checkov as well as Tirith, so you can move Checkov out of individual pipelines and into the platform. From there you can enforce Checkov as a whole or only the rules you select, alongside your Tirith policies, and control both centrally instead of relying on each team to wire them in.

StackGuardian also reports on the gaps: pipelines where Checkov or Tirith is not being applied. That turns “we think every repository runs the checks” into a list of the ones that do not.

If you are not ready to move enforcement, platform mode is a lighter first step. Your pipeline keeps running Tirith, sends the evaluation to StackGuardian and gets the result back, and StackGuardian retains the run evidence and policy results. Broader controls, such as credential brokering, private execution, drift detection and recovery, require the appropriate platform workflow, permissions and state or execution connection; they are not side effects of installing the CLI.

Start with one repository and one rule that matters, then map how Tirith at scale and StackGuardian can take over enforcement for the wider organisation. You choose when to move execution into the platform.

Conclusion

Checkov and Tirith are not competing for the same slot in a pipeline. Checkov covers broad security scanning well. Tirith gives you a declarative, reviewable way to enforce the rules that only your organisation cares about, across plans, cost estimates, Kubernetes and workflow files. StackGuardian becomes relevant when both need to run everywhere: it can enforce Checkov and Tirith centrally, show where they are missing, and keep the evidence.

A useful first step is to ask one question: which infrastructure rule do your engineers still check by hand, and how do you know every repository enforces it? Try Tirith on that rule in your existing CI, or bring your pipeline to a StackGuardian engineer to map what shared governance would look like.

FAQs

1. We already use Checkov. Why add Tirith?

Add it if Tirith’s policy-authoring experience, or the path to shared StackGuardian governance, solves a real gap for you. Keep Checkov’s scanning either way; StackGuardian can run both. If Checkov plus your existing CI already handles your rules, distribution and evidence well, there may be no immediate reason to add another tool.

2. Can StackGuardian run our existing Checkov checks?

Yes. StackGuardian supports Checkov as well as Tirith. You can enforce Checkov as a whole or only selected rules from the platform, control it centrally rather than relying on each team to add it to their pipelines, and see reports of pipelines where Checkov or Tirith is not applied.

3. Could we write the same check in Checkov?

Often, yes. Checkov supports Python and YAML custom policies, graph relationships and shared checks loaded from Git. Compare the effort to author, explain, validate, distribute and operate your actual rules. Tirith’s value is in how those policies are authored, understood and operated alongside StackGuardian.

4. Do we have to move CI or buy StackGuardian to use Tirith?

No. Tirith’s local evaluator is Apache-2.0 and works without an account. Platform mode is optional and evaluates against your StackGuardian organisation. Existing apply jobs can stay in place.

5. Does an “approval required” result stop an external CI job?

Not today through this integration; it is reported as a warning. Use your CI’s own approval gate where needed, or an appropriately configured StackGuardian execution workflow. A recorded approval request is not the same as enforced human approval.

6. Does using AI agents change the security model?

Human-authored and agent-authored changes can pass through the same configured gate. Agents can help draft policies or propose fixes, but review, tests and deterministic evaluation remain essential. Neither tool can guarantee a change is safe beyond the checks and inputs it actually evaluates.

‍

Availability and Sources

Checked on 28 September 2026. Tirith 1.2.1 is the latest stable release; it includes the beta interactive interface, lint and format commands and richer result context. Still in development: predefined policy packs (PR #364), PyPI publishing (PR #284), native YAML policy authoring, mixed-provider and multi-document rules, plan identity verification, richer before/after predicates, and external CI approval coordination. An open PR or issue is not a shipped capability. Directly initiating infrastructure execution from Tirith is labelled planned on the Tirith at scale page; check availability, configuration and entitlement for your deployment.

• Checkov overview
• Checkov Terraform plan scanning
• Checkov YAML custom policies
• Checkov sharing custom policies
• Checkov hard and soft fail
• Tirith release 1.2.1
• Tirith repository and usage
• Tirith platform check reference
• Tirith GitHub Action
• Tirith policy-authoring skill
• Tirith at scale
• StackGuardian MCP server documentation

Related reading: IaC security best practices: policy enforcement in Terraform workflows and Terraform MCP Server: what it is and how it works.