Not shipped yet.Here is the order, and roughly when.
Everything on this page is in development or planned. None of it is available, and anything already working lives in the documentation instead. It is ordered by release, and each item says which of the two it is.
Trust the verdict
Next, about a monthNothing new is worth building on an engine that can drop a result. This release is about the verdict itself being something you can rely on, and it changes verdicts, so it ships saying so.
- A skipped check can never read as a passIn dev
A rule that could not run is already reported as unevaluated rather than as success, which nothing else in this category does. A defect in the rollup makes that untrue in some orderings, and it is measured: it changes the verdict on 327 policies. Fixing it is the first thing in the plan for a reason.
- Fail on severity, not on everythingPlanned
Every policy already carries a severity and nothing reads it. --fail-on-severity turns "block on critical, warn on medium" into one flag instead of four pipelines.
- Blast radius as one rulePlanned
"Does this change delete more than two things?" is a property of the change, so a per-resource rule has nowhere to put it. Counting destroys becomes a single policy once count can filter on the action.
- tirith testPlanned
A fixture convention and a runner, so a policy ships with proof that it fails on the document it is supposed to fail on. Every comparable tool can test its policies and Tirith cannot, which is backwards for a project asking strangers to contribute rules.
- Failures that name the resourceIn dev
Every result says which resource address, which planned action and which attribute produced it, so a red pipeline points at a line rather than a policy id.
Scope it, test it, package it
After that, about two monthsThe release that makes Tirith adoptable without writing every rule yourself, and safe for other people to contribute rules to.
- Import the rules you already havePlanned
A translation corpus of 2,495 upstream rules already exists, drawn from Checkov and three Powerpipe Terraform modules: 1,842 of them run as Tirith policies today and 653 do not, each with the reason recorded. Publishing them as installable packs, with a mapping table from the original check id, turns a rule-count gap into a migration path.
- Policy packs and a default libraryPlanned
A manifest that selects a subset of policies and tags them, so "run the CIS pack at high and above" is one command. With a curated default set behind it, evaluating a plan works before you have written anything.
- Policies from gitPlanned
Point -policy-path at a git URL and pin it to a tag, the same way you already pin a Terraform module. Four teams share one rule set without anyone hosting a registry.
- SARIF outputPlanned
The verdict in the format GitHub code scanning, GitLab and most security dashboards already read, so the result lands where your other findings live.
Policy on the change
Then, about two monthsEvery item here is a question a per-resource engine cannot ask, because the subject is the change rather than any single resource in it.
- Before and after, not just afterPlanned
Reading the value a change moves from as well as the value it moves to makes the transition itself the subject of a rule. Deletion protection being switched off, a CIDR being widened, a retention window being cut. Today a policy sees only the new value, and on a delete it sees nothing at all.
- Why a resource is being replacedPlanned
The plan already records the reason. Exposing it separates "you removed the module" from "you changed an immutable field", which are the same red diff and two different conversations.
- Rules that know whose module it isPlanned
Filtering by module address routes a failure to the team that owns it, and turns blast radius per module into a rule rather than a spreadsheet.
- Secrets, checked properlyPlanned
The plan marks which values are sensitive. Reading that is the correct version of "secrets must be marked sensitive", which cannot be written honestly without it.
The layer
Later, about three monthsProvenance and correlation. These are the two things no comparable tool answers at all, which is why they are last: they are worth doing properly rather than early.
- The plan being applied is the plan that was approvedPlanned
A hash of the evaluated plan in the verdict, and a verify step in the apply job that refuses a plan it has not seen approved. Nothing else in this category answers this, because answering it means being present at two moments rather than one.
- One rule across two documentsPlanned
Naming several inputs at once lets a rule say "the scanner flagged this resource and the plan replaces it". Today a policy reads one document per run, so governing several tools means reconciling their output by hand.
- Your own providers and conditionsPlanned
A plugin interface for document readers and condition types, so a shape nobody here has thought of does not require a fork. Policies stay data: a plugin adds typed operations, not an escape hatch into code.
- Installed the way you install anything elsePlanned
Homebrew, a container image, a dev container feature, and the Action listed on the Marketplace. Today installation is a git URL, which is the single most friction-heavy thing about starting. The pre-commit hooks are already published.
The list is not fixed.
Order changes when evidence changes. Several items above moved because a translation corpus measured how many real policies they actually unblock, and one was dropped when the measurement came back at a single policy. If something you need is missing, saying so is the most useful thing you can do.