Checkov and Tirith: Governing Every IaC Pipeline With StackGuardian

TL;DR

• Many IaC pipelines already run a security scanner such as Checkov. The rules specific to your organisation, such as required tags, cost limits and team conventions, still need an owner and a way to be enforced.
• Tirith is StackGuardian’s open-source policy engine for those rules. You write them as declarative JSON and evaluate them against Terraform plans, Infracost estimates, Kubernetes manifests and workflow files.
• Connecting a pipeline takes one step after terraform plan: the Tirith GitHub Action, the Tirith GitLab CI/CD component or a Tirith Bitbucket Pipelines step.
• Once connected, StackGuardian runs Tirith, Checkov and other policy engines such as Wiz on plans and code artifacts, keeps every result for audit, and reports the pipelines that skip the checks.
• The platform adds plan visualisation, continuous enforcement, approvals, credential brokering, run snapshots, drift detection, recovery, notifications, SG Code modernisation and AI remediation with Kyro, including turning a finding into a Tirith policy.

Most platform teams already scan their infrastructure code, often with Checkov. Over time they find a second category of rule that a generic 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, and can anyone prove it?

This post covers how Tirith turns those rules into policy as code, how to connect the pipelines you already run to StackGuardian with a single step, and what the platform does with every plan once it can see them. Product status was checked on 1 October 2026 against Tirith 1.2.1 and the documentation linked at the end.

Where Security Scans 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.

These are governance problems that sit alongside security scanning, and each one is specific to how your organisation operates. Solving them takes three things: a clear way to write your own rules, a reliable way to run them on every change, and a record that shows they ran.

Tirith: Your Own Rules as Policy as Code

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 you build policies, experiment in a playground and inspect the resource behind a failure, and lint catches an invalid policy structure before you need a plan. Reviewers read a policy the same way every time, which keeps rule changes quick to approve.

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, so a plan policy can require an ownership tag while a separate cost policy checks an Infracost total, both written the same way. A single rule that joins several documents is still roadmap work.

Policies Owned Centrally

A policy file copied into fifty repositories drifts into fifty versions. With platform mode, tirith platform check evaluates the same plan against the policies your StackGuardian organisation enforces, with the same verdicts and exit codes. Policy owners change a rule once, and every connected pipeline picks it up on its next run.

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 that requires an owner tag, 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"
}

To try it locally, place the check between plan and apply. This sequence stops on any error and applies the saved binary plan:

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. Tirith does not yet provide built-in plan identity verification, so make sure apply uses the exact plan that was evaluated and protect the required checks in CI.

Connect Your IaC Pipeline in One Step

You do not need to rebuild your pipelines to bring them under governance. Add one step after terraform plan in the CI system you already use, and the plan flows to Tirith and StackGuardian. Existing apply jobs stay where they are.

Every route works in local mode first, evaluating policy files committed to the repository. Switch the same step to platform mode when you want StackGuardian to own the policies, run the other engines and keep the evidence.

What StackGuardian Adds Once Your Pipeline Is Connected

StackGuardian runs Tirith, Checkov and other policy engines you already rely on, such as Wiz, on plans and code artifacts. It keeps every result, links it to the run that produced it, and makes it available for audit and for remediation through Kyro AI.

Some of these depend on how far you connect the platform. Approvals, credential brokering, drift, recovery and snapshots need the relevant workflow, permissions and state or execution connection, which you configure separately from installing the CLI.

From Finding to Guardrail With Kyro

A finding fixed once can return in the next pull request. Kyro, the AI assistant in StackGuardian, closes that loop. When a scan, a policy result or detected drift raises a finding, Kyro drafts a Tirith policy against the real schema, together with a proposed fix for the code that caused it. Your team reviews the policy with passing and failing tests, approves it, and StackGuardian enforces it on every connected pipeline, so the same mistake is stopped in the next plan.

People stay in control of every step that changes something. Kyro proposes; a person approves; the deterministic Tirith evaluator decides whether a change passes. The StackGuardian MCP server gives authorised agents the same context, including workflows, templates, policy attachments and run information.

Conclusion

Your scanners already check that resources are secure. 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 runs those rules and the engines you already use on every pipeline, keeps the evidence, shows you where checks are missing, and uses Kyro to turn each new finding into a guardrail.

Start with the rule your engineers still check by hand. Try Tirith on that rule in one pipeline, or connect your pipeline with a StackGuardian engineer and see every plan, policy result and coverage gap in one place.

FAQs

1. Do we need to change our existing security scanners to use Tirith?

No. Tirith runs as an additional step in the pipeline you already have, so your current checks keep running as they are. Once the pipeline is connected, StackGuardian can run Checkov and other policy engines alongside Tirith and keep all of their results in one place.

2. Can StackGuardian run Checkov and other policy engines?

Yes. StackGuardian runs Tirith, Checkov and other policy engines such as Wiz on plans and code artifacts. You can enforce every Checkov check or only selected rules, control them centrally, keep the results for audit and remediation, and see which pipelines are not applying them.

3. 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.

4. Which CI systems can we connect?

GitHub Actions through the Tirith IaC governance action, GitLab CI/CD through the Tirith CI/CD component (demo project), and Bitbucket Pipelines through a Tirith step (demo repository). Other container-based CI systems can call the Tirith CLI directly after the plan step.

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

No. Through the CI integration today, an approval-required result is reported as a warning, so the CI job continues. Where a human decision must block the change, use your CI’s own approval gate or a StackGuardian workflow with approvals configured.

6. Does using Kyro or other AI agents change the security model?

No. Human-authored and agent-authored changes pass through the same configured gate. Kyro drafts policies and proposes fixes, a person approves them, and deterministic evaluation decides whether a change passes. Each tool can only vouch for the checks and inputs it actually evaluates.

‍

Availability and Sources

Checked on 1 October 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 and external CI approval coordination. Treat open PRs and issues as work in progress until they ship. Platform capabilities depend on your StackGuardian plan, configuration and connected workflows; check availability for your deployment.

• Tirith release 1.2.1
• Tirith repository and usage
• Tirith platform check reference
• Tirith GitHub Action
• Tirith GitLab CI/CD component demo
• Tirith Bitbucket Pipelines demo
• Tirith policy-authoring skill
• Tirith at scale
• StackGuardian MCP server documentation
• Checkov overview

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